The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

design patterns; a PHP sandtrap?

I've been a PHP user for a long time, maybe 8 years or so. It's a great language.

Years ago, I would come to this forum to learn about amazing things, mostly "design patterns". It's good stuff. I learned a lot. But I started using another language and framework and got on my merry way, creating applications (not frameworks and patterns). I stopped visiting the sitepoint forums for no good reason really. But now, years later when I come back, people are still talking about the exact same things; MVC, front-controllers, template systems, Composites etc.. It's as if nothing has changed. I don't tend to see these kinds of discussions in the other languages that I've been using. I know it's a good thing, but because nothing seems to have changed, it makes me wonder if it's some kind trap that PHP developers fall into. Anyone else ever think about this?

I have been following it too, and it is my opinion that many of the conversations you mention are started by different people relearning those same things.

Its not that the search doesn't work, its likely that as I say the personalities change, and the language moves on, opening up new possibilities to do things in slightly different ways.

It is also probably true that many of the people here are like me, and dare I say like many PHPers, we don't have a formal CI background or training, and really need to have some principles explained to us.

When you are the recipient of so much free, thoughtful and intelligent advice you do feel inclined to "give back" when you can. Perhaps that is a PHP thing? Perhaps PHPers don't mind explaining the same things over and again to newcomers, because they hope and believe that they will also influence someone else to "give back" when they can.

It doesn't bother me that the discussions are perennially about mvc, there is always a new twist, a new way of explaining it but I do find it a bit sad that there is now far less discussion on other patterns than there were, say 2 or 3 years ago.

Personally, I agree with you that patterns are a trap that PHPers fall into, but I see it as part of the learning process and eventually you do stop looking for patterns and thankfully, that's when they start looking for you.

The problem is that most documents about MVC on the web don't show the complete picture. It's not enough to talk about models, views and controllers. Especially in the web context, you have to talk about:

Routing from a http request to a page (often this is all called "controller")

Assembly of pages from visual elements (composite view)

The different kinds of visual elements, with different representation: Pages, layouts, templates.

Components that are layered in model, view and controller. (this can be the entire application, or single visual elements)

Controller code to handle form input.

The data layer, with methods for data retrieval and data manipulation. And the interface that the data layer presents to the view layer (via a locator, or whatever).

Especially, it is often not clear if the separation into MVC layers should happen for the entire application, or for single components.

At any point where we want to modularize, we have the possibility to do this either vertically (in MVC) or horizontally (into components, such as startpage, shopping cart, etc).

Give me such a comprehensive document, and I'll stop asking questions on sitepoint
(well, not really)

I also think that model, view and controller are not the best names in a web context. "page router", "page" and "page element" (with "view" being the "abstract parent class") would be much more helpful for understanding.

... Especially, it is often not clear if the separation into MVC layers should happen for the entire application, or for single components. ...

Very good point lemon.head. From what I've seen so far everybody tends to separate the whole application in MVC layers rather than the components. The syndrome for such a disease is probably controller obesity.

I think the constant influx of new developers has a lot to do with the perpetual focus on MVC, but I think the fundamental reason is with PHP itself.

With PHP, it's difficult to build a set of tools (IDE, framework, debugger) that works well for every development environment and development team. Compare the sheer number of well-known application frameworks for PHP (ZF, Symfony, CakePHP, Konaha, CodeIgnitor, Prado, eZ, etc) versus C# (ASP.NET, ...?). Or the number of code editors that PHP developers use (Eclipse, Notepad++, Textmate, vi, PSPad, PhpED, etc), versus those that C# developers use (VS.net, ...?). Having a single company (like MS) that maintains the language/platform with a very strict vision of what it will be enables a level of standardization and best practices in the development community that is difficult for a project like PHP to mimic.

A large part of PHP's appeal is its minimalism; it doesn't "get in the way", it let's you build your app however you see fit. But this minimalism means that 3rd parties have to fill in the gap by providing the tools/libraries/frameworks that are missing from the core. So combine that toolset variety with PHP's relatively rapid evolution (e.g., OO overhaul from 4 to 5, autoloading classes in 5, namespaces and late static binding in 5.3, traits in 5.3 or 6.0, etc) and you end up with a pretty dynamic (unstable?) community where best practices are kind of hard to nail down. Like Cups said,

Originally Posted by Cups

...the language moves on, opening up new possibilities to do things in slightly different ways...

Then there's the fact that PHP is used mostly for building web apps, as lemon.head pointed out. The most critical issue with building a web app is, arguably, deciding on how to handle the flow of the application from request to response. MVC is almost always the first answer out of peoples' mouths, but the devil is obviously in the details

Originally Posted by lemon.head

Routing from a http request to a page (often this is all called "controller")

Assembly of pages from visual elements (composite view)

The different kinds of visual elements, with different representation: Pages, layouts, templates.

Components that are layered in model, view and controller. (this can be the entire application, or single visual elements)

Controller code to handle form input.

The data layer, with methods for data retrieval and data manipulation. And the interface that the data layer presents to the view layer (via a locator, or whatever).

It's no wonder that folks have a hard time understanding, much less describing, the best way to tackle these issues...implementing MVC in the PHP4 days was much different than it is now, and I imagine the target will move again when PHP6 comes out.

I also think that model, view and controller are not the best names in a web context. "page router", "page" and "page element" (with "view" being the "abstract parent class") would be much more helpful for understanding.

"Page" is much more intutitive, but also ill-defined. Here's a challenge: when do two different HTML documents represent separate web pages, and when do they represent the same web page? What are the criteria to decide those questions? With plain static hypertext, it's easy to answer. When everything is dynamic, it's not.

"Page" is much more intutitive, but also ill-defined. Here's a challenge: when do two different HTML documents represent separate web pages, and when do they represent the same web page? What are the criteria to decide those questions? With plain static hypertext, it's easy to answer. When everything is dynamic, it's not.

"Page" maybe be ambiguos. But honestly: Who cares? Usually when you say "the profile page", it is quite clear that you are talking about something that takes as a parameter a username, and spits out a html page representing a member profile. The same for "forum topic page".

You will always find a way to use the word in a non-ambiguous way, and still benefit from the intuitiveness of this term, as opposed to "view". I don't want to totally dismiss the term "view", just don't use it for things that could have a more meaningful name.

Here's a challenge: when do two different HTML documents represent separate web pages, and when do they represent the same web page? What are the criteria to decide those questions? With plain static hypertext, it's easy to answer. When everything is dynamic, it's not.

Actually, considering how HTTP is designed, this is actually very simple: just compare their URLs. If they are the same, you have a single "page", regardless of how they are different and how they're created.

Web consists of nothing but resources (that's the "R" in URL), which can be a text document, an image, a Flash video, a bitstream or any number of available data formats. A web page is an organized collections of those resources presented through a browser.

Actually, considering how HTTP is designed, this is actually very simple: just compare their URLs. If they are the same, you have a single "page", regardless of how they are different and how they're created.

Web consists of nothing but resources (that's the "R" in URL), which can be a text document, an image, a Flash video, a bitstream or any number of available data formats. A web page is an organized collections of those resources presented through a browser.

I agree with that basic definition of what a page is, but that is just the end product that the user sees in their browser, and it's very common that what the user sees at any point in time was created with many different views on the server side. Therein lies the trouble of calling the "view" a "page". Sure, if every response your application builds is a single HTML document which ends up being rendered as a single, "normal" page in the browser, then "page" would suffice.

But it gets more complicated and less page-centric when you get into the realm of AJAX and APIs where responses are no longer complete pages, but instead are page fragments, or even just structured data (JSON, XML, etc).

So while "page" does make sense for many situations, the more generic "view" covers all the bases pretty effectively.

I don't call everything a page, only those things which deserve this name. More precisely, I call those classes or variables a suffix "$page" or "class SomethingPage" which represent a page.

So while "page" does make sense for many situations, the more generic "view" covers all the bases pretty effectively.

Generic names for generic items.. specific names for specific items. What I want to avoid is having two variables or classes which are both called "view", but with one being a page, the other a fragment of it.

The same goes for documentation about MVC in general: Instead of calling everything a view, you can give more precise names.

I don't call everything a page, only those things which deserve this name. More precisely, I call those classes or variables a suffix "$page" or "class SomethingPage" which represent a page.

Ok, I was considering this page-vs-view issue from a more abstract level. Your earlier comment:

Originally Posted by lemon.head

I also think that model, view and controller are not the best names in a web context. "page router", "page" and "page element" (with "view" being the "abstract parent class") would be much more helpful for understanding.

...seemed to imply that the "view" layer should be referred to as the "page" layer instead. When it comes to naming conventions in the application code (i.e., specific view classes and objects), then I agree that "page" would add a good bit of clarity for folks that are already in a page-centric frame of mind and looking to understand MVC.

Interesting, with the title of this post and how the discussion has turned into a discussion about patterns; we're (NOT) even on page 2!

I too find this stuff interesting. The reason I made this post is because I've been working with another language and framework over the past years or so. And because that framework provides all of the things I use to solve on my own when I used PHP, I stopped thinking about these issues and starting writing and finishing apps. Which is an awesome feeling.

But it's interesting to think about how depending on something that solves problems for you, naturally makes you not think about those problems anymore. Not sure if that's good thing or a bad thing? In a way, I miss solving those problems/revisiting and thinking about them.

Actually, considering how HTTP is designed, this is actually very simple: just compare their URLs. If they are the same, you have a single "page", regardless of how they are different and how they're created.

Web consists of nothing but resources (that's the "R" in URL), which can be a text document, an image, a Flash video, a bitstream or any number of available data formats. A web page is an organized collections of those resources presented through a browser.

I'm afraid I started this and then dropped out for a few days. Sorry.

That's an unambiguous definition, but does it make sense from the point of view of web app internals? After all, we want to know how to program it. You have /article/101 and /article/102, two different URLs. Almost certainly, they're handled by the same code and the ID is just passed down through the layers. It's one View, two URLs.

That's an unambiguous definition, but does it make sense from the point of view of web app internals? After all, we want to know how to program it. You have /article/101 and /article/102, two different URLs. Almost certainly, they're handled by the same code and the ID is just passed down through the layers. It's one View, two URLs.

Well, you have to consider something -- in terms of what is visible in your browser, your application's internal structure is completely irrelevant. From the visitor's point of view, your /article/101 can be a static page served by the http daemon, while /article/102 can be prepared by a 10.000 LOC server-side application utilizing four different databases and whatnot.

It's important to understand that each Web application actually consists of at least two completely separate applications -- one is your server-side app, which does what it needs to do to prepare as its output the code for the second application, which runs in the browser (even if it's just plain HTML).

On the PHP server side the definition is only partially useful. What it can tell us:
- We only have one http request per run. Thus, we only have one "page", which is, the document being served (hey this reminds me, why not call it "document", if we want to include ajax or non-html media?).
- Different vars can store different aspects of a page. For instance, $page_parameters, $page_layout, $page_layout_template_filename, $page_html.
- A page class is not the same as a page object. The page (if we have one unique object for it) object can be an instance of PageAClass one time, and PageBClass another time.

...seemed to imply that the "view" layer should be referred to as the "page" layer instead. When it comes to naming conventions in the application code (i.e., specific view classes and objects), then I agree that "page" would add a good bit of clarity for folks that are already in a page-centric frame of mind and looking to understand MVC.

I was not only thinking of code, but also of documentation / tutorials, where it's not helpful to only talk about "views". This applies especially to documents about MVC which are not written with a web context in mind (such as, for java, cocoa, smalltalk..).

It's important to understand that each Web application actually consists of at least two completely separate applications -- one is your server-side app, which does what it needs to do to prepare as its output the code for the second application, which runs in the browser (even if it's just plain HTML).

I think the topic starter made it quite clear which of these two separate apps we are talking about..