Page 1 of 1
Template View and site layout commonalty
Posted: Fri Sep 02, 2005 11:00 am
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?
Posted: Fri Sep 02, 2005 2:33 pm
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
Posted: Fri Sep 02, 2005 4:22 pm
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.)
Posted: Fri Sep 02, 2005 5:15 pm
by nielsene
Please, I'm asking for different methods for implementating a Template View style, not Transform View...
Posted: Fri Sep 02, 2005 5:26 pm
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
Posted: Fri Sep 02, 2005 6:44 pm
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.
Posted: Fri Sep 02, 2005 7:11 pm
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?
Posted: Fri Sep 02, 2005 8:06 pm
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.
Posted: Fri Sep 02, 2005 8:11 pm
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.
Re: Template View and site layout commonalty
Posted: Fri Sep 02, 2005 8:17 pm
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.
Re: Template View and site layout commonalty
Posted: Fri Sep 02, 2005 8:34 pm
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.
Posted: Sat Sep 03, 2005 8:32 am
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.
Posted: Sat Sep 03, 2005 1:12 pm
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?
Posted: Sat Sep 03, 2005 1:39 pm
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
