on 4/15/00 12:29 PM, dave bryson <[EMAIL PROTECTED]> wrote:
> 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.
+1
> * 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.
Ok...
> * 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.
-1. I don't want to have to make someone edit a single file (or any files)
outside of the system in order to define new pages.
The example above would not work for a distributed environment at all with
multiple people adding pages to the system. It also would not work for dummy
HTML designers who simply want to add a new .wm file to the system to make
them edit something like this. We *need* to simplify things for these people
otherwise this software isn't going to fly...
> So, overall the benefits of this are:
> 1. semi-standardized way of handling templates
+1
> 2. The ability to map names to templates.
-1. Adds to confusion.
> 3. The ability to map many templates to one Screen.
+1, but can be done another way I'm sure...
> 4. The ability to use more than one Service at the same time
> (For example: Coccon and JSP) from one configuration file.
Already can do that.
> 5. The ability to maintain access control in the case of
> many templates to one Screen.
+1, but can be done another way I'm sure...
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
