Object Oriented Blog System Class Structure

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Object Oriented Blog System Class Structure

Post by Christopher »

Jonah Bron wrote:This sounds pretty different from the guide I was reading (http://oreilly.com/pub/a/php/archive/mv ... tml?page=1). Obviously you don't want to read the fourteen page article, so I'll summarize. :)
That article is five years old and wasn't that good when it was written. ;)
(#10850)
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Object Oriented Blog System Class Structure

Post by Jonah Bron »

Understanding MVC in PHP
by Joe Stump
09/15/2005
Uhhhohhhh... he-he :?

Hm. If you haven't seen this one, perhaps somebody could take thirty seconds and skim it real quick to see if it's any good. It's a lot shorter.

http://anantgarg.com/2009/03/13/write-y ... rk-part-1/

It seems to be much closer to what you described. I might just take a bit to read the whole thing and do the controller over entirely.

Whoa. I'm already experiencing the awesomeness of MVC... I don't have to redo the whole thing: only the controller 8)
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Object Oriented Blog System Class Structure

Post by Jonah Bron »

I've been browsing the code, and it looks like in that particular sample framework, templates and views are one and the same. I'm not too crazy about that idea, mainly because I want to have it set up so that templates correspond to model/actions, and views correspond to output formats (HTML, XML, JSON, etc.). That way, for example, I can make a call with AJAX, and all I have to do is remove the HTML at the end and put on JSON.

But, I guess I don't have to conform to every little detail. I'll start modifying the controller and let you know what I come up with.

Jonah out.
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Object Oriented Blog System Class Structure

Post by Jonah Bron »

The code is getting jumbled. I don't know which way's up anymore. :?

I'm going to scrap it and start over, and base it on the framework in that link I gave...

...tomorrow.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Object Oriented Blog System Class Structure

Post by josh »

That doesn't make sense, templates & views are interchangeable terms. You can do what you describe regardless of what you call your view (a template or a view).
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Object Oriented Blog System Class Structure

Post by Christopher »

josh wrote:templates & views are interchangeable terms.
Not exactly. Views in PHP are often template renderers, but can also generate output programatically. Many frameworks put the generic View code into the Controller (as the are both in the Presentation layer). The View loads the template and the template uses the View functionality to assist in rendering.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Object Oriented Blog System Class Structure

Post by alex.barylski »

That doesn't make sense, templates & views are interchangeable terms. You can do what you describe regardless of what you call your view (a template or a view).
I see a view as most usually an object, where as a template is a HTML file with lines of PHP or some basic subset. A view in it's most basic form, would be the template object, which is then assigned a template file.

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Object Oriented Blog System Class Structure

Post by josh »

You guys are right that theres a distinction between the view object (part of the framework) and the view scripts (or template). But those "view scripts" are often called "templates" was my point. Case in point, Zend Framework has Zend_View which is the view object, and then within each module you have a folder called views/ where your view scripts (templates), and other output generating "view helpers" go.

It doesn't matter if your framework calls those files view scripts, or templates, you can still copy & rename them for different contests (html vs json)
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Object Oriented Blog System Class Structure

Post by Jonah Bron »

Christopher pointed me to the Skeleton Framework project. It's okay because I was trying to put code on top of an apparently not-so-good foundation.

I think I'm going to start working on that project, and use it instead. The cool thing is that I can use all of the info I've received here there. Many thanks to Josh (especially for introducing me to MVC), Christopher, and PCSpectra for all your input. :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Object Oriented Blog System Class Structure

Post by Christopher »

I agree with Josh that you should definitely take a look at Zend Framework as it is a great example of current best practices in PHP. I don't think the code is that approachable, but the examples will show how apps are built.
(#10850)
leenco12
Forum Newbie
Posts: 1
Joined: Tue Sep 14, 2010 9:05 pm

Re: Object Oriented Blog System Class Structure

Post by leenco12 »

Jonah Bron wrote:Thanks josh. That clarifies things a bit. This...
josh wrote:A request basically makes the controller execute, which in turn grabs a model and "pushes" it to the view.
...was what really clinched it. I'll do some more reading and start coding.

Cheers.
For what it's worth, when you inject/push the model into the view, the view becomes directly dependent on that model object and without additional constraints, you make the model API available to the view and that "can" promote a bad practice, such as updating models in the view. You can of course prevent this using a few techniques but now it's just extra code, and IMO over-engineering.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Object Oriented Blog System Class Structure

Post by alex.barylski »

For what it's worth, when you inject/push the model into the view, the view becomes directly dependent on that model object and without additional constraints, you make the model API available to the view and that "can" promote a bad practice, such as updating models in the view. You can of course prevent this using a few techniques but now it's just extra code, and IMO over-engineering.
I tend to agree, but in some instances, such as a pager that must be reused on several pages it prevents a lot of duplication. Otherwise, you would be stuck querying the model and passing an array of pages available for display.

There are also circumstances, where querying the model directly could be beneficial, depending on how or what you return from your model methods. For instance, I asked earlier today, how everyone returned resultset from model methods. I had experimented with returning a resultset object, from the database. Which I have two types:

1. Associative array
2. Buffered query

Associative array resultset object simply dumped the DB results into native PHP array and returned the array for iteration. Alternatively, I could have used a buffer query resultset, which when iterated would only pull one record from the `much more memory efficient` db result set. While this performance boost is moot in all but extreme cases, where *may* come a time when this is what one might want.

If for whatever reason, you needed to render a view or page with 100K records, non-paginated, using a buffered query would be much more efficient as opposed to dumping 100K records into a PHP array.

That being said, I cannot concieve of a single event where this would be required, except maybe in querying a massive email database and firing off mail blasts, any visual display would almost certainly be paginated, thus a simple array being passed to the view should suffice.

Different strokes for different folks, I know personally I like the flexibility of having both as options, just in case. :)

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Object Oriented Blog System Class Structure

Post by josh »

leenco12 wrote:that "can" promote a bad practice, such as updating models in the view. You can of course prevent this using a few techniques.
Wouldn't it be as simple as simply not updating the model from within the view? Put it in your coding standards document if you need to remind yourself ;-)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Object Oriented Blog System Class Structure

Post by Christopher »

leenco12 wrote:For what it's worth, when you inject/push the model into the view, the view becomes directly dependent on that model object and without additional constraints, you make the model API available to the view and that "can" promote a bad practice, such as updating models in the view. You can of course prevent this using a few techniques but now it's just extra code, and IMO over-engineering.
I think it should explained why "updating models in the view" is considered a "bad practice" because these aphorisms about MVC often go unexplained -- adding to the mystery. ;) First I want to clarify that in MVC the View is supposed to be "directly dependent" on the Model. I always want to repeat how important it is that the Model is the independent object and in a separate layer.

The problem that leenco12 mentions is not a dependency problem, it is allowing access to the part of the interface that can modify the Model's state that is the real question. You want the View to access data from the Model. The interface problem can be enforced by creating a Facade to wrap the Model in a reduced interface. I agree with leenco12 and Josh that this is not much of a problem and usually does not need such of a solution.

In the general case, the Model is updated by the Controller because the Controller is what mainly deals with external data sources like the Request or data feeds. And in the general case the View is accessing the Model to get data and state information to generate the Response. Both the Controller and View are in the Presentation layer. Both are dependent on the Model. And though the Model should be independent of code in the Presentation layer, most definitions of MVC allow dependencies from the View back to the Model. This is for practical reasons -- mainly for reusablity of the Model -- where the View (or Controller) provide necessary information to the Model so it knows how to properly deliver the data. You can see that arrow heading from the Model back to the View in most MVC dependency diagrams.

So in general Views should not be updating Models. However, there are cases where it may actually simplify the code and reduce duplication to have the View update or set the Model state. It really depends on the relationships between the Controllers and Views which can be one-to-one, one-to-many or many-to-one.
(#10850)
Post Reply