At 16:05 05/11/01, Jason van Zyl wrote:
>Hi Guys,
>
>I am workng with David to try and get Jetspeed working with next
>release of the TDK which is the 2.1 version of Turbine that will
>be released on June 4th.
>
>There is one thing that needs to be fixed before this can happen
>so I wanted to get some input.
>
>Right now the only thing that doesn't work is the Template service
>that you guys subclassed ... The template service in turbine now
>supports multiple template paths, but this might not be required
>for what you need if I understand the problem correctly.
>
>If I understand you are using your template service to use
>a localized set of templates for a certain mime type, yes?
>If I have this wrong could someone explain to me what exactly
>happens in your template service. I will try to factor in what you need
>to
>the TurbineTemplate service so that our releases on June 4th
>will cooperate with one another.
Cool, thanks for your help.
I attach two older mails of mine, that might explain a little, what we are
doing.
The idea was basically that the Template service searches a direcory
"bottom-up" until it finds a specific template file. We use this to get
NLS/MimeType support by organizing the templates in a way that the most
specific is "deepest down" in the directories.
If you now the old template service: All I changed was the
parseScreenTemplate method - nothing else. I think the most imporetant
change was that all directories in the path were searched not only for the
default template but also for the one that has been requested.
Please ask if you need detai�led information. I'll try to help as good as I
can.
ingo.
>I must say I don't fully understand how all of Jetspeed works, but
>would it be possible to take information from the Profiler to
>construct a template path that takes into account the locale
>and the mime type?
>
>Thoughts? I will do whatever is needed to get what you need into
>turbine to get rid of this last incompatibility.
>
>Thanks,
>
>--
>jvz.
---------------------------------------------------------------------------------------------------------
At 19:03 03/08/01, ingo schuster wrote:
>I checked in a first version of the MLS code. Some German pages are
>provided as demonstration.
>What I changed:
>* The Jetspeed SessionValidator determines the user locale (browser
>settings or default defined in TR.p) and stores it in the user's TempStore
>as "locale" .
>* I copied the TurbineTemplateService to JetspeedTemplateService - the
>only method that has changed is "parseScreenTemplate", but I didn't manage
>to subclass the TurbineService in a simple way - too many "privates" (Will
>discuss this on the turbine list).
>The service now does a fallback strategy when it can't find a template.
>This was already done for layouts, but not for screens... To give an example:
>A template name "/html/en/US/IE/mytemplate" would result in a search for
>following files (in the given order):
> 1. /html/en/US/IE/mytemplate
> 2. /html/en/US/mytemplate
> 3. /html/en/mytemplate
> 4. /html/mytemplate
> 5. /mytemplate
>* I modified JetspeedTemplatePage and JetspeedJspLayout to work with the
>new code (minor changes).
---------------------------------------------------------------------------------------------------------
>Date: Thu, 08 Feb 2001 15:26:13 +0100
>To: "JetSpeed" <[EMAIL PROTECTED]>
>From: ingo schuster <[EMAIL PROTECTED]>
>Subject: [Info - long] Templating System
>
>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.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
