Hi Mike, Did you get anywhere with this. If you need some collaboration, I am about to try and solve the same problem.
Sean I believe I'm working on what you seek. I'm working on a project which extends tapestry 5 to pull page/ component templates from an external data store. Where Tapestry pages are normally pulled from the classpath: or the context:, I've added another option(http:) which pulls page/component templates from itself(localhost) on a separate(non-tapestry) servlet app. While this has the added work of opening another http connection for the page/component being accessed, the resulting template is stored in tapestry's cache and could be invalidated when an update is made to the database. I'm trying my best to do this without making changes to tapestry's base code. Now that I've gotten familiar with the IoC container, I'm comfortable enough to inject and override a couple of tapestry's core services. If I'm lucky, creating a tapestry-centric cms should be as easy as dropping a jar in with tapestry which will auto-load its tapesty-specific AppModule class. I know..I'm tooling with services from behind the org.apache.tapestry.internal curtain while the framework itself is technically unreleased. I'm running a risk here, but hopefully the interfaces won't change too much for the few services I'm overriding. So far I'm achieving this by overriding the following services with ioc: http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/PageTemplateLocator.html http://tapestry.formos.com/nightly/tapestry5/apidocs/org/apache/tapestry/internal/services/ComponentTemplateSource.html without touching the base code, I'm able to get tapestry to pull the templates from something other than the context or classpath. It's a mini-success. What I really envision though, are page/component templates that are specific to the hostname being used in the request. I'm able to make this work by contributing my own ComponentClassResolver which uses an ugly hack to tack on the hostname to the primary key used in the cache. (luckily it's one of the few services where I can extend howard's implementation and just override a couple methods - many of the other services are marked "final") I'm halfway there, http://localhost:8080/start and http://127.0.0.1:8080/start now pull two separate page templates from the database and work with tapestry's cache. What I REALLY want is the ability to change the location component templates are "searched for" to be in the following places in the following order: 1 - the database(using http: and a servlet, or perhaps jndi?) 1a - by hostname, page name and component id 1b - by hostname and page name 1c - by hostname 2 - fall back to its classpath resource in ".components." package eg: http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage:myloginform_en.tml http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm:MyLoginPage_en.tml http://localhost:8080/templateservlet/localhost/org.example.app.components.withexternaltemplates.LoginForm_en.tml classpath:org .example.app.components.withexternaltemplates.LoginForm_en.tml classpath:org.example.app.components.withexternaltemplates.LoginForm.tml (yeah, all the locale stuff should also stick) The real-world example: we are to maintain dozens of sites which each use a login form. The logic behind the login form will not change that much between sites but the appearance for each site should be different. The application programmer creates a component class (LoginForm) and a "functioning" component template which are developed and packaged together. Through a web-based page builder, the web designer might create a new site which needs a login form. Wouldn't it be cool if the designer could drag and drop from a palette of "web-editable" tapestry components to the page? When the component is dropped on the page, it would use the "most matching"(based on hostname, page, id) component template available but always be able to fall back on the original login form template(from the classpath) which was written by the application programmer(and is most likely UGLY). If the designer wanted to change the appearance of the login form, they would click an admin-only control which would allow them to edit a copy of the programmer's TML(from the classpath) which would be saved to the database. Upon saving, an invalidation event would fire, and tapestry's template cache would clear, and thus, the next request for that component would bring its updated template down from the database and be stored in tapestry's cache. I'm thinking these "special" components should be treated almost as portlets for a portal system. Each faux portlet could be "configurable" from the web with persisting configuration options(in addition to being able to modify the template). Could some core developers chime in on whether they think this is feasible? anyone have any thoughts on this? If someone wants to collaborate with me, I'd be happy to do so. -- View this message in context: http://www.nabble.com/Web-Content-Management-Systems-tp14212538p20459391.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
