You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by llama-king <p....@albourne.com> on 2012/11/06 10:33:19 UTC
Elegant Handling of Multiple Zones in 'Deep' Hierarchies of
Components
Hello all,
I was wondering what everyone's preferred approach to using multiple zones
in a hierarchy of components was. I'm not pleased with the current pattern
we use and figured someone might have come up with a better approach.
We run a complex page; having a single zone proved very slow.
We increased the number of zones to encompass specific components so as to
speed up the page; this worked but as a side effect we have large numbers of
component parameters dedicated to zones and thus long chains of parameters
carried through a number of components.
We need to update (multiple) zones in multiple places throughout our
component hierarchy. One good example is a text alert that needs to be
updated by pretty much every component in the hierarchy and so we end up
passing the 'alert zone' as a parameter to every component that needs it.
I was imagining something similar to an object of session state that can be
initialized to hold on to the zone references and thus be injected where
required. Or perhaps as is the case with the zoned alert component, to have
it extend Zone and pass that around as a parameter (I already pass the
injected Alert component as well as the related Zone all over the place;
this allows me to centralize reusable alert messages for the component
hierarchy, makes breakages more manageable).
It's quite an open question - I do hope to hear some of your approaches!
Thanks again!
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Elegant-Handling-of-Multiple-Zones-in-Deep-Hierarchies-of-Components-tp5717698.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of Components
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think you'll see a lot more can happen in 5.4 where the specifics get
handled are sorted out on the client; much like in 5.3 the use of the
zone="^" parameter (to mean: update the immediately enclosing zone).
In any case, if you have lots of zones, you will almost certainly want to
supply a specific client-side id for each zone so that you don't get into
the business of passing the Zone instance around, just to constantly
extract its dynamically allocated client id.
On Tue, Nov 6, 2012 at 11:39 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Starting in Tapestry 5.4, the order of calls to
> AjaxResponseRender.addRender() is maintained for execution on the client;
> the big problem with deeply nested zones is that when updating multiple
> zones in one go, the order (in 5.3 and earlier) was not defined, and if
> zone A contains zone B, but zone B is updated first, then the results in
> the page don't match the expectations.
>
>
> On Tue, Nov 6, 2012 at 2:03 AM, Taha Hafeez Siddiqi <
> tawus.tapestry@gmail.com> wrote:
>
>> Why not use AjaxResponseRenderer ?
>>
>>
>> On 06-Nov-2012, at 3:03 PM, llama-king <p....@albourne.com> wrote:
>>
>> > Hello all,
>> >
>> > I was wondering what everyone's preferred approach to using multiple
>> zones
>> > in a hierarchy of components was. I'm not pleased with the current
>> pattern
>> > we use and figured someone might have come up with a better approach.
>> >
>> > We run a complex page; having a single zone proved very slow.
>> >
>> > We increased the number of zones to encompass specific components so as
>> to
>> > speed up the page; this worked but as a side effect we have large
>> numbers of
>> > component parameters dedicated to zones and thus long chains of
>> parameters
>> > carried through a number of components.
>> >
>> > We need to update (multiple) zones in multiple places throughout our
>> > component hierarchy. One good example is a text alert that needs to be
>> > updated by pretty much every component in the hierarchy and so we end up
>> > passing the 'alert zone' as a parameter to every component that needs
>> it.
>> >
>> > I was imagining something similar to an object of session state that
>> can be
>> > initialized to hold on to the zone references and thus be injected where
>> > required. Or perhaps as is the case with the zoned alert component, to
>> have
>> > it extend Zone and pass that around as a parameter (I already pass the
>> > injected Alert component as well as the related Zone all over the place;
>> > this allows me to centralize reusable alert messages for the component
>> > hierarchy, makes breakages more manageable).
>> >
>> > It's quite an open question - I do hope to hear some of your approaches!
>> >
>> > Thanks again!
>> >
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Elegant-Handling-of-Multiple-Zones-in-Deep-Hierarchies-of-Components-tp5717698.html
>> > Sent from the Tapestry - User mailing list archive at Nabble.com.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of Components
Posted by Howard Lewis Ship <hl...@gmail.com>.
Starting in Tapestry 5.4, the order of calls to
AjaxResponseRender.addRender() is maintained for execution on the client;
the big problem with deeply nested zones is that when updating multiple
zones in one go, the order (in 5.3 and earlier) was not defined, and if
zone A contains zone B, but zone B is updated first, then the results in
the page don't match the expectations.
On Tue, Nov 6, 2012 at 2:03 AM, Taha Hafeez Siddiqi <
tawus.tapestry@gmail.com> wrote:
> Why not use AjaxResponseRenderer ?
>
>
> On 06-Nov-2012, at 3:03 PM, llama-king <p....@albourne.com> wrote:
>
> > Hello all,
> >
> > I was wondering what everyone's preferred approach to using multiple
> zones
> > in a hierarchy of components was. I'm not pleased with the current
> pattern
> > we use and figured someone might have come up with a better approach.
> >
> > We run a complex page; having a single zone proved very slow.
> >
> > We increased the number of zones to encompass specific components so as
> to
> > speed up the page; this worked but as a side effect we have large
> numbers of
> > component parameters dedicated to zones and thus long chains of
> parameters
> > carried through a number of components.
> >
> > We need to update (multiple) zones in multiple places throughout our
> > component hierarchy. One good example is a text alert that needs to be
> > updated by pretty much every component in the hierarchy and so we end up
> > passing the 'alert zone' as a parameter to every component that needs it.
> >
> > I was imagining something similar to an object of session state that can
> be
> > initialized to hold on to the zone references and thus be injected where
> > required. Or perhaps as is the case with the zoned alert component, to
> have
> > it extend Zone and pass that around as a parameter (I already pass the
> > injected Alert component as well as the related Zone all over the place;
> > this allows me to centralize reusable alert messages for the component
> > hierarchy, makes breakages more manageable).
> >
> > It's quite an open question - I do hope to hear some of your approaches!
> >
> > Thanks again!
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://tapestry.1045711.n5.nabble.com/Elegant-Handling-of-Multiple-Zones-in-Deep-Hierarchies-of-Components-tp5717698.html
> > Sent from the Tapestry - User mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of Components
Posted by Taha Hafeez Siddiqi <ta...@gmail.com>.
Why not use AjaxResponseRenderer ?
On 06-Nov-2012, at 3:03 PM, llama-king <p....@albourne.com> wrote:
> Hello all,
>
> I was wondering what everyone's preferred approach to using multiple zones
> in a hierarchy of components was. I'm not pleased with the current pattern
> we use and figured someone might have come up with a better approach.
>
> We run a complex page; having a single zone proved very slow.
>
> We increased the number of zones to encompass specific components so as to
> speed up the page; this worked but as a side effect we have large numbers of
> component parameters dedicated to zones and thus long chains of parameters
> carried through a number of components.
>
> We need to update (multiple) zones in multiple places throughout our
> component hierarchy. One good example is a text alert that needs to be
> updated by pretty much every component in the hierarchy and so we end up
> passing the 'alert zone' as a parameter to every component that needs it.
>
> I was imagining something similar to an object of session state that can be
> initialized to hold on to the zone references and thus be injected where
> required. Or perhaps as is the case with the zoned alert component, to have
> it extend Zone and pass that around as a parameter (I already pass the
> injected Alert component as well as the related Zone all over the place;
> this allows me to centralize reusable alert messages for the component
> hierarchy, makes breakages more manageable).
>
> It's quite an open question - I do hope to hear some of your approaches!
>
> Thanks again!
>
>
>
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Elegant-Handling-of-Multiple-Zones-in-Deep-Hierarchies-of-Components-tp5717698.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of
Components
Posted by Lance Java <la...@googlemail.com>.
Have you considered an environmental?
http://tapestry.apache.org/environmental-services.html
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Elegant-Handling-of-Multiple-Zones-in-Deep-Hierarchies-of-Components-tp5717698p5717700.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of
Components
Posted by llama-king <p....@albourne.com>.
Hi Geoff,
Many thanks for the response (and for jumpstart)! I went ahead and branched
and converted one of our component hierarchies to use bubbling where
appropriate.
Well bubbling does help to an extent, it definitely is an alternative to
passing zones as parameters and I can see how it's possible to rethink
component structure (mostly by wrapping zone around component rather than
the other way round) to achieve this in more scenarios.
It still doesn't feel too clean though, especially with a lot of bubbling
going on and components used in multiple places in multiple hierarchies of
components.
I guess I'm still wondering at whether there's still a cleaner way of
achieving this, somehow, lurking in someone's mind (even if it's not yet
implemented)!
Thanks again!
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Elegant-Handling-of-Multiple-Zones-in-Deep-Hierarchies-of-Components-tp5717698p5719313.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of Components
Posted by Geoff Callender <ge...@gmail.com>.
That response wasn't quite right - it was made too late at night. Of course, PersonList and PersonEditor do know they're in zones - the zone id is a parameter to each. Which has me wondering, have I addressed your issue at all?
On 15/01/2013, at 1:09 AM, Geoff Callender wrote:
> 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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of Components
Posted by Geoff Callender <ge...@gmail.com>.
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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of Components
Posted by Geoff Callender <ge...@gmail.com>.
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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of
Components
Posted by llama-king <p....@albourne.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Elegant Handling of Multiple Zones in 'Deep' Hierarchies of
Components
Posted by llama-king <p....@albourne.com>.
@Lance and @Taha - I can see how this might alleviate some of the large
numbers of zones I'm passing around as parameters to components though I
really still don't like the idea of keeping a bunch of references to zone
instances anywhere apart from perhaps at their point of injection in their
'home' component. In my understanding once a zone is declared it is known to
exist by the client-side by its unique client id; would be nice to just be
able to invoke AjaxResponseRenderer.addRender off that unique client id
rather than passing the zones around all over the place.
@Howard - yes I've experienced this 'ordering' issue myself also! Must say I
really am loving the sound of 5.4 more and more after reading your blog post
a couple weeks back. The '^' short-cut is very handy indeed but I am
specifically interested in your comment about specifying specific client ids
for the zones so that I don't have to carry the instance around.
I declare my zones as such <t:zone t:id="someid" id="someid">...</t:zone>
giving them their specific client id.
I then need to update multiple zones (via AjaxResponseRenderer) but the
addRender methods require either the Zone itself or the zone's id and a
renderer (thus I will usually end up going
AjaxResponseRenderer.addRender(zone.getClientId(), zone and so have carried
the zone instance around with me).
Is there something that I'm perhaps missing or are you alluding to a way of
updating zones solely via their unique client id?
I can imagine a mixin that might simply invoke zone updates for provided
client ids... but how else might this be possible unless I explicitly
specify or construct the 'renderer' in every place that addRender might need
to be called?
And thanks all for your responses! It's very exciting to be able to build
such complex pages with real relative ease!
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Elegant-Handling-of-Multiple-Zones-in-Deep-Hierarchies-of-Components-tp5717698p5717760.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org