> 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?
Yes, I think this is a good idea.
Both templates and psml are resources, and a profiling service could be used
to locate them.
The profiler also has some features that may be useful for templates:
- anonymous/user/group/role resources
- ACL-based control to these resources (not yet complete)
- caching of resource names (so a directory tree seach isn't required)
I believe the new TurbineTemplatingService also has some new features:
- multiple template path roots
- caching of templates
We have been playing around with a decoupling of the 'ConfigStore' part of
the profiler, as can be seen in the new psml branch under
org.apache.jetspeed.customization. The idea is that the profiler handles
taking a request, and mapping it to a 'neutral' Profile object - see
org.apache.jetspeed.customization.om.ConfigInfo. The ConfigInfo is then
passed to a ConfigStoreService, which determines from the ConfigInfo how to
return the resource.
The question left in my mind is: how much of this functionality should be
moved up into Turbine?
The profiling service is currently plugged into the modules.screens.Home
class.
This is where Jetspeed gets the PSML resource, and then outputs all of the
portlet content into the stream.
We could still make use of a common profiler at this point, as well as
making use of the same profiler to find template resources.
A lot of the 'ConfigStore' like functionality, plus caching, is already
built into the TurbineTemplatingService.
So to make 'common' profiling and configstore services, there is a lot of
refactoring to do.
- david
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
