I know everyone is busy, but if you have any interest in the use
of Templates (WebMacro, FreeMarker, Cocoon, JSP) in Turbine
I'd appreciate your feedback on this.
I've been thinking of a way to standardize how Turbine handles
templates so the specific type of Template (WebMacro, Freemarker,
Coccon, etc...) is isolated to their respective Service and a Screen.
This is so we don't end up with a Page for each, special configuation
for each etc.... I've also been looking at how we can make templates
more configurable and map many templates to one screen.
Here's what I've come up with so far:
* Use the parameter "template" as a standard way of passing template
names around Turbine. The value of template DOES NOT have to be the
actual name of the template page. For example, template=/dave/AddForm
can map to addform.wm.
* Add a hook to DefaultPage that looks for the parameter "template"
(just like in FreeMarkerSitePage). if (template == null ) continue as
normal, otherwise use the TemplateService (see below).
* The TemplateService maintains a container of TemplateHolders that
have mapping information about a template. This mapping information
comes from an XML file. Here's the structure I have in mind:
<templates>
<template_holder name="/dave/AddForm"
screen="Add"
layout="Default"
template="addform.wm"
scheme="https"
role="add_user"
permission=
service="WebMacro"
template_holder/>
</templates>
Note some of the other attributes of template_holder - especially,
role, permission. This is so if you have many templates that use one
Screen you can still control access by setting the value in the
Template holder configuration file.
* The DefaultPage calls the TemplateService. The Service looks up the
TemplateHolder object for the name passed in template. Then from the
TemplateHolder the DefaultPage can get the Screen, Layout and
forward the TemplateHolder object in the RunData. The particular
Screen can then use some of the other information in the TemplateHolder
to maybe check access rights, etc...
So, overall the benefits of this are:
1. semi-standardized way of handling templates
2. The ability to map names to templates.
3. The ability to map many templates to one Screen.
4. The ability to use more than one Service at the same time
(For example: Coccon and JSP) from one configuration file.
5. The ability to maintain access control in the case of
many templates to one Screen.
Thoughts?
--
Dave
[EMAIL PROTECTED]
your flame > /dev/null
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
