[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121267#comment-14121267
]
Geoff Callender edited comment on TAP5-2383 at 9/4/14 11:50 AM:
----------------------------------------------------------------
Chris, can I refer you to the example in the thread that prompted this issue.
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Different-Zone-Update-s-tt5728186.html
. Bubbling up and calling down in this situation is thoroughly unwieldy.
Complex AJAX pages with deeply nested components like that are becoming
commonplace in my world.
Better still, think of a page that's working like a portlet, where a parent has
no idea what's in its deeply nested children.
Or another situation: where a component on a page has allowed a user to make
choices, via AJAX, that affect its content. The content now has nothing to do
with the page context. There is no way the page can infer anything about the
content. The content may have returned a zone that wants to subscribe to a
particular type of message.
And that last example brings me back to the need to do this client-side. In
that last example, the client knows the whole DOM. The client-side pub-sub
mechanism will have no problem working with the freshly returned zone.
was (Author: geoffcallender):
Chris, can I refer you to the example in the thread that prompted this issue.
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Different-Zone-Update-s-tt5728186.html
. Bubbling up and calling down in this situation is thoroughly unwieldy.
Complex AJAX pages like that are becoming commonplace.
Better still, think of a page that's working like a portlet, where a parent has
no idea what's in its deeply nested children.
Or another situation: where a component on a page has allowed a user to make
choices, via AJAX, that affect its content. The content now has nothing to do
with the page context. There is no way the page can infer anything about the
content. The content may have returned a zone that wants to subscribe to a
particular type of message.
And that last example brings me back to the need to do this client-side. In
that last example, the client knows the whole DOM. The client-side pub-sub
mechanism will have no problem working with the freshly returned zone.
> Serverside publish / subscribe mechanism
> ----------------------------------------
>
> Key: TAP5-2383
> URL: https://issues.apache.org/jira/browse/TAP5-2383
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
> Reporter: Lance
> Priority: Minor
>
> In some cases, an event in one component should cause an action (eg ajax
> update) in another. When these components are siblings it sometimes gets
> tricky having to pass zone id's around and having one component update the
> other.
> It would be nice to decouple the components with a serverside pub/sub
> mechanism. Here's an initial brain dump on how it could work.
> {code:java}
> public class EditPersonComponent {
> @Parameter
> private Person person;
> @Inject
> private PersonDao personDao;
> @Inject
> private ComponentResources componentResources;
> // lets assume there's a form in the component which gets posted
> void onSuccessFromPersonForm() {
> personDao.save(person);
> componentResources.publish("personUpdated", person); // new method on
> ComponentResources
> }
> }
> {code}
> {code:java}
> public class SomeOtherComponent {
> @Inject
> private AjaxResponseRenderer ajaxResponseRenderer;
> @Property
> private Person person;
> @Inject
> private Zone personZone;
> // new subscribe annotation (and naming convention?)
> @Subscribe("personUpdated")
> void onPersonUpdatedPublished(Person person) {
> this.person = person;
> ajaxResponseRenderer.addRender(personZone);
> }
> }
> {code}
> If this change was made on ComponentResources, we should probably add the
> following to support invoking publish events on the client
> {code}
> Link ComponentResources.createPublishLink(String eventType, Object... context)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
