> 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
Hi Santiago,
Just wanted to get your thoughts on this: I will try to remove the
JetspeedTemplateService, and call the JetspeedProfiler from somewhere in the
pipeline (We are still determining the best place) before the
TurbineTemplatingService tries to retrieve the template.
This will give us one profiling service on the front-end to handle
mediatypes, nls, and fallback algorithm, with the TurbineTemplatingService
doing the actual resource retrieval/caching for templates, and the
JetspeedProfiler (still) doing the actual resource retrieval for PSML (as
discussed, the Profiler could later be split into two services, such as a
PSMLService or ConfigStoreService perhaps)
This is all under the new TDK, so there are other issues to work out before
committing which may take a while
> > - 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.
>
Sorry, I don't understand what you are saying here.
Probably because I am sleepy.
We can talk about this tomorrow/tonight, later...
-- David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
