David Sean Taylor wrote:
>>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.
>
+1. I remember we have discussed this when we saw the similarities
between the PSML lookup and the template lookup strategies:
- locale information
- mime type
- user name/role/group, ...
> 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)
Thinking into this, I'm not completely sure that the ACL control should
not be in the accessed objects (PortletSet or Template throwing
exceptions), rather than in the lookup class. It is stronger, as the
classical exploits of passing the "wrong" path would not work.
> - 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.
>
If the TurbineTemplatingService was splitted into the "proper"
templating code and a "resource-lookup" service, it would do. Our
profiler would use the ResourceLookup service to look for psml, and then
load it, while our templating service would disappear, and instead we
would configure our lookup strategy into Turbine's
But the ResourceLookup should take a RunData as argument, to extract
dynamic Locale and mime type information from it. DynamicResourceLookup?
Just Random Thoughts :)
> - david
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
