If you are using Magnolia I have integrated Magnolia with a grails application recently. I created my own mechanism that works through JNDI to access a Magnolia session. As more of a guess than a well researched design, I'm pooling sessions with the open session in view pattern. This seems to work pretty well for me. I'm curious if you the pooling of JCR sessions is really necessary or a case of overkill?
On Wed, Nov 12, 2008 at 7:29 AM, srawilliams <[EMAIL PROTECTED]> wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
