Template View and site layout commonalty

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Template View and site layout commonalty

Post by nielsene »

When using Template View for the view component, how do you deal with the common site layout markup (of which I have three separate themes used in different areas of the site).

I've been planning that the Template View only contains the "Content" for the View. All the "chrome" shouldn't be included, making it easy to change, later. The "simplest" way I've considered is having a single class for each layout, that does its own include($templateName) to pull in the content with the chrome framework.

Another related option would be to use the above base classes, but have the Templates elevated to classs status with a over-ridden getContentPanee() method to inject the page specific content. This either moves the actual template into the class (thus making it harder for a designing to get at) or causes a x2 explosion in number of files. Plus it hardcodes a given template view to a given chrome-style

Addressing the last issue would be some sort of abstract factory (get Header, getNavMenu, get footer, etc) for each page-layout style along with a builder for order of calls. Content could still be directly included or packaged in a class.

I hear a lot of people talking about editting Template Views in WYSIWYG editors, but I don't really see how that works -- unless you don't pull out the chrome. Then the page is a full page, in context, to view and design. But now you have to touch every single template view to change the markup. (Not simple CSS changes). If the template has lots of sub-includes for the header/nav/footer, its still not easily designable, unless you've kept the structural divs at the topmost template level so they block out the page. This still means that you can't changes those later easily, but that's less of an issue....

What are your thoughts?
User avatar
andre_c
Forum Contributor
Posts: 412
Joined: Sun Feb 29, 2004 6:49 pm
Location: Salt Lake City, Utah

Post by andre_c »

lately i have been letting the template engine only do variable substitution and output an xml file describing the layout (not colors, images, or theme stuff) and i use a different XSLT file for each theme
i prefer to describe layout using metadata, not code
... not sure if that applies to what you're asking about
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

In theory i prefer the XSL / CSS combination for customized layouts/presentations.. But compared to PHP templates (simple plain text html with some php code in it) it's pretty slow on a busy server.. (For a company this would not be a really issue.)
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Please, I'm asking for different methods for implementating a Template View style, not Transform View...
User avatar
andre_c
Forum Contributor
Posts: 412
Joined: Sun Feb 29, 2004 6:49 pm
Location: Salt Lake City, Utah

Post by andre_c »

sorry, I'm still getting used to those names, i often get them confused...
although since both patterns solve the same problem, it might be worth considering Transform View
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

(I've got a feeling i don't understand your question/problem well)

From http://www.martinfowler.com/eaaCatalog/ ... eView.html:
The best way to work is to compose the dynamic Web page as you do a static page but put in markers that can be resolved into calls to gather dynamic information. Since the static part of the page acts as a template for the particular response, I call this a Template View.

Why do you think that an XSL file or a PHP file can't be an implementation of a Template View?

Imho, if you have 3 different themes (different static content, same variable content) it's more or less evident that you search for the common code, wrap it in include files/functions/classes instead of copying it 3 times.
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Using XSLT to transform some logical domain structure to a XHTML page is the very definition of Transform View as opposed to Template View. I have nothing against PHP file being a Template View; and its one of the options I've been looking at.

The fundamental question was:
One of the biggest advantages often mentioned regrading Template View is the ability for a designer to work soley with the template. Either using "simple PHP" or extensive custom tags, etc. However, for a designer to work with a template in a WYSIWYG editor, normally requires the "full chrome" of the page and not just the content section. How have been implemented a Template View, without replicating the Chrome, but still keeping the template WYSIWYG editable?
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

nielsene wrote:Using XSLT to transform some logical domain structure to a XHTML page is the very definition of Transform View as opposed to Template View.
In my vision, an XSL file (not the XSLT process) is a Template View. I would consider the class/function that performs the actual XSLTransformation using the XML/XSL files to be a Transform View. (Its analog to a PHP file used as a template. The transformation is done by the PHP engine, not the file itself)

nielsene wrote: The fundamental question was:
One of the biggest advantages often mentioned regrading Template View is the ability for a designer to work soley with the template. Either using "simple PHP" or extensive custom tags, etc. However, for a designer to work with a template in a WYSIWYG editor, normally requires the "full chrome" of the page and not just the content section. How have been implemented a Template View, without replicating the Chrome, but still keeping the template WYSIWYG editable?
If i understand well, it's again a matter of defining interfaces, what the template writer can expect as input (or what the coder should generate as output)

To allow the designer to work soley on the template i think that "mocking" that input is a good option:

In the case where the designer writes XSL templates, it's a matter of agreeing on the XML that will be used as "interface". Now the designer only needs a static sample of that file, and a tool to perform XSLT.

In the case of a PHP based template, i would expect some mock objects that deliver sample data...

For both approaches there is a range of wysiwig tools available.
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

timvw wrote:
nielsene wrote:Using XSLT to transform some logical domain structure to a XHTML page is the very definition of Transform View as opposed to Template View.
In my vision, an XSL file (not the XSLT process) is a Template View. I would consider the class/function that performs the actual XSLTransformation using the XML/XSL files to be a Transform View. (Its analog to a PHP file used as a template. The transformation is done by the PHP engine, not the file itself)
In which case you're into a Two-Step View process and not simply Template View.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Re: Template View and site layout commonalty

Post by McGruff »

nielsene wrote:But now you have to touch every single template view to change the markup.
Dreamweaver (or etc) libraries can be used to manage common page elements such as shared headers/footers. The main body of the script can simply define sets of data for different views without knowing anything about headers, footers or whatever.

A library lets you share layout elements without resorting to template fragments in separate files. You'd still have fragments but now they're stored in a library. The big advantage is that you can work with complete pages from doc type to < /html > - and of course a single (library) edit updates all. From the graphic design point of view, you really need to see how everything fits together as a whole.
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Re: Template View and site layout commonalty

Post by nielsene »

McGruff wrote:
nielsene wrote:But now you have to touch every single template view to change the markup.
Dreamweaver (or etc) libraries can be used to manage common page elements such as shared headers/footers. The main body of the script can simply define sets of data for different views without knowing anything about headers, footers or whatever.

A library lets you share layout elements without resorting to template fragments in separate files. You'd still have fragments but now they're stored in a library. The big advantage is that you can work with complete pages from doc type to < /html > - and of course a single (library) edit updates all. From the graphic design point of view, you really need to see how everything fits together as a whole.
This is what I'm trying to "get". I've always just done all my design/programming/etc in Emacs. So if a template contains, none of the shared elements, then I can't preview the template in a the browser, etc. Thus my old pages would typically get rendered like

Code: Select all

$page=$display->beginPage($title);
$page .= <<<END_PAGE
content

END_PAGE;
$page.=$display->endPage();
echo $page;
Thus the HEREDOC served as the Template. With all the chrome stuffed into the two function calls. (There used to be more function calls, but I ended up continually combining them so it was less likely to have to change the individual pages, etc)

However, that doesn't feel "right" for a Template View -- it should be just the stuff that was in the Heredoc.

So assuming a person was using Dreamweaver, or some other HTML editors, what would a template view look like, how is the chrome managed, etc.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

Dreamweaver marks up library items in html files with comments:

Code: Select all

<!-- #BeginLibraryItem "/Library/header.lbi" -->
......
<!-- #EndLibraryItem -->
You can easily add library items to pages by dragging and dropping. When you edit a library item, Dreamweaver automatically updates all files with that item.
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

So does this mean that when implementing your Template View, if you want to separate out the common elements, but retain ease of editting by HTML designers you have to limit yourself to a single editting platform because of the custom extensions for managing shared elements?
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

The assumption is that, basically, this is nothing to do with the php application: html formatting is best managed by the kinds of tools which a non-coder might commonly use so that they can work in the way they're used to, as far as possible. The main editor I have in mind is Dreamweaver. If you don't have library support then yes, that's going to mean a bit of copy-pasting - or write your own in php.

Others may not share my aversion to template fragments though ;)
Post Reply