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.
>
As far as I understand the issue, the JetspeedTemplateService was created
only for NLS based directory traversal so that in effect, we would have
this kind of template traversal:
/base/sub/html/en/default.vm
/base/sub/html/default.vm
/base/sub/default.vm
/base/html/en/default.vm
/base/html/default.vm
/base/default.vm
/html/en/default.vm
/html/default.vm
/default.vm
so basically we need either to itegrate this in the base Turbine functionality
(but I think it would be considered too expensive by the HTML only users) or
have protected method in TurbineTemplateService dealing with tree traversal so that
we would only have to subclass TurbineTemplateService and reimplement this method.
I'm not familiar with either the JetspeedTemplate code (see Ingo) or the new Turbine
template code but I guess it should be pretty easy to work out the issues along these
lines.
> 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?
>
The Profiler is supposed to make the mapping
user request -> portal resource
(BTW with the current default PSML files implementation, this also requires
a directory tree traversal)
Implementing the tree traversal in Profiler would be hack right now because
the turbine templating system is not aware of a Profiler but if we consider a
mid-term solution it is certainly possible to envision a reworked templating
structure which would be closer to the Velocity one, with the following services
cooperating:
Profiler: request -> resource request descriptor
ResourceEngine: resource broker dispatching requests to specific resources providers
*TemplateEngine: template resource provider: maps a resource request descriptor to
to a resource and returns the resource
That would enable integration of PSML "templates" as a specific kind of resource that
a PortalLayoutService knows how to process and render...
> Thoughts? I will do whatever is needed to get what you need into
> turbine to get rid of this last incompatibility.
>
--
Raphael Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
