Right on the spot here. People have tried to solve the problem of form validation by looking at the representation of the form (the HTML form that the user sees in his/her browser), instead of looking at the logical meaning of a form: just a bunch of values that come in as $_POST or $_GET variables to PHP. To name a few of these solutions: PEAR QuickForm, Manuel Lemos' form package (can't think of the name right now, probably metaform :)). These were designed with the representation of the form in mind and fail to adequately separate (which is not the same as 'customizable'!) the validation of this bunch of $_POST values from the displaying of a HTML form. Instead, these two distinct problem were tightly packaged into one almighty UberForm class because 'that makes it so easy for users to create forms'.Quote:
I can understand how people are having problems with form validation, composite views, and all that other crap. Because most of these 'problems' arise when we define our application from the user's perspective, and they become completely befuddling when we combine these misconceptions with the ultimate anti-pattern in web applications; an MVC-based architecture.
MVC, or whatever frameworks us SitePointers propose that bear remarkable similarity to one another's not-quite-MVC-frameworks (:)), does provide the foundation for separating these two distinct problems. By foundation I mean the architecture, or layering, which supports separation of these problems.
That is exactly the reason that form packages like the above mentioned are so hard, if not impossible, to 'integrate with MVC', simply because they were designed for a different purpose. A perfect example of how users pay the price for trying to use classes that were designed to do too much.
Agreed, Fowler is vague. Most of his PoEAA pattern names have so many possible interpretations ('Action', 'Controller', 'Page', 'Front'??) that they loose half of their meaning. What I believe is that he has the right idea but can't come up with an explicit (perhaps even formal) definition of that idea. Instead the idea is given implicitly in his descriptions.Quote:
If the concept of a page is meaningless, the the term Page Controller is confusing. Fowler implicitly indicates as much when he tells us that a Page Controller really handles actions. (That, in turn, is a confusing term, but less so.) I can see now that Fowler, on whom I've been leaning heavily, is also confused and doesn't quite know what he's talking about. Neither does anyone else, I think.
I believe the same is true of (not-quite)-MVC: it advocates some design principles that provide benefits to web apps, even if those benefits are not always visible on short term, but a formal definition of the pattern still has to be given.
But if you think of it, all of the 'classic' Design Patterns [GoF] also started out as vague ideas of things that didn't turn out to be patterns until somebody formally described them.
I know it's vague but that is what a Page Controller is all about: handling actions. They handle things that users want to do with an application (that is even more vague, hehe).Quote:
Fowler implicitly indicates as much when he tells us that a Page Controller really handles actions.
Enough vagueness for now.