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 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
