That article is five years old and wasn't that good when it was written.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.![]()
Object Oriented Blog System Class Structure
Moderator: General Moderators
- 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
(#10850)
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Object Oriented Blog System Class Structure
Uhhhohhhh... he-heUnderstanding MVC in PHP
by Joe Stump
09/15/2005
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
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Object Oriented Blog System Class Structure
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.
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.
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Object Oriented Blog System Class Structure
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.
I'm going to scrap it and start over, and base it on the framework in that link I gave...
...tomorrow.
Re: Object Oriented Blog System Class Structure
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).
- 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
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.josh wrote:templates & views are interchangeable terms.
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Object Oriented Blog System Class Structure
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.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).
Cheers,
Alex
Re: Object Oriented Blog System Class Structure
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)
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)
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Object Oriented Blog System Class Structure
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.
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.
- 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
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)
Re: Object Oriented Blog System Class Structure
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.Jonah Bron wrote:Thanks josh. That clarifies things a bit. This...
...was what really clinched it. I'll do some more reading and start coding.josh wrote:A request basically makes the controller execute, which in turn grabs a model and "pushes" it to the view.
Cheers.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Object Oriented Blog System Class Structure
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.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.
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
Re: Object Oriented Blog System Class Structure
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 yourselfleenco12 wrote:that "can" promote a bad practice, such as updating models in the view. You can of course prevent this using a few techniques.
- 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
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.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.
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)