Hi Paul, I briefly looked into page loading a few weeks ago when I looked into creating a 'hot' page loader (one that would reload the page only if it detected that the template or xml file timestamp had changed) to provide JSP style reloading in a live webapp, without the performance penalty of completely disabling caching..
Although Tapestry caches loaded pages read from an xml and html template by default, doesn't mean you have to do it that way as well. You probably need to create your own PageSource and PageLoader implementation that instead of parsing a .page template file, just builds the page structure dynamically from whatever modules are in use. Another option would be to make use of the 'Delegator' component for dynamic areas. This allows you to delegate a component's rendering competely to java code. A third option of course is the standard Block and RenderBlock components. Hope this is useful. regards, Scott On Thursday 30 March 2006 09:35, Paul Russell wrote: > Hi Guys, > > I've been a silent user of Tapestry off and on since version 4.0 was > late-alpha/early-beta. That doesn't sound long, but it's been long > enough for me to learn a fair bit about the framework, and to be very > impressed with it. The reason I got /into/ tapestry in the first > place was actually more to do with Hivemind than Tapestry. I've been > pushing a plug-in based approach for about 4 years; Howard thankfully > saved me the effort of having to write a framework to actually /do/ it. > > Now I'm in a position where I'm trying to do both. I'm in the middle > of building a proof of concept for a green-field Tapestry app that > needs to demonstrate the ability to make /extremely/ modular > applications where - amongst other things - individual areas > (components) on screens can be contributed by modules, dynamically, > on the fly, depending on context. Yes, I'm clearly mad, but there are > reasons I'm taking this to the extreme I am. Effectively, what I'm > proposing is something very eclipse like: 'Perspectives' will be > created, and views will be contributed to these perspectives from > other modules. Furthermore, decorations and panels will then be > contributed to these views to extend their behavior. All very Hivemind. > > The complexity here is that effectively I want the ability to embed > whole components, designed using standard tapestry semantics into > each other. The reason for this is that within this particular > application, embedding components in this manner is going to be the > norm, not the exception, so building a whole new component framework > around IRender is not the route I want to take if I can avoid it! > > I've been trying to work out how to achieve this goal for a few days > now, and I'm not seeing an easy way to achieve it, so wanted to ask > the experts. What I've considered so far is: > * Creating a component that (indirectly, via contributions and > services that actually work out which component to create) calls the > PageLoader.createImplicitComponent method. Unfortunately, this method > adds the component to the 'containing' component permanently, the > component can't change 'per request', which it will potentially have to. > * Creating a entirely separate 'component loader' service that > replicates the functionality that the pageloader has, but doesn't > actually add the component to its container. The issue here is that > it (a) it feels too complicated to be the 'right' way, and (b) I'm > not clear if this totally breaks the tapestry architecture -- can a > component /exist/ without a parent component? > * Creating something that looks and works a lot like a component, but > has a less static lifecycle. My concern here is that again, that > sounds like a pretty major departure from where Tapestry is now, so > I'm concerned that taking this tack might just make the solution un- > maintainable. > > I guess the fundamental issue here is that it appears that Tapestry > is designed to load the entire page statically once, and then re-use > it. There doesn't appear to be a provision for elements of that UI to > be constructed 'on the fly', which seems a shame. There are already > elements of the standard framework that 'feel' like they could > benefit from this ability (the 'describe' framework, for a start), > and I can see the potential increasing as more people get into Hivemind. > > Has anyone else thought about this? Has anyone got any suggestions > for ways to think about this that I'm missing? > > Cheers, > > > Paul > > --------------------------------------------------------------------- > 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]
