Captain Protons MVC Advanced Example

[Dr Livingston]

Gathering data for a page in a structure which mirrors the page layout can make it more awkward to share.

Okay, this point is valid but it is sumountable. The last peice of script that I posted in this thread would allow common data to be shared between any number of composites or page fragments.

Now, this leads to this problem... What or how do you determine if one composite or another one for that matter, isn't interested in knowing that common data? For example, as you've pointed out, the HEAD would need to know about a title, but not so the FOOTER.

Please continue McGruff, as you are going somewhere with this

[arborint]

That could be handled by Dreamweaver libraries.

True, but now you have created an additional production step and dependency.

Suppose for example you wanted to use the same application on the command line. You'd print the data in paragraphs not blocks.

First I am not sure just such a thing ever happens in the real world. Second, if you were going to do such a thing writing a renderer to parse the HTML/XML and output formatted text is not to difficult. Third if you are truly outputting to two different devices, of course you could use a separate set of templates.

However I think the cases you mention would be better handled with a separate Presentation layer. If you needed to drive a vector based chisel to carve the output in to stone tablets you would need such a thing as well.

I also think you miss mentioning outputting realistic options like PDFs where a hierarchy is eqully beneficial.

Often you'll find that bits of data cut across page elements:

Several views may share the same model to easily solve this, or create a facade for data from multiple models. This still maintains layer separation.

I started off by wondering if information about page structure was leaking out of the presentation layer. What I meant to say was is it extending too far into the view.

Still not clear about "page structure ... extending too far into the view." I create separate presentation code for each device type if necessary. That usually splits my presentation layer into two layers: a device specific one on top of a general one. A small scale example if this would be a receipt page that also sends an email using the same model.

[arborint]

Selkirk, I am interested to know if you plan to use a hierarchy of controllers that pass the Views back up through them, or if they create a hierarchy of Views that the root controller then renders?

[McGruff]

...but now you have created an additional production step and dependency.

I'm not so sure. All I'm suggesting is to avoid defining page structure until you get to the template. That's formatting just the same as a style="color: red;".

The CLI example was intended to illustrate some design consequences but I also think it's of practical use. With a backup program, it would be easy to adapt the same essential core for use with either a web interface or shell.

However I think the cases you mention would be better handled with a separate Presentation layer.

It's just the formatting which varies, so that's where the cut is made. This would help with PDF's too if your html layout doesn't fit well in A4 - or whatever size the PDF pages are - and has to be rethought.

[Dr Livingston]

or if they create a hierarchy of Views that the root controller then renders?

In the example script I posted today (see the patterns thread I started) the composites dealt with template files only, as this was an early script. Now however, what I have is that it is the job of the recursion to take the View from a Controller.

At this point, the View already has it's HTML fragment composed with whatever Model(s) (their data) it uses, and the composite takes this composed HTML fragment and appends it to it's parent composite's HTML fragment.

This goes on until you reach the root composite, if that's any help?

[dylanegan]

I can see what McGruff is on about.

There should be a way to call the model and pass it to the view without any defining structure, but I have yet to see it. I don't know if we should break a rule here or there to make it easier to work with.

On the other hand, I was thinking about the XML set up that Livingston posted about earlier and thought about using PHPTAL for this.

<page>
 <title tal:content="path content/blogs/title"/>
 <content>
  <blog tal:action="latestBlogEntries"/>
 </content>
</page>

could end up like

<page>
 <title>Latest Blog Entries</title>
 <content>
  <blogs>
   <title>Latest Blog Entries</title>
   <blog>
    <title>PHP....</title>
    <text>PHP do da do....</text>
   </blog>
  </blogs>
 </content>
</page>

Now there really isn't that much structure there, just a definition. There's no presentation either.

Would this break a rule and if so, is it justified?

[McGruff]

There should be a way to call the model and pass it to the view without any defining structure, but I have yet to see it.

    class FooViewData
    {
        // vars used by the template
        var $foo;       // (string)
        var $bar;       // (string)
        var $list;      // (object) - an iterator
    
        function setData() 
        {
            $something =& $this->_someKindOfDomainObject();
            $this->foo = $something->getFoo();
            $this->bar = $this->_request->getBar();
            $this->list =& $this->_someKindOfDataAccessObject();
        }
        function &_someKindOfDomainObject()
        {
            include(..etc..);
            return new SomeObject;
        }
        function &_someKindOfDataAccessObject()
        {
            include(..etc..);
            return new SomeObject;
        }
    }
    
    class FooHtmlPrinter extends FooViewData
    {
        var $_request;  // (object)
    
        function FooHtmlPrinter(&$request)
        {
         $this->_request =& $request;        
        }
        function print() 
        {
            $this->setData();
            include('path/to/foo_template.htm';
        }
    } 

Vars might be obtained from the request, the domain or, if there's no domain logic to do, direct from the data access layer. You can pass scalars or iterators to the template - or any kind of data structure you like.

In practice, it would be slightly more complicated since data might not be available. The setData() method could return true/false, and this would have to be checked in the print() method. You might even have something to undo: the simple act of reading data can occasionally change the model.

Let's say the Foo html view uses a shared header. Where did it go..? On the application side of the boundary, there is no such thing. Just data.

Perhaps I'm missing something, but this seems a whole lot simpler than what I've understood from some of the hierarchical systems being described (although I haven't been looking at actual code). Some hierarchies simply don't exist on the application side of the boundary. Some do: but that's because they are genuine data relationships rather than relationships between the parts of a page layout - eg a list of forums with nested lists of boards.

I don't know if we should break a rule here or there to make it easier to work with.

Just to be sure I'm not misleading you, this isn't an accepted design rule just my own uncorroborated theory.

[arborint]

There should be a way to call the model and pass it to the view without any defining structure, but I have yet to see it.

Not clear what "defining structure" means. I don't see how you could pass the Model to the View and have the Model define structure or layout or whatever. The View can certainly use data from the Model to determine structure or layout. For example in this forum the number of posts (or none) returned by the Model "determine" how many are shown to some extent by the View. But the dependencies still go the right way.

Let's say the Foo html view uses a shared header. Where did it go..? On the application side of the boundary, there is no such thing. Just data.

Huh?

[dylanegan]

Well I do believe I wasn't very clear too. I find it hard to communicate an idea through a medium instead of in person, so sorry for that. As for structure definition I was referring to the way I was passing an XML doc to the View, where another way would be to pass each XML block as you go along.

What I am going to end up using is something similar to the example I posted before. I think it's a simpler controller and is easy enough for a non-technical person to understand. I will let you know how it works out.

[Selkirk]

Selkirk, I am interested to know if you plan to use a hierarchy of controllers that pass the Views back up through them, or if they create a hierarchy of Views that the root controller then renders?

Take a look at this sitepoint page. You can see that it has a hierarchical structure (all HTML does). Yet, not all of the branches of the hypothetical tree are rendered. Look at the tab at the top of the page. The articles, books, and blogs branches of the tree are not rendered as part of this page. The bulk of this page represents the forums branch in the greater application.

So the first stage is to take the input request and determine which portions of the tree to render. This is done by traversing the tree from the root to a leaf. This path from root to leaf is called the command path or the focus path.

The next stage is to build the composite view. For this, we walk the focus path from the leaf node back to the root. At each node we assimilate the view that is associated with that node. In addition, we can collect the children of the node that didn't receive focus, but that can participate in a composite view. These extra children are called 'active' children.

On this page, the articles, books, and blogs children are NOT active children. They can receive focus (When the user clicks on those tabs), but they do not participate in the composite view otherwise. You could imagine that it would be possible to have another organization of this page where those branches where simply hidden via the DOM and the tabs implemented by javascript. In that case, those branches would be considered 'active' because they would be rendered to the view.

As we move back up the line of focus, if we ever reach a point where our composite view cannot be a child of another view, then we stop and render it. This allows child trees to override layout set by a higher level node.

The reason we go from bottom to top when composing the views is purely for performance. Imagine that a lower level view overrode the master layout. It would have been a waste to instantiate the view object associated with the master layout too early. By traversing from the leaf to the root with our ViewComposer, we can be assured of instantiating only the view objects that we are going to actually be rendered. It does make building the composite view more difficult, however, this shouldn't matter to framework users.

Some nodes have children that can neither receive focus, nor activation. During the focus path building stage, events are able to forward focus to another part of the tree. When this happens, the focus path is re-drawn from the root to that node. Thus, nodes that can't receive focus based on direct user input can receive focus based on programmatic control. This is good for error messages, exceptional conditions, and wizards.

Sounds complicated, huh? My hope is that it won't be in actual practice. I'm still implementing it.

[arborint]

Sounds complicated, huh?

Actually, yes.

I'm wondering a couple of things. One is whether this scheme is any better than the traditional Front Controller dispatching an Application Controller where you explicitly specify the tree you mention.

Second, is whether WACT is going towards the Ruby on Rails "automatic transmission" style that seems to be the rage? If what you describe you are building sits on top of a basic controller architecture and can be used both ways, that would be interesting. I guess I'll just have to wait and see.

[Dr Livingston]

I think Ruby on Rails is recieving way too much attention and hype at the moment, it needs to settle first but that's my view only.

Imagine that a lower level view overrode the master layout. It would have been a waste to instantiate the view object associated with the master layout too early.

Exactly, this is what I was thinking off when I made a few posts back there, in a way you could complete revoke a given composite, and thus all it's child composites as well easily.

You could also I suppose, use a completely different parent template based on these actions, and let the recursion begin all over again, which does offer some surprising developments

Looking forwards to seeing more of your ideas Selkirk.

So the first stage is to take the input request and determine which portions of the tree to render.

Selkirk, do you suppose that you'd have pre and post processing for this?

http://www.isis.vanderbilt.edu/publi...Tool_Suppo.pdf

[Ren]

Take a look at this sitepoint page. You can see that it has a hierarchical structure (all HTML does). Yet, not all of the branches of the hypothetical tree are rendered. Look at the tab at the top of the page. The articles, books, and blogs branches of the tree are not rendered as part of this page. The bulk of this page represents the forums branch in the greater application.

So the first stage is to take the input request and determine which portions of the tree to render. This is done by traversing the tree from the root to a leaf. This path from root to leaf is called the command path or the focus path.

The next stage is to build the composite view. For this, we walk the focus path from the leaf node back to the root. At each node we assimilate the view that is associated with that node. In addition, we can collect the children of the node that didn't receive focus, but that can participate in a composite view. These extra children are called 'active' children.

On this page, the articles, books, and blogs children are NOT active children. They can receive focus (When the user clicks on those tabs), but they do not participate in the composite view otherwise. You could imagine that it would be possible to have another organization of this page where those branches where simply hidden via the DOM and the tabs implemented by javascript. In that case, those branches would be considered 'active' because they would be rendered to the view.

As we move back up the line of focus, if we ever reach a point where our composite view cannot be a child of another view, then we stop and render it. This allows child trees to override layout set by a higher level node.

The reason we go from bottom to top when composing the views is purely for performance. Imagine that a lower level view overrode the master layout. It would have been a waste to instantiate the view object associated with the master layout too early. By traversing from the leaf to the root with our ViewComposer, we can be assured of instantiating only the view objects that we are going to actually be rendered. It does make building the composite view more difficult, however, this shouldn't matter to framework users.

Some nodes have children that can neither receive focus, nor activation. During the focus path building stage, events are able to forward focus to another part of the tree. When this happens, the focus path is re-drawn from the root to that node. Thus, nodes that can't receive focus based on direct user input can receive focus based on programmatic control. This is good for error messages, exceptional conditions, and wizards.

Sounds complicated, huh? My hope is that it won't be in actual practice. I'm still implementing it.

So, if my understanding is correct..

If ViewComposer was building a XSLT, each node would be providing a <xsl:template>, and if one provides <xsl:template match="/">, its complete, and traversal can stop.