Captain Protons MVC Advanced Example

[graedus_dave]

This is a bit of a rabbit trail, but I have a quick question. I'm currently working on refactoring a fairly large OOP application into MVC/patterns. For the sake of simplicity, I'm spreading model and view classes across multiple files. Obviously, I only want to include the models and views the application will be using for any given request.

My question is: where's the best place to require_once() the models/views you need? Does it matter? Am I missing something in terms of the application design?

Here's what I'm thinking (ignore the hard-coded path):

class IndexCommand extends BaseCommand {
    
        function execute() {

            require_once('../views/IndexView.php');    
            $this->view = new IndexView();

        }

    } 

Just wanted to make sure that was a reasonable way to go about it. Thanks!

[Dr Livingston]

I think the Controller selecting the View and Model and passing the Model to the View is the most straightforward. I also keeps the dependencies straight.

Exactly, this is my understanding of this pattern. Rather me being the cause of confusion, I think this is the source of confusion

...
Views often offer functionality that allows controllers to manipulate the display.
...

This is back to front

[DougBTX]

Under what circumstances would you see two sets of commands depending on request method?

In a CMS with clean URLs, you could find an example. Say you want to read an article, you could get the article using:

GET http://www.example.com/article/learning-mvc HTTP/1.1

Then you want to post a new article, you could do this:

POST https://www.example.com/article/ HTTP/1.1
username=DougBTX
password=pass
article-name=My Article
article-text=Some text here.

As with any POST, you will want to redirect from that page to somewhere else to protect from reposting, so the returned headers might look like this:

HTTP/1.x 302 Moved Temporarily 
Location: http://www.example.com/article/my-article

Or you could do it with an intermediate page like vBulletin does.

You don't technically need to know whether the data has come from a GET or a POST, but it might make programming interfaces like the above simpler if you do know.

Douglas

[DougBTX]

I think the Controller selecting the View and Model and passing the Model to the View is the most straightforward. I also keeps the dependencies straight.

In this scenario is there only ever one model per view? Do the views then get combined by a "composite view"?

Douglas

[Ren]

In a CMS with clean URLs, you could find an example. Say you want to read an article, you could get the article using:

GET http://www.example.com/article/learning-mvc HTTP/1.1

Then you want to post a new article, you could do this:

POST https://www.example.com/article/ HTTP/1.1
username=DougBTX
password=pass
article-name=My Article
article-text=Some text here.

As with any POST, you will want to redirect from that page to somewhere else to protect from reposting, so the returned headers might look like this:

HTTP/1.x 302 Moved Temporarily 
Location: http://www.example.com/article/my-article

A successful POST (meaning that everything passes validations, and model and/or database successfully updated. Otherwise you'd want the same view.

You don't technically need to know whether the data has come from a GET or a POST, but it might make programming interfaces like the above simpler if you do know.

You dont need to know where the data has come from, (array_merge($_GET, $_POST) is fine) but if your making changes to server state, HTTP recommends only doing that via POST. Hence the idea of limiting the available commands/actions based on the $_SERVER['REQUEST_METHOD'].

[arborint]

You don't technically need to know whether the data has come from a GET or a POST, but it might make programming interfaces like the above simpler if you do know.

I agree, but I think that what you need to know what the request method is and make a decision on that. My question was about maintaining two sets of commands (one for post, one for get) for the same action posted by Ren.

In this scenario is there only ever one model per view? Do the views then get combined by a "composite view"?

I am forming the opinion, based in part on Selkirk's experiences with WACT, that creating a heirarchy of Controllers with their (optionally) associated Models and/or Views is a good direction to go. It is where I currently am headed and why this thread is of interest.

[DougBTX]

hehe, here's a testamonial for Studs:

I've been using PHP for my personal sites in the last couple of years. While it has been great to create simple dynamic websites, I've been pretty appalled with the freely available applications/libraries for PHP ... it seems that Studs takes the most annoying aspects of Struts development, and castrates the quick development process of PHP.

See Studs MVC Framework+ for more info

Douglas

[sambox]

View:

- View components display information to the user. A view obtains the
data from the model. There can be multiple views of the model.
- Each view has an associated controller component. (!?)
Each view creates a suitable controller. There is a one-to-one relationship between views and controllers. Views often offer functionality that allows controllers to manipulate the display.

Sorry this was confusing, I took it from the book "A System of Patterns", and they describe not a web application. So the model could change during Runtime and the view needs to be updated immediately. So they use an observer pattern behind the MVC pattern in order to react on events.



My solution:

I am very impressed by the http://www.rubyonrails.org/ Framework, I watches those videos and I am in love :-)

Especially the Components solution is impressive. In my eyes this is a better solution for a complex page then the ActionChaining Concept. It abstracts the ideas from the HMVC solution. The different is that not the Controller chooses “SubMVCs”, instead the View includes “SubMVCs”:

<%= render_component(:controller => 'image', :action => 'recent_image') %>

The advantage I see is, that the main controller stays so simple as possible and to me it is more part of the View to include SubMVCs (like a Header, Footer, some Boxes (Login, Search ...)). Like I said before:

The SubMVC-Modells are so View related ... For example if the user chooses not the "Product-Website-View" but instead the "Product-Minimal-Cellphone-Website-View" (Product is shown, but without some boxes ...)

Components

The Possibilities

As you can see, it is possible that, with components, Rails developers will be even more capable of sharing code. Additionally, if you intend for the users of your software to alter the views of the application (which is common), it allows you to provide those users with even greater flexibility in regard to what can be displayed without additional work and configuration files on your part, and without them having to modify the controller code.

...

Rails’ components offer one final feature. For those of you interested in being as modular as possible, there is the components directory (found one level below app). This directory is meant to hold other directories which contain entire subsets of functionality: controllers, models, and views. The allows the components to exist entirely outside of the standard app directory and makes for simple tar/untar style distribution and installation.

...

From this point forward, your models, views, and controllers should be coded just as they would be normally ...

Components to heavy in some cases?

Think abou a very simple box on the page with an image and some text inside.
Sure, it don't make sense to implement a SubMVC for that?! In that case you are free to use for example the ViewHelper Pattern.

And ... You are not restricted to call the SubMVC Components from the View, of cause you still have the possibility to involve them from the Controller:

Secondly, there is render_component within the controller. This has the effect of passing both control flow and view rendering off to the component being called. This is useful if you have a controller that implements logic to determine what should be displayed but would prefer to utilize code already in a component method to handle the rest of the logic once it’s determined what is needed to be done. It allows for your code to be more DRY (don’t repeat yourself).

The next thoughts ...

Page Controller or Frontcontroller?

There is an nice article from Harry:

The Front Controller and PHP

That said, looking at some of the frameworks inspired directly by Jakarta struts, such as php.MVC, phrame, ambivalence and eocene, all use a central configuration file which contains information about the entire website. There's a tale to tell here about what happens when you try to apply Java to rigorously to PHP... One other that takes an interesting "middle ground" is ISMO, distributing most of the command hierarchy to the file system in a similar manner to eZ publish but using class methods instead of a switch statment for handling the final actions.

All of these pass requests through a single script, which often hurts when it comes integrating or making significant modifications to your site later.

It might also be argued that this approach to implementing a Front Controller in PHP does alot to raise the learning curve required to become fluent with the framework, which is significant if you're not convinced about the "vendor".

He is not a friend of a Frontcontroller, and I think so too.

But what about...?

To say that passing all requests through, say, index.php "is evil" is wrong.

The big advantage of doing this is it makes it very easy to deal with "global operations", which have to happen on every page of your site, such as logging, authentication / session checking and dealing with such things as HTTP client cache headers.

The solution from WACT:

The Base Controller

When multiple page controllers share duplicate logic, a common practice is to move that logic to a base page controller which each page controller can inherit from. This is one way of implementing CentralizedRequestLogic.

ASP.NET provides a special mechanism for implementing base controllers in scripts, called CodeBehind.

When the base controller class begins to have special case logic in it for types of requests, it might be a good idea to consider a FrontController instead.

So ... this is my favourite solution for MVC and SubMVCs:


Source: http://www.martinfowler.com/eaaCatal...ontroller.html


And now ... ? :-)

A real world example in PHP would be nice ;-)

[dylanegan]

Heya Dr Livingston sorry to reply so late, but I was wondering about your XML solution.

I am currently working on a XML/XSL MVC solution.

What happens is pretty similar to WACT and so on, as in their is a controller which calls an action and the action defines a view. Well the action I have sets any data that may need to be passed to the view into XML format so the view just calls and XSL file and viola, output. But I am stuck on how to handle multiple actions -> views.

Hopefully something in this thread will help me.

[Dr Livingston]

At the moment, for complex views I use the Composite which is built on the fly on each page load, so based on an XML file, I can structure a layout for a given page, a given series of pages, or an entire site easily.

Each Composite (page layout such as a search box, navigation breadcrumb, etc) has it's own controller, or in some events, an action chain to decide one of many actions, such as based on a request or a configuration variable.

To develop in a consistent manner easily the ideal solution would be to build the composites on the fly, for maximum re-use. However if this isn't possible you are left with building the composites statically.

I like this approach as each controller is then reusable and completely separate from the application. (Looking into how each controller can cross communicate between themselves).

Kyber has posted several examples I believe? Both are worth more attention in their own rights, I like their approaches but personally I don't need to implement those approaches.

But I think they are worth exploring some more. The templates I use at the moment are (x)HTML but they could just as easily be XML, and if that were the case, it'd be the XmlWalker that'd ultimately generate the (x)HTML from the XML based on a XSL stylesheet.

Makes no difference to the architechture, as I just need to swap in another XmlWalker to differentiate the use of a stylesheet.

But I am stuck on how to handle multiple actions -> views.

I'm of the view that where ever there is a decision process you can either use Chain of Responsibility, or a Factory if object creation is the end result? But I'm not completely following your question...

Are you trying to create one or more action to generate one view, or the other way around? ie one action with many (sub) views...

[sambox]

@dylanegan

Welcome in the club ;-) You have the same problem as I! I use a simple PHP template engine in my Views in order to generate XHMTL output. I (want) to use a Data Transfer Object (DTO) inorder to hand the data over from the modell to the View.

At the moment :-) I think components are the best way to handle multiple actions.

Each Composite (page layout such as a search box, navigation breadcrumb, etc) has it's own controller, or in some events, an action chain to decide one of many actions, such as based on a request or a configuration variable.

@Dr Livingstone, Hey that sounds like a component :-)

[Dr Livingston]

Hello,

Have you looked at the View Helper? I posted an example in the thread in my Signature if that's any help

EDIT:

What do you mean by a component? Could you explain some more please.

EDIT No2:

Do you mean the Action Chain?

[sambox]

@Dr Livingston

No I do not mean the Action Chain, I try to avoid this concept bcause I think the Controllers getting to complex with that. I think Components (Ruby Rails Component Concept) is much better. Please take a look at the post before my last post in this thread, I wrote there al lot about the component conzept.

[Ren]

I'm still pondering on the Response class, in regards to what responsibilities that are required. Could do with some help if available?

A Request contains the Accept* headers

Accept
Accept-Language
Accept-Encoding
Accept-Charset

Which indicate UA preferences.

So Im thinking Response deals with what your actually going to send, what content-type, language, encoding(gzip compression), and charset.

[Dr Livingston]

Please take a look at the post before my last post in this thread, I wrote there al lot about the component conzept.

I didn't notice your post at the time that I had posted, but I'm reading it now

[Dr Livingston]

Hello,

Yes, it does appear that both approaches have simular methods. At the moment though in my case, one controller cannot communicate with another controller, as in the rails approach,

3.2 ... In a Controller

Secondly, there is render_component within the controller. This has the effect of passing both control flow and view rendering off to the component being called. This is useful if you have a controller that implements logic to determine what should be displayed but would prefer to utilize code already in a component method to handle the rest of the logic once it’s determined what is needed to be done.

This is what I'd like to implement. So ultimately one controller higher up the Composite hierarchy is dependent on the outcome of one the controllers lower down, for example.

I think some kind of Queue would be required, but not sure

[arborint]

I like the idea of each "SubMVC" being a Component (stand-alone unit with a defined interface). Many frameworks seem to add this capability, but wouldn't it make more sense to just start with only having SubMVCs in a heirarchy. Each would return a $view object with a render() function. Each parent can render each subView in the corrrect place. The root View displays everything.

The next thoughts ... The Front Controller and PHP

I wouldn't be too concerned about which one is "right". A Page Controller combines the functions of the Front Controller / Application Controller combo. Either way is fine.

[Dr Livingston]

The root View displays everything.

This is how I do it at the moment, but in my case I just return a template to each controller, so the recursion picks this up and deals with it.

This makes the recursion lighter but less flexible so there may be an advantage to your suggestion...

[dylanegan]

Thanks for that Livingston. Although I just woke up i'll get back to this when im wide awake and can process some thoughts.

What you have said is exactly what I am looking for, especially since I need to adapt this to a CMS situation where the client can define a page and its own blocks and it needs to be able to build itself.

OK a bit more awake now. I have, in the past, read about CompositeView, etc, but didn't take it in because I wasn't planning on doing anything with it at that point in time. I think I will have to gather all the best links available and read it again.

What I am thinking of doing is with each "Action" it would do what it needs to do and then create an instance of a particular view and pass any data to it. With a pack of actions with their own views I would need some way to define what views to render first and so in. Using the CompositeView this would be fairly easy as I could pass an id as a string or a number to it along with the view and it could build up a tree structure. It would then go from the highest number to the lowest rendering each view. Just wondering because each View is rendering a piece of XML the sections would be transforming as they go higher, would this actually work out?

Now this is thought of with my limited knowledge and will probably not make sense once I actually get down to reading this.

[Dr Livingston]

Umm...

For the recursion to work properly (on the fly) each composite has to have it's own ID, and it's own parents ID. I leave these as attributes in the XML file, on the otherhand WACT takes another approach for example.

Just wondering because each View is rendering a piece of XML the sections would be transforming as they go higher, would this actually work out?

I think the best approach would be to pull the XML out of each composite as you recurse and add these fragments to the parent composite fragment, and build the document up that way? Then the root composite just renders via a transformation.

You could on the otherhand, transform each XML fragment as you go up the hierarchy, and build the web page that way as well?

Taking the second approach would mean you need the transformer in the component (base class which each composite extends). But in saying that I think a Visitor could be used to abstract the transformer from the component.

[sambox]

@dylanegan take a look at the first post on page 2 of this Thread, there I wrote something about the composite View (with links).

I think the easiest way is to combine the compositeView with Components like ruby on rails and ViewHelpers.

[DougBTX]

What I am thinking of doing is with each "Action" it would do what it needs to do and then create an instance of a particular view and pass any data to it.

If you set up a naming convention between actions and views, your framework could automatically generate the view 90% of the time. Having an action define a different view would be a special case, so it should save you doing lots of repetitive coding in the actions.

Further, if the action declared which view it would like to use, rather than creating one itself, you wouldn't end up with creating default views for actions then discarding them 10% of the time.

Douglas

[Ren]

Umm...

For the recursion to work properly (on the fly) each composite has to have it's own ID, and it's own parents ID. I leave these as attributes in the XML file, on the otherhand WACT takes another approach for example.

I think the best approach would be to pull the XML out of each composite as you recurse and add these fragments to the parent composite fragment, and build the document up that way? Then the root composite just renders via a transformation.

You could on the otherhand, transform each XML fragment as you go up the hierarchy, and build the web page that way as well?

What if sub-component-x requires some javascript?

[DougBTX]

What if sub-component-x requires some javascript?

Assuming output buffering is being used (and I'd assume so, so that caching can be used) then each sub-view just has to register with either its parent or the root that it wants x chunk of HTML in the <head>. That piece of code could be a <script> tag, or a <link> to an RSS feed, or whatever you like.

It would probably be easiest to do this in the root rather than a parent, saves bubbling up the data. There is only one <head>, so there may as well only be one object to handle it, though if you don't want children knowing about root, you'll only have to tell them about parent. If parent asked its children for <head> info, the child wouldn't even need to know about its parent, in which case the parent my as well be root.

											
     asks         asks
root ====> parent ====> child
  ^           ^           | 
  | head      | body      |
  |           |           |
  +----<------+----<------+
                body+head
                    
    ===> = request
    ---> = data flow 
    head = a view which renders: <script>, <link>, <meta> etc
    body = a view which renders: <h1>, <p>, <div>, <li> etc
    bold = classes/nodes

And because of the infinite repitition, root is the parent of parent, just as parent is the parent of child, so eventually parent passes its body to root too.

Douglas

[Ren]

Ok.

I suppose if you views where returning DOMDocumentFragments it'd work quite well,

Subview Z returns
<link...>
<div class="subviewZ">...</div>

Subview Y (parent view of SubView Z) returns
<link ...
<div class=subViewY">...<div class="subViewZ">...</div>...</div>

all the way up to the root, where it can finally place link(s) etc in the correct place.