Obviously, we can't predict every possible use case ahead of time.
On Jan 16, 2008 2:56 PM, David Kendall <[EMAIL PROTECTED]> wrote: > I would like to have a way to force tapestry to flush/reload its caches > and I am wondering how best to get such functionality incorporated into > the Tapestry 5 framework. I am not sure what the best forum is to post > suggestions around T5 so I thought I would start here. If there is a > more appropriate venue please point me in the right direction. > > My specific use case is that I have built functionality to load some > templates from a content repository. I basically do this through a > custom class loader - so the source of the templates is largely > transparent to tapestry. However - when a template in the repository > changes I need a way to tell tapestry to reload. This is much like the > existing logic that reloads the caches when a template file changes. > > In attempting to implement this I decorated the ComponentTemplateSource > service with logic to query the content repository for changes. However > - my implementation was blocked by the fact that the UrlChangeTracker is > constructed directly by the ComponentTemplateSourceImpl class. This > means I have no way to force the ComponentTemplateSourceImpl to flush > its cache. It seems that UrlChangeTracker might easily be implemented as > an IOC service which would make it available to other services that need > to handle loading of templates. Such services could then force a cache > flush through the forceChange() method. An alternative approach might be > to add a forceChange method to the ComponentTemplateSource interface. > Different instances of URLChangeTracker do track different things; a single shared service would not be ideal. > We are very successfully using Tapestry 5 for the next generation user > interface of our product. We love how flexible and customizable the > framework is. It fits in very well with our need to be able to customize > and co-brand our UI. > > I am somewhat new to active participation in open source and am > wondering if there a best practice around lobbying for a feature request > in a project like tapestry. I am pretty familiar with the tapestry > source by now - so one option would be for me to code the update I would > like to see and submit a patch. However - I am sure there are multiple > approaches to build the functionality I want to see - so it would be > helpful if someone familiar with the internals of the caching logic > could provide some feedback if my approach is the optimal. Supporting your situation could be accomplished by addining a new method, flushCache(), to the ComponentTemplateSource interface. Alternatively, you may be able to replace the CTS service with your own. A contribution to the Alias service will replace Tapestry's built-in implementation with one of your own. You can re-use the implementation class, but pass in an URLChangeTracker explicitly, so that you can use the forceChange() method. Tricky stuff, but doable. > > If there are other strategies that people here find effective please > suggest them. > > Thanks. > > David Kendall > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
