Howard - thanks for your reply. > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Friday, January 18, 2008 3:14 PM > Obviously, we can't predict every possible use case ahead of time.
Very true. It's notable that we have built a whole lot of functionality on T5 without encountering any significant limitations. This is the first real stumper we have come across - not bad considering this is very much an "outside the box" use case. For this reason - please regard my comments / questions as a testament to the flexibility of the framework. > Different instances of URLChangeTracker do track different things; a > single shared service would not be ideal. That's fair enough - and something I didn't spot before I just looked at the code. However the pattern of the XXXSourceImpl classes explicitly constructing an instance of UrlChangeTracker may be something to revisit. Such a pattern creates a tight coupling that inhibits the extensibility of the framework. As an alternative - perhaps a UrlChangeTrackerSource service could be injected into these services - which would act as a factory for UrlChangeTracker instances. Such a service could then be decorated or aliased as needed. I am sure there are other approaches that could achieve the same result. > Supporting your situation could be accomplished by addining a new > method, flushCache(), to the ComponentTemplateSource interface. This would be fine - it seems like it would be easy to implement and fitting. Probably a similar method should be added to the other XXXSource services that cache their contents. > 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. That's a good idea - and something I had not considered. The only downside of this is that the CTS service constructor that takes an explicit UrlChangeTracker instance has package visibility right now - so I assume I would need a class in my source code that would be in the org.apache.tapestry.internal.services package. This would be a little ugly - but probably acceptable as a temporary work around if we could eventually get that constructor given public visibility. Let me know if I can help in any way. Thanks again. David Kendall --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
