RE: T5 Proposal: Provide a Mechanism to Force Cache Flushing
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]
Re: T5 Proposal: Provide a Mechanism to Force Cache Flushing
On Jan 18, 2008 6:20 PM, Daniel Jue [EMAIL PROTECTED] wrote: This is bordering on a way around the static structure, dynamic content vision! Not that we need to weasel around that vision to make great applications, but this is a way to have the best of both worlds--the performance of semi-cached templates/classes with the flexibility of live structure editing. That could be dangerous. It would be like continously re-deploying your application. You will hit problems where version #1 of a page uses one structure, reflected in its action URLs, but by the time you submit, it's version #2 and the action URL no longer makes sense. -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 Proposal: Provide a Mechanism to Force Cache Flushing
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]
Re: T5 Proposal: Provide a Mechanism to Force Cache Flushing
This is bordering on a way around the static structure, dynamic content vision! Not that we need to weasel around that vision to make great applications, but this is a way to have the best of both worlds--the performance of semi-cached templates/classes with the flexibility of live structure editing. I mentioned svn-like versioning, since you really want a set of all classes that work together, which may go beyond a page/template pair. (like new selection model or value encoder). I guess there will always be limitations on this kind of design, since things like this can happen: User on old version of a form on Page X v1.0 Admin changes published version of the Page X v1.1 User submits from old Page X v1.0 -assume it will crash But in general it's really cool. Dynamically supplied or generated CSS. The idea of uploading zipped components to a live system, all via the app's system console itself, like Joomla/Mambo/other PHP CMS's. Live editing of templates structure. Basically any roadblock I can think of that was due to the Tapestry cache being sacred. I guess output of the application is a different beast, but the high level concept shares some parts: configurable I/O I think most people have desired outputting a completed page to a stream for html email generation. Maybe there are other options? I've had enough espresso for tonight. Thanks for putting up with my rantings. ;-) On Jan 18, 2008 8:50 PM, Michael Lake [EMAIL PROTECTED] wrote: This is precisely the stuff I've been working on for the past few weeks. I too am successful with pulling templates from a DB and so far, so good. I'll need to dive back into the code to see if there's a way to do a template parse and be able to catch an exception if there's an error. in fact today I was hammering out ideas for the svn-like versioning/ staging stuff. -mike On Jan 18, 2008, at 8:03 PM, Daniel Jue wrote: dangerous ideas This could be an interesting way of running an application straight from a DB backend, where the DB can act as a versioning system if needed. A new updated class or template is uploaded to the DB, and the flushCache() causes the CTS service to pick up the newest template versions. This could provide CMS type publishing of individual pieces (components/pages) by version. Then you can still roll back to a previous version of a class/template if you want, all via a web UI. Kind of like SVN. Can the flushCache() flush only specific classes/templates? Or does it flush everything? On Jan 18, 2008 6:14 PM, Howard Lewis Ship [EMAIL PROTECTED] wrote: 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
Re: T5 Proposal: Provide a Mechanism to Force Cache Flushing
dangerous ideas This could be an interesting way of running an application straight from a DB backend, where the DB can act as a versioning system if needed. A new updated class or template is uploaded to the DB, and the flushCache() causes the CTS service to pick up the newest template versions. This could provide CMS type publishing of individual pieces (components/pages) by version. Then you can still roll back to a previous version of a class/template if you want, all via a web UI. Kind of like SVN. Can the flushCache() flush only specific classes/templates? Or does it flush everything? On Jan 18, 2008 6:14 PM, Howard Lewis Ship [EMAIL PROTECTED] wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 Proposal: Provide a Mechanism to Force Cache Flushing
This is precisely the stuff I've been working on for the past few weeks. I too am successful with pulling templates from a DB and so far, so good. I'll need to dive back into the code to see if there's a way to do a template parse and be able to catch an exception if there's an error. in fact today I was hammering out ideas for the svn-like versioning/ staging stuff. -mike On Jan 18, 2008, at 8:03 PM, Daniel Jue wrote: dangerous ideas This could be an interesting way of running an application straight from a DB backend, where the DB can act as a versioning system if needed. A new updated class or template is uploaded to the DB, and the flushCache() causes the CTS service to pick up the newest template versions. This could provide CMS type publishing of individual pieces (components/pages) by version. Then you can still roll back to a previous version of a class/template if you want, all via a web UI. Kind of like SVN. Can the flushCache() flush only specific classes/templates? Or does it flush everything? On Jan 18, 2008 6:14 PM, Howard Lewis Ship [EMAIL PROTECTED] wrote: 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] - 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]
