[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121143#comment-14121143
]
Lance edited comment on TAP5-2383 at 9/4/14 9:01 AM:
-----------------------------------------------------
Answering Chris's questions:
{quote}The pub/sub pattern in this context smells a bit to me, it feels like
something that could lead to a maintenance mess.{quote}
It's just another tool in the toolbox which of course could be abused. This is
trying to solve the problem of sibling components affecting one another. The
other option is passing zone id's around which means each component needs to
know a lot about the other's internals. I would argue that's a worse
maintenance mess.
{quote}And considering that it is so trivial to implement (and someone already
did as mentioned above) I do not think that the feature needs to be included in
tapestry.{quote}
Using external libraries has it's own risks (eg abandonware). I think if an
idea is good enough, it should be considered for bringing into tapestry-core.
was (Author: uklance):
Answering Chris's questions:
{quote}The pub/sub pattern in this context smells a bit to me, it feels like
something that could lead to a maintenance mess.{quote}
It's just another tool in the toolbox which of course could be abused. This is
trying to solve the problem of sibling components affecting one another. The
other option is passing zone id's around which means each component needs to
know a lot about the other's internals. You could argue that that's a worse
maintenance mess.
{quote}And considering that it is so trivial to implement (and someone already
did as mentioned above) I do not think that the feature needs to be included in
tapestry.{quote}
Using external libraries has it's own risks (eg abandonware). I think if an
idea is good enough, it should be considered for bringing into tapestry-core.
> 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)
