tapestry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
Date Thu, 04 Sep 2014 10:09:51 GMT

    [ https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121188#comment-14121188
] 

Lance edited comment on TAP5-2383 at 9/4/14 10:09 AM:
------------------------------------------------------

Dmitry's questions:

{quote}You can have {{<t:eventLink t:id="myEvent">}}... that will trigger the same event
handler. Now, how this event will be handled, using bubbling or publishing{quote}
As I said, I'm suggesting these events are a new type of event. So eventlink will never fire
@Subscribe event handlers.

Note that publish event handlers will never return anything and will always be void. So using
existing event handlers is a bad fit (you can always have one call the other if you wish).

{quote}it doesn't feel right to have publish method on ComponentResources, because it only
knows about parent/child component relations of specific page relative to current component.{quote}
Correct, ComponentResources only knows about the current page. My whole idea is that pub/sub
happens within a single page. A page will never publish to another page since we are only
ever generating a response for a single page.


was (Author: uklance):
Dmitry's questions:

{quote}You can have {{<t:eventLink t:id="myEvent">}}... that will trigger the same event
handler. Now, how this event will be handled, using bubbling or publishing{quote}
As I said, I'm suggesting these events are a new type of event. So eventlink will never fire
@Subscribe event handlers.

Note that publish event handlers will never return anything and will always be void. So using
existing event handlers is a bad fit (you can always have one call the other if you wish).

{quote}it doesn't feel right to have publish method on ComponentResources, because it only
knows about parent/child component relations of specific page relative to current component.{quote}
I disagree. ComponentResources has a pointer to the containing page (see {{ComponentResources.getPage()}}).
I feel that the page will distribute the event to all of it's children. Regardless of the
current component's place in the hierarchy.

As I said before. These publish subscribe events are all within the container of a page. One
page will never publish events to another. That doesn't make sense since the user is viewing
a single page at a time (ignoring multiple browser windows for the moment)

> 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)

Mime
View raw message