Page Driven Design |
BACK | UP | NEXT |
Two Models for Site DevelopmentIf you used to be a CGI programmer then you likely thing about site design like this:
This development process tends to put the programmer in the drivers seat: you created some really interesting content, and now you want someone to make it look pretty. The template writer is probably asked to render your data with a nice template. However, many websites work the other way around: the template writer creates a page, then comes down to engineering and asks for it to be implemented. WebMacro has extremely strong support for this second model of development, called page driven design, which empowers the page designer, putting the HTML folk in the drivers seat.
Step #1: Write the template firstWith a page driven development process the first step is you write your template. Then look at it, see what objects you needed to create on the template, and instantiate them.Since WebMacro is just as happy dealing with a hashtable as a full fledged Java bean, you can mock up an initial implementation fairly quickly: populate some hashtables with some mock data and your template will render it beautifully. But this approach is still lacking something: the template author has to work through the programmer. Having to go down to engineering and wait while the objects are implemented is a major pain in the neck--it's an example of one person trying to work through another. True page driven design demands a little better co-operation between the template writers and engineering than that. Step #2: Provide a library of standard objectsPage driven organizations do tend to know what kinds of information their page designers will put on the pages--they just don't know where it's going to go.For example, a page designer creating a page consisting primarily of $Search results might decide to throw up some $News.Headlines in the corner. They might also choose to use a banner $Ad on the page as well. Ordinarily, the page designer would have to work through engineering, requesting that these objects be put into the Context so that they can be used on each page. It would be better if they automatically sprung into existence, just because the page designer made use of them. WebMacro has a facility to support this, this called ContextTools. The ContextTool APIYou can have a set of objects that are automatically instantiated in your Context on first use. These objects are called ContextTools. You write your ContextTool objects and add them to the WebMacro.properties file. They are then available, automatically, for use on any page.A ContextTool implements this interface: public interface ContextTool { Object init(Context c); }The first time the ContextTool is referenced on a template its init() method will be called. Whatever object is returned by init() will be placed into the Context exactly as if the servlet programmer had done a Context.put(ContextTool.init(context)) prior to invoking the template. Here are the important points about ContextTools:
For example, if a suitable SearchTool were registered in WebMacro.properties then template writers could write code like this on every page: <ul> #foreach $result in $Search.Results { <li><a href="$result.URL">$result.Name</a> } </ul>The $Search object could inspect the form data submitted to the page (finding that in the context), and the getResults() method would return suitable search results. What's right for you?Whether you will prefer a page driven development approach, or a code driven approach, or something in between is up to you. WebMacro will support you either way.Both approaches preserve the Model/View/Controller separation bewteen controlling servlet code, the template view, and the back-end model. The only difference is the mechanism by which the model data gets into the context: did the controller put it there? Or was it loaded on demand by a tool? | |
BACK | UP | NEXT |