Reviving my old thread for continuity - just picking up the same train of
thought again. The theme, building some form of 'registry' for zones on a
given page. Either on a per session or environment basis; whatever is seen
to be most suitable.
The following example is for the sake of argument and we are making the
assumption that a suitably semantic situation has arisen where it is
entirely logical to want to update zones in this way.
Let's say we have this component structure:
<t:a>
<t:b />
<t:c>
<t:d />
</t:c>
</t:a>
All of these components declare one or more zones in their templates, need
to perform multiple zone updates per event and rely on each other in various
ways.
An event is triggered in d, it needs to update a zone in its parent
component c as well as in component b. So: d needs a reference to one of c's
zones and one of b's zones so as to either call
ajaxResponseRenderer.addRender(clientId, zone) or return the zone from the
event handler.
The current way we do this is by passing c's zone into d as a parameter. To
get at b's zone we have to create a getter for the zone in b, inject
component b in a, create a delegate getter for the zone in a, pass the zone
into c as a parameter and then pass the zone into d as a parameter.
The only nice thing about this whole process is in terms of refactoring, if
a zone is removed or renamed, we'll know about it via exception at render
time and won't push a broken site to production. :)
So I had a half-baked idea about having some sort of registry for zones;
- components register the injected instances of their zones, something like
Map<String, Zone> where string is ideally the zone's clientid.
- it will hold AjaxResponseRenderer.
- if a component needs to render a bunch of zones in a bunch of places, it
calls the registry's render method and supplies the string keys of the zones
that need to be updated.
The nasty thing about this is, if we remove or rename a registered zone,
we'd need to make sure we check all of the hierarchy of components for
references to rendering of that removed or renamed zone.
So I ask you fellow Tapestry people - any ideas what do?
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Elegant-Handling-of-Multiple-Zones-in-Deep-Hierarchies-of-Components-tp5717698p5719297.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
