MVCP - MVC missing a layer?

[Captain Proton]

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.

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'.

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.

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.

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.

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.

Fowler implicitly indicates as much when he tells us that a Page Controller really handles actions.

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).

Enough vagueness for now.

[lastcraft]

Hi...

These two terms both have strong ties with the user's experience created by following a chain of requests using a web browser. And while this is how the majority of our applications will be used, it has NO relation to the actual workings of web applications.

I don't think that this is the right approach. A web application as defined by the business will be built around the conceptual view of...er...a view. This means that as business needs change the schisms will occour along these lines. If our own development model is cut along different lines we will be in trouble.

If I had an ideal framework (on the control side) I would like to write code like this...

Class MySite extends Site {
    function MySite() {
        $this->Site();
        $this->addPanel(new MyMainMenu());
        $this->attachToPanel('main', new MyForum());
    }
}

class MyForum extends Forum {
    function MyForum() {
        $this->setEntryPoint(new ForumEntryPoint());
    }
}

class ForumEntryPoint extends ? {
    function ForumEntryPoint() {
        $this->addTemplates(...);
        $this->addPanel(new MyMainMenu);
        $this->addPanel(new ForumSignUp());
    }
} 

It would then be compiled into nice fast scripts . I would want to be able to change the navigation and plug things in with ease. That would be a controller worth having.

yours, Marcus

[Azmo]

I'm afraid your architecture could be described as MVC anyway. Your Responses and Documents would be the View. Whatever you use to process the Request is your Controller. And presumably there's some data and possibly some business logic (even though you neglect to mention it), which would be the Model.

Yup. You're absolutely right. It could be described as MVC. But there are thousands of approaches you can use to describe this problem, and the vast majority of them don't help you in any way. For example, I could describe my application in terms of Barbie dolls (only the Ken object is allowed to drive the MobileHome object, and Barbie doesn't talk to Ken, because he's an instance of the Sexist******* class). How does this describe the problem domain we're working with? Well, it doesn't, but we could describe our applications using these terms if we forced ourselves.

And that's exactly the problem with MVC. You end up discussing things for ages, but it's never clear what anybody's talking about. And that's because the vocabulary doesn't fit the problem domain.

Then there's the Action. Fowler would place that as part of the Controller in the Front Controller pattern.

You may not like it and you're free to reject it, but what I think is that it's good to be able to think of a design from different perspectives.

My point is that some perspectives are not productive, or even counter-productive. IMO the whole notion of MVC is one of these dangerous approaches. You end up thinking in terms of the User's experience, not in terms of the actual application or problem domain.

And, quite frankly, I couldn't care less about what Martin Fowler says. He's posted some interesting stuff on his website, and I'll definitely buy his refactoring book when I finally have some cash, but I'm quite pissed off at him and the GoF for spreading all that nonsense about design patterns. But that's a rant for a later date.

[dagfinn]

Yup. You're absolutely right. It could be described as MVC. But there are thousands of approaches you can use to describe this problem, and the vast majority of them don't help you in any way. For example, I could describe my application in terms of Barbie dolls (only the Ken object is allowed to do the drive the MobileHome object, and Barbie doesn't talk to Ken, because he's an instance of the Sexist******* class). How does this describe the problem domain we're working with? Well, it doesn't, but we could describe our applications using these terms if we forced ourselves.

And that's exactly the problem with MVC. You end up discussing things for ages, but it's never clear what anybody's talking about. And that's because the vocabulary doesn't fit the problem domain.

I think the problem is that the vocabulary that fits the problem domain hasn't quite been invented yet. MVC helps, but not enough. We're still groping for it.

And, to add one more thing. I think our discussion demonstrates why MVC is helpful: looking at your design from the MVC perspective allows us to see that there are two important things you have not made explicit: 1) business logic and storage (Model) and 2) interpreting the HTTP request (Controller). So knowing about MVC helps me ask intelligent questions about your design if I want to learn about it.

[McGruff]

There are HTTP GET requests and HTTP POST requests. GET expresses the intention to view something, POST expresses an intention to process something. Isn't that pretty close to the distinction you're making here?

Almost - but a site search (ie a submitted form) is a request to view something.

There might also be some processing if you were, for example, logging searches made on an ecommerce site for marketing info.

Actually, ANY request to view something could also involve various processing tasks (email notification, file logging - whatever).

I think MVC fails when you try to use the Controller to manage the entire app. You might instead embed MVC, ie the MVC Controller is passed whatever it needs to get page vars from a model layer, and print them in a view layer (a post-client output email notification would embed another MVC routine to print emails, and so on for file writing or anything else read by a person as opposed to a machine). It does NOT attempt to do anything else. Many descriptions of the MVC Controller would seem to drive a coach and horses through the principle of RDD.

The View (or whatever other name has less baggage) and Model layering is important but I think it's best to forget all about the Controller and manage the application workflow (pre-client tasks --> client output --> post client tasks) as you see fit .

[sweatje]

Almost - but a site search (ie a submitted form) is a request to view something.

For which you could:
a) as you were thinking - have the form post
b) have the <form method="get"> and we are back to a GET request
c) have a post to an actions, uses header('Location: ...); to get to a view

I tend to use c becuase I primarily develop for an Intranet environment that is low latency, and this eliminated the "refresh post message" that bugs my users so much.

[dagfinn]

For which you could:
a) as you were thinking - have the form post
b) have the <form method="get"> and we are back to a GET request
c) have a post to an actions, uses header('Location: ...); to get to a view

I tend to use c becuase I primarily develop for an Intranet environment that is low latency, and this eliminated the "refresh post message" that bugs my users so much.

The search engines tend to use b) and I think this is the most logical thing to do. But it's true--you can choose to use GET or POST for almost anything. I'm not trying to make any rules about implementation; this is conceptual thinking.

[Azmo]

I think the problem is that the vocabulary that fits the problem domain hasn't quite been invented yet. MVC helps, but not enough. We're still groping for it.

But MVC is almost always presented as 'the way' to interpret and discuss web applications. It has become like dogma in a way. If you're still searching for the right vocabulary, you need to be willing to drop or replace definitions that don't fit. Hardly any attempts to do this seen to have been made.

MVC also comes with a set of rules which really don't work in web applications. The terminology is confusing, extremely limited, inappropriate, and misleading. Sure it can help in some way, but so can Barbie. I would prefer to see people use neither of these, and use a vocabulary that comes more naturally. People have been talking about Actions, Blocks, and Documents on these forums. Everyone knows what they are (I don't even have to explain these terms to people who haven't read a tutorial or something). But 'View', 'Model', and 'Controller' are unclear to quite a number of people, and as they read more about the MVC pattern, they often gain confusion rather than insight or understanding.

Many problems we face simply can't be solved if you allow yourself to remain restricted by the MVC straight-jacket. Things like form validation and composite views become alarmingly easy to solve once you accept that there's a different way of viewing things. I should know, because I've solved them.

And, to add one more thing. I think our discussion demonstrates why MVC is helpful: looking at your design from the MVC perspective allows us to see that there are two important things you have not made explicit: 1) business logic and storage (Model) and 2) interpreting the HTTP request (Controller). So knowing about MVC helps me ask intelligent questions about your design if I want to learn about it.

I haven't given you any details of my design yet. I'm just mentioning the vocabulary I use to understand the problem domain:

Controller: Action, Parameter, Block

Model: Data, DataSource, DataManager

View: DocumentComposer, Document, Content, Response, Template, DocType

Other: Authenticator, Authorizer, Request, Client, Server, User

This list isn't complete, but you can already see I can use more terms to describe the problem than MVC would allow, without having to resort to derivates like 'subMVC' and such.

And let's not forget I'm not the one with the problem here.

[Widow Maker]

I haven't given you any details of my design yet.

Are you going to ?

[Azmo]

Are you going to ?

I'm planning to, but first I need to write some documentation for the core classes, register the domain, and GPL the code.

[Widow Maker]

Hurry up then. Please

[cyngon]

I'm planning to, but first I need to write some documentation for the core classes, register the domain, and GPL the code.

I'm quite intrigued by the concepts you discussed, and I'd like to take a look at your architecture. Would it be possible for you to make your code available now so those of us with interest can start tinkering?

I realize the tendency to want to hold off until you can get the documentation in good order and the like, but I believe the "release early, release often" mantra applies here.

If your worried about having to field lots of questions that arise because the code isn't documented yet, you could handle that with appropriatly placed warnings of the code's pre-Alphaness. Perhaps consider making it available via CVS or other version control system instead of a zip download.

If you still don't feel ready for a controlled, public, proof-of-concept release, would you please consider e-mailing the code to those of us following your developments that are interested?

Thanks.

[Azmo]

Would you mind having to wait two more months? By that time I'll have some of the basic functionality ready and stable (user registration, login, permissions, BBCode, ...). I'm also still working on a licensing solution, as the GPL would probably cause me a lot of headaches: some of my customers don't want the features I write for them to be released under the GPL, and I myself am not too keen to hand out commercial software for free either. (I've recently started my own company, and I sort of need to make money. )

I also need to invest quite a bit of time in a testing suite, as I am about to remove a number of features from the framework, among them the debugging system I added about a month ago. Things were starting to get so complex even I had problems understanding what was going on. Screw 'mixins', screw 'aspects', and screw 'namespaces': simplicity ownz.

I could email you the current framework, but I'd rather wait until I have some real functionality to display, so people can fool around with it, and get an idea how this thing is supposed to work (the framework consists of ~7 classes, and it doesn't really give you any idea of how the application built on top of it works).

Would it be OK if I announced the first pe-alpha release of my framework in a topic on this forum? At that point I could even post the framework's code here (along with whichever licence I decide to use ).

[Widow Maker]

Okay, we can wait

But not too long mind, we get bored very easily As for profiting, fair game, we all need to make a living, to avoid upsetting your clients, you could just release the basics.

That would be enough for us all to get an idea of how your framework works, and why it works the way it does, etc. Thus, your protecting your own interests as well

[ghurtado]

Really looking forward to getting my hands on this!

[Afro Boy]

So, 2 months is up! Have I missed it?

Af.

[Azmo]

So, 2 months is up! Have I missed it?

Af.

I totally didn't expect anyone to still show an interest in my work after this time. And yes, you did miss it

I posted the core source code in this topic. Since then I haven't had a lot of time for development, but recently I did make some serious modifications to the structure and ideas behind the framework/application (no more components, just modules). I'll post the new source in the somersault thread when I've had some time to clean it up. Right now I'm kinda busy setting up the new company fileserver.