tapestry-dev 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 08:24:53 GMT

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

Lance edited comment on TAP5-2383 at 9/4/14 8:24 AM:
-----------------------------------------------------

Answering some of Geoff's questions:

{quote}I think the server-side would have no way of knowing how many subscribers there are
within the page{quote}
I disagree, when tapestry starts up it assembles the page and all the components inside it.
It could register all the subscribtion handlers at this stage.

{quote}For example some subscribers could be within a loop, and they might be conditional.{quote}
In my example, the subscribtion handler is either there or it's not. You could use the context
to determine whether to actually do anything. If it was a loop, you might choose to publish
a message for each person.

{quote}However, the client-side has the full page state, so I think that's where the pub-sub
has to happen.{quote}
This is an interesting concept but would it work in my example? In my example, the publish
happens in onSuccessFromPersonForm(). But the client has not idea if the form post will succeed
or not. I'd hate to send a second request after the form post succeeds.

In general, I'd much prefer to keep the pub/sub mechanism serverside.


was (Author: uklance):
Answering some of Geoff's questions:

{quote}I think the server-side would have no way of knowing how many subscribers there are
within the page{quote}
I disagree, when tapestry starts up it assembles the page and all the components inside it.
It could register all the subscribtion handlers at this stage.

{quote}For example some subscribers could be within a loop, and they might be conditional.{quote}
In my example, the subscribtion handler is either there or it's not. You could use the context
to determine whether to actually do anything. If it was a loop, you might choose to publish
a message for each person.

{quote}However, the client-side has the full page state, so I think that's where the pub-sub
has to happen.{quote}
This is an interesting concept but would it work in my example? In my example, the publish
happens in onSuccessFromPersonForm(). But the client has not idea if the form post will succeed
or not.

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