[Solar-talk] Layout / View ideas

[Rodrigo Moraes]

Paul asked about the idea of adding /View as a final callback for layouts,
and I would like to elaborate a bit about why this was first suggested and
the my preferred approach to manage layout and view templates, which I think
is also very flexible and consistent.

First, we asked to include /View as a final fallback because Solar includes
"templates with content" in layouts. For example, _auth.php is included in a
layout using:

    include $this->template('_auth.php');

And this means that _auth.php is not available to be used in view templates
without changing the stack. I think this is wrong. _auth.php may be part of
a view, and we could reuse the same markup with different styles if it was
inside /View ("login to comment", "login to vote" etc). So, I moved
_auth.php to /View, and removed the include from the layout. After a while,
I developed a method of building layouts which is flexible for any layout,
highly reusable and consistent. It has some rules:

1. Layout templates are just structures. They never have content or specific
content markup. Which means: they never include templates that may be reused
in a view - basically, they never include "templates with content". They
just include "structure templates".
3. So, because of #1, layout templates just echoes content. "Content" are
parsed view templates which are assigned to a "Layout" class (I don't know a
better name, so I will just call it a "Layout class"). The layout class is
assigned to the view object on render().

So, taking an example from the app branch, instead of having this in a
layout:

<?php include $this->template('_header.php'); ?>

With _header.php carrying some content and content specific divs, we would
have this:

<?php
if($this->_header) {
    echo $this->_header;
}
?>

... or whatever variable name is defined in the Layout class for the header.
On render(), all templates assigned to the header part are fetched and
assigned to the variable. What then? The layout becomes elastic and flexible
to include other templates assigned to the same variable, and it is also
very reusable and consistent - all content in a layout is echoed, never
included - layouts just include other structure layouts. The result is that
layouts become very "agnostic" and clean.

A Layout class also would allow us to assign multiple templates to the
"current view" without including them on the view template or adding logic
to the view template. This is possible by assigning the current action view
template by default to the 'layout_content' variable in the Layout class,
but it is possible to add another template to this variable (an array of
template definitions), and all templates will then be fetched on render().
This means more flexibility to manage views, allowing us to handle and
combine "multiple action views" inside the controller or a extended Layout
class. And, extending a class like this, you can also have an automatic
cache mechanism to cache templates separately and have a mix of dynamic and
cached templates in a page without repeating the logic needed for the cache
(an example with caching support is here, using the bad name "Response":
http://dev.tipos.org/browser/trunk/Tipos/Response.php ).

I can clarify these ideas and provide some examples, if you are interested
or have doubts. :)

rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.killersoft.com/pipermail/solar-talk/attachments/20070316/d87892d4/attachment.htm