> I would chose to get the list of Zones from the page either by > implementing the event handler in it or by triggering an event from > the component...
Yep, and here we are back to my original mail where I ask whether it might be a useful addition to tapestry to reach all components in a page with an event. Currently you only reach components that are ancestors (at least that is what I understand from the documentation) and you only reach one event handler (if you not rethrow the event and aggregate the result in every handler). > > > ---------- Forwarded message ---------- > From: Markus Joschko <markus.josc...@gmail.com> > Date: 2010/9/23 > Subject: Re: Global events > To: Tapestry development <d...@tapestry.apache.org> > > > Ok, sorry. I thought the dev list is for questions regarding > development of tapestry in contrast to questions regarding the usage. > > The MultiZoneUpdate indeed solves one part: Delivering the content of > multiple zones to the client. > But how should the event handler know, which zones to return in the > MultiZoneUpdate? I can only think of three ways: > a) Zones configured as parameters. However with deeply nested > components that can lead to long chains of getters to reference the > zones. > b) Zones received as results of an event -> however the current event > mechanism is limited to one receiver/result. > c) Hardcoded. Only listed for completeness. > > Regards, > Markus > > On Thu, Sep 23, 2010 at 2:31 PM, Christophe Cordenier > <christophe.corden...@gmail.com> wrote: >> Hi ! >> >> Please, use the user mailing list for this kind of question. >> >> Anyway, i think that the MultiZoneUpdate should solve your problem. >> >> 2010/9/23 Markus Joschko <markus.josc...@gmail.com>: >>> Hi, >>> just wanted to ask what you guys think about a global server side >>> event functionality in tapestry. >>> Currently the events triggered by triggerEvent on ComponentResource >>> just bubble up and halt when the first handler returns non null. >>> It would be nice to have a event mechanism where matching handlers in >>> all components on a page (not only the ancestors) >>> are triggered, the results are collected and passed to the event >>> triggering method. >>> >>> The use case I have in mind is a page which has three components that >>> each display different aspects of a group of users (one component >>> listing all users of a group with details, one component with birth >>> dates of the users and one component with twitter messages from the >>> users). >>> The "list of users" component has a delete button which deletes a >>> specific user. This results into an Ajax request to the server and >>> triggers a zone update of the user list. However the birthday and the >>> twitter lists still show the previously deleted user, because the >>> components on the server side aren't informed that they also need to >>> refresh their zones. >>> Ideally they have had received a server side event and contributed >>> their zones to the Ajax event result. >>> >>> What do you think? Should I add a JIRA for this? >>> >>> Regards, >>> Markus >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>> >>> >> >> >> >> -- >> Regards, >> Christophe Cordenier. >> >> Committer on Apache Tapestry 5 >> Co-creator of wooki @wookicentral.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > > > > -- > Regards, > Christophe Cordenier. > > Committer on Apache Tapestry 5 > Co-creator of wooki @wookicentral.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
