Hi,
Those of you who are reading the CVS committs will have noticed
that I reorganized the way how the (Jsp) templating is done in
Jetspeed.
In our alpha1 most of it was done "manually", not much advantage of
turbines templating service has been taken (e.g. locating template
file, checking if it really exists).
Let me briefly summarize how templates are handled in turbine:
* Besides "screen" and "action" there is a third keyword for URLs,
"template". It's used to set the screenTemplate, i.e. the template
that produces the content that used to be produced by the
screen via Ecs (e.g.: /portal/template/login).
* Screens no longer produce output, they can be used to do
some preprocessing and choose a screenTemplate.
-> I can't see any use in screens any more, as this way
they are just another action. I think we don't need to use
screen in the future, just template(s) and action(s) should be
sufficient. (Or am I mising something?)
* The SessionValidator for templates makes sure that only one of
both are set via the URL, screen _or_ template. If both are set,
the screen is set to "null".
* The TemplatePage
- uses the TemplateService to verifiy that the screen template
really exists, otherwise the error is set to the error screen
(e.g. JspErrorScreen).
- sets the layout to the default layout (e.g. JetspeedJspLayout).
- tries to find a layout template that matches the screen template
(e.g. if the screen template is "/screens/login.jsp", it is seached
for the layout template "layouts/login.jsp"). If it can't be found,
the default layout is choosen (e.g. layouts/default.jsp).
This means that theoretically, every screen could have it's own
layout (but I dont't think we'll need this feature).
* There is a TemplatePage _specific_ to the templating system,
it extends the Template Page (e.g. JspPage). It is used to store
objects in the template context that can be used by the template
later on (e.g. the toolbox).
* The flow is then like (at the example of Jsp templating):
req-->TurbineServlet
| [..]
|--> SessionValidator
| [..]
|--> Page.doBuild() [ DefaultPage ]
|--> doBuildBeforeAction() [ JetspeedJspPage ]
|--> execute Action
|--> doBuildAfterAction() [ JetspeedTemplatePage ]
|--> Layout.doBuild() [ JetspeedJspLayout ]
|--> execute layout template [ layouts/default.jsp ]
|--> include navigation(s) [
navigations/top.jsp ]
|--> include screen [ screens/login.jsp ]
(If the screen is the Ecs.jsp, it uses the ecsScreenTag to jump
back in the code and execute the (ecs) screen, in this case
to really produce output. We need this hack currently for all
screens that display portlets.)
I subclassed turbines TemplatePage to make it mime type aware,
i.e. the template name is prefixed by >preferredType+"/"<. So in
the above example the pathes would really be layouts/html/default.jsp
and screens/html/login.jsp or layouts/wml/default.jsp.
I moved the screens and navigations in respective subdirectories.
--> We therefore need own classes JspTemplatePage,
VelocityTemplatePage, etc doing just the same as those in turbine
but subclassing the JetspeedTemplatePage.
BTW, JetspeedTemplatePage is a bit messy at the moment, I did
some "enhancments" that meanwhile found into turbine - but not
into TDKa11. I'll clean it up after the next turbine update. (It'd be
probably saver to subclass the template service instead of the
TemplatePage.)
What I'm missing at the moment (however I haven't even looked
into it) is a comfortable error handling in turbine that allows to
pass an error code that is resolved into a specific error template
name. But it might already be in turbine, just didn't look for it yet.
Just to keep you informed,
ingo.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
