Hi Manuel, in seedsnipe we have rendering functions which could be provided by services. An approach would be provide such renderin functions in ssp.
I don't think using the map for rendering process variables would be the right place. Rather a separate map for those fumctions. Cheers, Reto ----- Original message ----- > Hi Reto, > > Sorry, my previous mail seems to be ambiguous. My proposal was not about > a caching mechanism itself, > but a way to provide it to a ssp. As you say ssps cannot access OSGi > services. I propose to circumvent > this by filling services (implementing a certaing service interface) into > the global map. This would be done > by the GenericGraphNodeMBW which would reference the services to be > filled in. The caching service would > be just one instance of such a service, but with this mechanism all > kinds of services could be provided to > ssps (E.g. the script executor). > > As for the caching mechanism itself. I implemented a generic way for > caching in org.clerezza.cms.cache. > With it it should possible to realize the features you described. > > Cheers, > Manuel > > On Sat, Sep 11, 2010 at 12:43 PM, Reto Bachmann-Gmuer > <[email protected]>wrote: > > > Hi Manuel > > > > If I understand you correctly your proposal is about caching arbitrary > > java objects that would otherwise need to be generated multiple time. > > > > This is relevant for ScalaServerPages as these cannot access OSGi > > services directly which could otherwise take care of computation of > > the objects as well as appropriate caching. I think for ssps and other > > renderlets we should introduce mechanism that allow caching of the > > resulting snippet. A renderlet should be able to indicated how long > > the result it generates is valid and also which modifications to an > > underlying graph causes the otherwise cacheable result to be > > invalidated. > > > > Before addressing this issue I think we should: > > - select the renderlet based on a global type priority list (same as > > for typerendering), generate this typepriority list taking into > > account ordering constraints (provided typically by bundles) in a > > similar fashion as the ordering of documentation > > > > And maybe also: > > - make it easier to register ssps (withouit needing service call) and > > have them as well as statically served file easily overwritable at > > runtime (preventing the need of redeploys when fine-tuning the > > frontend). > > > > Cheers, > > reto > > > > On Thu, Sep 9, 2010 at 2:22 PM, Manuel Innerhofer <[email protected]> > > wrote: > > > Hi Reto, > > > > > > As you know, we want to use caching within a .ssp. We are thinking > > > right > > now > > > about implementing the cache using static methods, which is > > > unfavorable > > in > > > my opinion. I was thinking about another mechanism to provide a cache > > object > > > to the .ssp and I'd like to hear your opinion on an idea I came up > > with. You > > > recently implemented the global map > > > (https://issues.apache.org/jira/browse/CLEREZZA-271). I thought we > > > could pre-fill the global map with objects (e.g. the cache object). > > > These > > objects > > > would implement a certain interface (something like > > > GlobalTypeRenderingObject) and expose themselves as OSGi services. > > > The GenericGraphNodeMBW would reference these services and fill them > > > into the global map. > > > What do you think? Of course the input of everyone is welcome! > > > > > > Cheers, > > > Manuel > > > > >
