> You can currently do what you are asking, and the method is not more
> complicated than the system you are asking to be designed. You simply
> leave it up to the page to determine what requires a refresh of the
> components.
>
> If you trigger an event from your delete handler then your
> page can handle it how it sees fit.
>
> // Component A
> Object onDelete(Long idOfItemToDelete) {
> final Object[] returnObject = new Object[]{null};
> // Maybe you want to pass the id of the object that was deleted here?
> _resources.triggerEvent("ChangedSomeSharedData", null, new
> ComponentEventCallback() {
> public boolean handleResult(final Object result) {
> if (result != null) {
> returnObject[0] = result;
> }
> return result != null;
> }
> });
>
> return returnObject[0];
> }
>
> // Page containing Component A
> Object onChangedSomeSharedData() {
> return "SomeOtherPage";
> }
>
Thanks for some example code. However I don't quite get how this helps
with the ancestor problem where I want to render zones from components
that are not in the same hierarchy.
Let's try some ASCII art:
page
/ \
comp1 comp2
/ \
comp3 comp4*
/
comp5
If an event is triggered in comp4, but comp5 also wants to rerender
it's zone on this event. How does it get notified?
Do you propose that that information is hard coded in the page during
development? I don't like this as it reminds me of action oriented
frameworks where the page handler is the master of the universe.
I really like how tapestry has decentralised contributions and
configuration at its heart and would like to have the same in the
relationship between page and its components.
A page should not have hard coded information if a subsubsubcomponent
needs to rerender its xyz zone when the onDelete event is triggered
somewhere on the page.
The story is different if the components register themselves on page
level for events (see my mail to Thiago).
>
> On Thu, Sep 23, 2010 at 5:27 AM, Markus Joschko
> <[email protected]> wrote:
>> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
>
> --
> --
> http://www.bodylabgym.com - a private, by appointment only, one-on-one
> health and fitness facility.
> --
> http://www.ectransition.com - Quality Electronic Cigarettes at a
> reasonable price!
> --
> TheDailyTube.com. Sign up and get the best new videos on the internet
> delivered fresh to your inbox.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
