I meant:
http://jumpstart.doublenegative.com.au/jumpstart/together/gracefulajaxcomponentscrud/persons
Cheers,
Geoff
On 15/01/2013, at 12:31 AM, Geoff Callender wrote:
> I would recommend using event bubbling. Keep component d unaware of its
> container. It should bubble up an event and let c and a decide whether there
> is a zone they should refresh.
>
> For an example of this philosophy have a look at
>
>
> http://localhost:8080/jumpstart/together/gracefulajaxcomponentscrud/persons .
>
> In it, PersonList and PersonEditor do not know about each other, nor do they
> know about their container, Persons, and nor do they know they are in zones.
>
> - When you modify PersonList's filter, it bubbles up event "filter" and the
> container does ajaxResponseRenderer.addRender(listZone);
> - When you select one of PersonList's entries, it bubbles up "selected" and
> the container does
> ajaxResponseRenderer.addRender(listZone).addRender(editorZone);
>
> Only Persons knows that there is a list and an editor, so it makes sense for
> it to coordinate the responses to the events.
>
> In your case it will be a bit trickier if a zone inside b needs to be
> refreshed, but maybe you could move that zone up into a, around b? Nested
> zones would be tricky, too, but to date I've always been able to structure
> the components in a way that avoids them.
>
> Cheers,
>
> Geoff
>
> On 15/01/2013, at 12:03 AM, llama-king wrote:
>
>> 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
>>
>
