MVCP - MVC missing a layer?

[Azmo]

The "web application" is an illusion created by a sequence of scripts. To maintain that illusion we have to have some kind of super controller to manage the steps. This step controller doesn't usually exist in any single script. Because in PHP we are always completing the last action and offering up the next, we are actually doing two half jobs. This means that the real application control, the real top level meat, occours half way between each script. A good way of exposing it is to split all top level scripts into *_display.php and *_handler.php in a typical application. You suddenly find that you need a bit of extra logic either at the end of the handler script, or the start of the display script to select the next display. Hardly surprising that this very important top level logic gets buried away and becomes difficult to modify. I wouldn't call the class that deals with this logic a "controller". More of a "navigator".

I think you are on to something with this idea of "two half jobs." Imagine an alien software anthropologist studying 20 applications written to use 20 different so-called MVC frameworks. Surely, he would not come away with the idea that the central abstractions of the application were models, views, and input controllers. He would come away thinking the central abstractions were commands or actions (*_handler.php) and views (*_display.php).

Web applications don't really do a half-job IMO. Our applications focus on "Resumption of Service". We want the client to make more requests in the near future. So every time we send a Document to a client, we embed links to related services (the Actions we perform to satisfy a client's request).

I agree that the web application only exists in the mind of the user. The meaning of the content is created by the user as well: the webbrowser has no idea what it's rendering (I'm referring to the business data here, not the Document's structure).

I've been struggling with this idea in WACT. Do the templates contain control information? I think there is a difference between control information (sounds like you mean navigation information) and a controller.

The URLs and forms embedded in templates can be seen as the APIs for the Action they request. Think of the domain name as the namespace, the remote filename as the function name, and the URL's parameters as the function's arguments. Then it suddenly makes sense why it's such a pain to change an URL: it's basically an API change, and these can cause a lot of work.

Working on this issue is challenge for the near future. I've run into the issue of needing viewlets and subviews. I've programmed some support for the CompositeView pattern, but have not yet determined what impact this will have on the controller structure.

I embed references to 'Blocks' in my main templates (.NET does it, too! ). Each Block object is responsible for fetching and transforming a certain set of data into a sub-Document. In MVC terminology: it's a sub-MVC object, or a SubView. This actually breaks MVC; it's bad practice to call lower-layer MVC objects from the View - you're supposed to make these calls from the Controller. So I don't use MVC.

Well, to sum this thing up, lets go back to our alien anthropologists list of tried and true patterns for web application development:

Front Controller
Page Controller (optional application controller)
Command
Model
View
Template

Should we even be looking for patterns at this point? It seems to me that we haven't even figured out what the Problem Domain really is. I think the patterns will emerge by themselves, after the Problem Domain has been defined. But whatever we end up doing, lets try to come up with an alternative to the MVC terminology. Most people who use 'MVC' seem to feel it doesn't really fit their application, or worse, they've run into problems because of it.