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.

[dagfinn]

Controlling the outcomes for a single page is the job of a Page controller. Its the job of the page controller to determine if the request for that page should trigger a login, search, command, etc.

But what is a page? According to Fowler, "more strictly, the controllers tie into each action, which may be clicking a link or a button." That would make a Page controller an event handler.

Is there a difference between a Page Controller and a command, except that the Page Controller looks like a page when seen from a user's point of view? If so, what is that difference?

One aspect of the the GUI MVC pattern is that it seems to emphasize multiple simultaneous views and instant updates of each view when the model is changed. This doesn't seem like it would matter in a web environment.

GUI MVC, or rather rich-client MVC, is so different from Web MVC that they should probably have different names. They serve entirely different purposes. The purpose of rich-client MVC is exactly what you describe. Much of the MVC confusion probably stems from the failure to make the distinction between rich-client and Web MVC clear.

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 View needs to contain information that's intelligible to the Controller because it communicates with the Controller. That doesn't mean this information is part of the Controller. I think of it as either event identification or as a "function call", a message intstructing the Controller to execute a command.

Does each subview have its own controller? if you do then in MVC you will have to build your C tree as well as your V tree.

Rich-client MVC calls for one controller per view, but these are simultaneous views that can be updated independently. I don't think that's relevant to Web MVC.

Smells like shotgun surgery.

The need for shotgun surgery to add a field is a downside of MVC and especially the typical layered architecture:

Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes. The classic example of this in a layered enterprise application is adding a field that needs to display on the UI, must be in the database, and thus must be added to every layer in between.

[NativeMind]

You know, lastcraft said it best... web applications are an illusion, they are just a bunch of scripts that we hook together to serve out something (the majority of the time access to a database).

There is no difference from the clients perspective if they choose your service via clicking on a URL that goes to index.php?module=myModule&action=theAction, versus just clicking on "blogs.php"

My very first PHP project at work (I had done other stuff as more of a hobbyist) was a couple years ago and I was charged with developing an admin system and end user interface, which just massaged data in a postgresql database.

This was before MVC or even OOP was popular in the PHP community, so everything was procedural and I put everything into various library files for common actions.

For every 'page', and every 'action' there was a separate php file. Like 'view_profile.php' and 'update_profile.php'; Each script included the session library file and executed the session check function (which would redirect them to the login page if the check failed).

Let me tell you, the only regret I have on that project was not using a template system.... everything else was lightning fast. I did more in one month of development that I've seen existing teams develop in several months (and these teams now use MVC frameworks).

I'm not saying that MVC frameworks (like Mojavi) don't provide a bunch of features, I'm just giving my experience using "the old way."

-----------------------------------------

Recently I was pondering about a great concept forum project. The concept is that the forum would be a simple front end to a series of SOAP services. The SOAP services would be very granular (like getTopic, getForum, getUser, getMembers). And then application script would be SOAP client requests to all of these other services and generate an front end to it using something like the WACT template system.

I don't think the model could get any more abstract than being its own service. Plus data being processed within the context of a single process, you defer some of the processing to the server threads. I know, overall, it would drive the performance down but you never know until you try!

[dagfinn]

You know, lastcraft said it best... web applications are an illusion, they are just a bunch of scripts that we hook together to serve out something (the majority of the time access to a database).

I'm afraid that particular insight doesn't make my day. Everything in programming is illusion. There's no operating system, no ethernet, no Internet, no PHP code. It's really just electrons running around in circuits. And a few light beams.

[Captain Proton]

But what is a page? According to Fowler, "more strictly, the controllers tie into each action, which may be clicking a link or a button." That would make a Page controller an event handler.

The sentence 'the controllers tie into each action' is important here. Try to forget about 'Actions' as you know them in Struts, that's just confusing terminology if you ask me. Actions are the individual tasks that a user can perform using your application: add news, edit news, add a user, view a list of recent news, etc.. A PageController is responsible for one of those actions or tasks. You could compare the code-behind of an ASP.NET webpage to a PageController, there are some differences though, but it's the closest thing.

The difference between a framework with PageControllers and a framework with one FrontController and Actions (Struts, Mojavi) is that PageControllers are part of the presentation layer of an application (= V + C) while Actions are part of the model layer of an application. The Actions execute logic without making any presentation layer-specific decisions such as returning a View, domain logic. The FrontController than examines some status code returned by this Action and then chooses an appropriate View. For those who have read PoEAA by Martin Fowler, you know that this is how Fowler defined the FrontController pattern.

The problem with PHP MVC frameworks like Mojavi is that there Actions in that framework are a combination of presentation layer specific logic (such as form validation) and domain logic. This leads to confusion as to where to place certain behaviour. If you look at Fowler's definition of the FrontController pattern, for those who have read PoEAA, the FrontController is actually a lot of PageControllers combined in one but with a lot of logic delegated to Domain Commands.

Fowler talks about a Front Controller dispatching to commands. Core J2EE patterns talks about Front Controllers being responsible for managing commands and managing views. I no longer think of it this way. I think the front controller's job is to dispatch to a page controller. Its the page controllers job to manage views.

I made that decision too a long time ago. At first, my FrontController started out as an object that simply checked the URL for which PageController to call, but then I added things like InterceptingFilters.

I do not think loading this information in the view itself violates MVC in any way. The view doesn't need the controllers help to go fetch some data from the model and display it to the user. The only place the controller would come into the picture is if the information in the subview was dependent on the user's input for that request. The view has free access to the model.

This has been the major problem with my current MVC-like implementation. If I drop this constraint, I'm done

[NativeMind]

This long time developer came to me as the local php guru at work since I was a proponent of using php for our embedded device management web interfaces.

This developer asked me "What is the benefit of an MVC framework? .. versus say just a bunch of scripts with some include files"

You know the only good answer I could come up with, the only one that a framework could do better than a simple set of scripts was maintainability. If you ever developed the old php application where you had files like "blogs.php" and perhaps "posting.php", you know that maintainability becomes an issue as you expand your application since things like URLs aren't necessarily addressed in a uniform manner. Perhaps the old way adds greater flexibility at the cost of maintainability.

To this day I still ponder over the adoption of a framework or not. You don't know where your website will take you. You start as an online store, but you want to add auctions, forums, photo galleries, blogs. How much work are you prepared to invest by porting these modules to use the framework?

One of the biggest arguments against MVC for me is not the separate of business logic and presentation but the front controller. HarryF argues best in his article that Apache is the front controller. If you accept this as true, then perhaps MVC has its place in the various use cases for your site (like news system, forums, etc). The front page of the site merely becomes which use case you want to display by default, and I think Mojavi implements this nicely.

[Captain Proton]

When HarryF advocates Apache as the FrontController, he is talking about the FrontController's task of 'selecting a page controller': selecting which PHP file to load based on the request.

However, the FrontController can also serve as a place for setting up Intercepting Filters. I know that these can be implemented as auto_prepend and auto_append files but than the request handling can not be done in a very object oriented fashion.

[NativeMind]

I don't see a difference in having a front controller object setting up filters versus having a page controller that is derived from a generic controller that does your filters

[mwmitchell]

I think that the main problem that the frameworks that I've tried out is the FrontController. They seem to lock me into working a particular way. Which can be a good thing. But it always seems like more work than just doing it without a framework. And I gree that the PageController (in some MVC frameworks) just kind of gets melded into the Action.

I think a set of guidelines for how to work with the different layers of an application, would be more valuable than a framework. And it seems as though that's exactly what this thread is headed for!

Matt

[Widow Maker]

SleepEasy - From an earlier post

... $pipe->add(new Login_Form()); ... 

Been thinking about this, and need some input from you ?

You register this action prior to handling the action it's self, so I could proberly do the same ?

So, if I register a number of events, like you do, the registra would in effect (to me anyways) hold the condition of an event, ie

If someone has decided to log in or not yes ? Likewise, for your menu, the event the registra holds would be the current condition of the menu ?

Would then be just to go through each event in the registra, one by one, and dump the output to the View.

My way of thinking is, that each class, ie Log In, Menu et al would be layered around MVC, so an event grabbed from the registra would in fact only return the XML/HTML/whatever to the View at the end of the day.

Can you give some input on my thoughts ?

[Widow Maker]

...guidelines for how to work with the different layers of an application, would be more valuable than a framework.

Do you own M Fowler's book by any chance, which talks about software layering. Been meaning to find some more time to read through it all again myself, alas, not enough hours in the day

[Captain Proton]

I don't see a difference in having a front controller object setting up filters versus having a page controller that is derived from a generic controller that does your filters

Flexibility. FrontControllers can form a pipeline out of any number of InterceptingFilters in any order, something which is not possible when the behaviour of the filters is coded into a PageController base class. By encapsulating this behaviour into separate classes instead of putting it into a PageController base class, the filters become better reusable and the request handing more flexible (which is, as some might say, more object oriented).

My way of thinking is, that each class, ie Log In, Menu et al would be layered around MVC, so an event grabbed from the registra would in fact only return the XML/HTML/whatever to the View at the end of the day.

This is a, if you don't mind my saying, 'frame of mind' that I understand, but you have to think about web applications differently. You are thinking from the point of view of the webpage: let's call this View oriented, ok? A webpage consists of a number of blocks and each of those blocks can trigger events which need to be handled.

In reality, web applications don't work that way. The blocks are an illussion, one might say A web application receives a request and it forwards it to some request handler which chooses an appropriate View after it has handled that request. A web app does not create a webpage first, than examines if an event has occured for any one of the blocks on that page and renders some output on that block (well, some apps do but they're not coded well). What it does do, is this: it responds to only *one* event and depending on how that event was handled, it sends a webpage to the browser. It does not matter which webpage (View) this request originated from. Let's call this: request/event-oriented, ok?

Would then be just to go through each event in the registra, one by one, and dump the output to the View.

This is a View-oriented thought It is based on the assumption that an event triggered by one of the blocks on a webpage always results in that same webpage but with parts of the blocks changed. This is an assumption that is easily debunked. When a login block is submitted, the web app might display a page in a totally different layout that simply says 'Thanks for logging in! We are now redirecting you'. So what is the point then of going through all blocks to examine if one of them has received a request?

Sigh: I home somebody out there understands what I mean and can rewrite it, because I did a lousy explanation (I'm not a native english speaker/writer). But the point is that you need to change from being View-oriented to being Request/Event-oriented when it comes to Web MVC.

[Widow Maker]

Thanks Captain, can see where your going with it

When a login block is submitted, the web app might display a page in a totally different layout that simply says 'Thanks for logging in! We are now redirecting you'.

You've made your point. But for me anyways, difficult to move in the direction your suggestion. From what I can gather, are you suggesting that I have an Request Handler to generate the required events to be triggered ?

If this is the case, wouldn't it be the same Request Handler that'd carry out the event triggering as well ?

[Captain Proton]

Well, I hadn't come to the suggesting-an-approach part yet

I'm not suggesting anything new really, just that thinking request/event-oriented can be done by using a PageController for every event. To continue your example somewhat, think of a website with a login block and a poll block. Two events can occur here: login and vote, you'd write a PageController for each one. When the login is a success, you might want to display a success page or simply display the original webpage again with the login block changed. To do this, your view code for the login should check if the user is logged in (not by doing complete cookie checks, but by a simple $user->isLoggedIn() or something like that) and display contents based on that condition. The view code for the poll block does something similar: it checks if the user has voted on the poll ($poll->hasBeenVotedOn() etc.) and changes the way it renders the poll accordingly.

The PageController for voting is an object that does not have much to do with the poll block, it simply responds to a vote event by adding a vote to the database or perhaps changing some $poll object. The view code for the poll block does not care whether the poll has just ago been voted on or whether this was done a year ago (i.e. it does not care whether the 'vote poll' event was triggered), it simply checks a Poll object to see if the user has voted on that poll already.

Your PageControllers are separated from your Views. They do not care how the views look like, all they have to know is what data they can expect from the browser when the PageController is called. I think this quote is related to this:

For the controller to pick apart the form data, though, it has to know a lot about the template structure because of the way all the data has to come in a batch in PHP.

Not necessarily. A PageController does (IMHO) not care whether a list is rendered using a select box or a series of checkboxes, all it cares is the format of the data it receives in the HTTP request.

Change any widget in the template and you have to change the controller. What is this telling you?

This is something that does not have to do with MVC per se. With or without MVC, if you change a field in your template this means that the underlying data model has changed as well. You have to change view, controller, model and data access code for this anyway. MVC does not force this restriction on you, nor does it take it away. There are solutions to this problem but they are not related to MVC, nonetheless they can be applied to an application that uses MVC.

[lastcraft]

Hi...

Normally I avoid MVC debates because I don't find them very enlightening. I relented this time because I had nothing to but suffer flu over Xmas. Boy am I going to regret that one, this thread never dies .

Not necessarily. A PageController does (IMHO) not care whether a list is rendered using a select box or a series of checkboxes, all it cares is the format of the data it receives in the HTTP request.

I was really thinking of more complicated situations, but yes I should have restricted my comments to say that the controller is extremely sensitive to view changes. Change a complex widget (such as adding a sort button to a grid) and any controller that has that widget within it's view will have to change quite spectacularily. Think of all those extra actions .

This is something that does not have to do with MVC per se. With or without MVC, if you change a field in your template this means that the underlying data model has changed as well.

Well, if you are likely to be making these changes reasonably often then the MVC architecture is likely a poor choice then? If you are mainly reporting data, the majority of the view does not involve widget interactions at all. In fact generated links should be fine. In this case I would say the controller/action classes are overkill. A more active template, that pulls the data it needs, allows the elements to be moved from page to page.

MVC does not force this restriction on you, nor does it take it away.

But, it forces you from a potential two way coupling (MV) to a definite three way one (MVC) straight away. Surely twice as much extra work. In addition it may mitigate against useful refactorings of the MV relationship whilst trying to fit into an MVC straight jacket.

Advantages of Struts style pattern (action classes):
1) Easy to understand structure.
2) Simple forms are very easy to code.
3) It is possible to build action superclasses for simple reuse.
4) Some simple filtering is possible a'la aspects for more widespread reuse.

Possible disadvantages:
1) Tight VC coupling.
2) Excessive layering making major refactorings painful.
3) Composition of views is difficult.

Reading this back it seems that this style is geered towards flexibility in event handling at the expense of flexibility in the display. Hey, it's starting to look like a pattern now .

Am I starting to understand some things at last?

yours, Marcus

[mwmitchell]

Just want to get this straight. When you all talk about an "Action", do you mean a form submission with user input? Or something else? If it's not a form submission, wouldn't an "Action" be every single request?

matt

[Widow Maker]

Can you explain what you mean by an Action Class Marcus ?

Maybe with an example if you can, without mentioning Phrame

Just so I can understand a bit more ?

Thanks.

[mwmitchell]

Do you own M Fowler's book by any chance, which talks about software layering. Been meaning to find some more time to read through it all again myself, alas, not enough hours in the day

No! I know I need to get it real fast. I keep thinking that I understand enough to post here in these forums (let alone this thread)! But sometimes after I read my own posts, I want to go and cry. I can't help it though, I love this stuff. I saw it at Barnes & Noble and may have talked my wife into getting it for me! (fingers crossed)

Matt

[Widow Maker]

I want to go and cry.

Tried that myself - doesn't work. So now I simply bang my head off a wall

[dagfinn]

Tried that myself - doesn't work. So now I simply bang my head off a wall

It's not good for your brain. You should use drugs instead

[lastcraft]

Hi...

Can you explain what you mean by an Action Class Marcus ?

It was Struts/Phrame/Mojavi I was thinking of. Anything where the action is selected by the front controller (even if the front controller is on several pages) based on the raw request and usually an XML config. Also where the action has a single method to carry out it's work (ignoring Struts' DynaForm for the moment).

yours, Marcus

[mwmitchell]

After thinking about the use of an "Action", I can't figure out why you'd want to use the URL to call one. I mean, shouldn't it be up to the page to call one of these "Actions"? It seems so limiting to use the URL to call only one. Then your "Action" has to worry about how to fit into the main view, or you have have to have some kind of page controller TO "Action" mapping.

If you start out with a Page Controller, then your Page Controller calls the "Actions" when needed. Am I making sense?

Matt

[Widow Maker]

I see. At the moment, I parse a required XML file based on what is passed via $_REQUEST.

This XML file has some variables required for the given page, such as which body template, and ''blocks'' to use, which are basically structural containers for dynamic data pulled from the model.

You are talking about a front controller, so I can only assume that from my script, this is the front controller ?

class Application {
        function Application() {
        } // class constructor not implemented
        
        function Run( $action, $l = false /* log in result */ ) {
            if( $l == (bool) false && $action['command'] != (string) 'LogIn' ) {
                header( 'location:index.php?Cmd=LogIn' );
                die();
            } 
            # fetch required file that contains execute command structure
            Application::Import( $action['module'] );
            
            # create an instance of this commands controller and perform an action
            $cntrl = &new $action['action']( &$action );
            $cntrl -> Perform();
        }
        
        function Import( $file ) {
            # check that file actually exists, if not then generate an error
            if( !file_exists( $file ) ) {
                ErrorReport::Invoke( 200 ); // bad file read
                die();
            }
            require_once( $file );
        }
    }
    
    class Action {
        function Action() {
        } // class constructor not implemented
        
        function Respond( $action ) { 
            # fetch command given by a user, or use default if none found
            $command = (string) ucwords( array_key_exists( 'Cmd', $action )? array_shift( $action):'CPanel' );
            $filename = strtolower( $command ); // all filenames are in lowercase
             
            # create an instance of XmlReader using this commands assocc configuration file
            $conf = &new XmlReader( DOCUMENT_PATH. $filename .'.action.xml' );
            
            # fetch root elements belonging to configuration file
            $children = $conf -> FindChildrenOf( 'command', 'Command' );
            $action = array();
            
            $action['xmlreader'] = &$conf;
            
            foreach( $children as $child ) {
                # every root element requires an array position
                if( $conf -> NameOf( $child ) == 'templates' ) {
                    # found an element typeof XML_ELEMENT_NODE
                    $action[$conf -> NameOf( $child )] = array();
                    
                    # find all child elements
                    $templates = $conf -> FindChildrenOf( 'templates', 'Templates' );
                    
                    foreach( $templates as $template ) {
                        # for each child element, extract name and contents
                        $node = $conf -> Extract( $template );
                        
                        # store a template name and filename to array
                        $action[$conf -> NameOf( $child )][$conf -> NameOf( $template )] = $node['filename'];
                    }
                }
                else if( $conf -> NameOf( $child ) == 'fragments' ) {
                    # found an element typeof XML_ELEMENT_NODE
                    $action[$conf -> NameOf( $child )] = array();
                    
                    # find all child elements
                    $fragments = $conf -> FindChildrenOf( 'fragments', 'Fragments' );
                    
                    foreach( $fragments as $fragment ) {
                        # for each child element, extract name and contents
                        $node = $conf -> Extract( $fragment );
                        
                        # store a template name and filename to array
                        $action[$conf -> NameOf( $child )][$conf -> NameOf( $fragment )] = $node['filename'];
                    }
                }
                else {
                    # no child elements on this iteration found
                    $action[$conf -> NameOf( $child )] = $conf -> ContentOf( $child );
                }
            } 
            return $action; // typeof array
        }
    } 

Here is an example of one of those XML files I stated as well

<?xml version="1.0" encoding="iso-8859-1"?>
<module>
    <forms>
        <form />
    </forms>
    
    <command name='Command'>
        <task />
        <title>Manage your application and it's user from this control panel</title>
        <action>CPanel</action>
        <module>modules/administration/cpanel.class.php</module>
        <heading>Administration :: Control Panel</heading>
    
        <templates name='Templates'>
            <template>
                <filename>templates/cpanel.html</filename>
            </template>
            <header>
                <filename>templates/header.html</filename>
            </header>
            <footer>
                <filename>templates/footer.html</filename>
            </footer>
            <body>
                <filename>templates/body.html</filename>
            </body>
        </templates>
        
        <blocks name='Blocks'>
            <a>
                <filename />
            </a>
        </blocks>
    </command>
</module>

Lastcraft, any thoughts?

Thanks again.

[Widow Maker]

Am I making sense?

Nope

[Azmo]

After thinking about the use of an "Action", I can't figure out why you'd want to use the URL to call one. I mean, shouldn't it be up to the page to call one of these "Actions"? It seems so limiting to use the URL to call only one. Then your "Action" has to worry about how to fit into the main view, or you have have to have some kind of page controller TO "Action" mapping.

If you start out with a Page Controller, then your Page Controller calls the "Actions" when needed. Am I making sense?

Matt

You're thinking from a View/MVC perspective, and this way Actions don't make much sense. But it's not the page (or PageController) that calls an Action, it's the Action that builds the page Document.

Example: www.sitepointforums.com/show_topic.php?t=1 The show_topic Action is executed, and it fetches the topic Block to combine it with the main forum template.

Using a Front Controller: www.sitepointforums.com/index.php?action=show_topic&t=1 In this case the Front Controller selects the show_topic Action based on the 'action' parameter.