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]
