[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14124728#comment-14124728
]
Geoff Callender edited comment on TAP5-2383 at 9/7/14 12:59 AM:
[~uklance]
Take your example a step further - what if the messages list has a filter? Only
the client will know the filter value, and therefore only the client will know
the current messages list.
You can see this exact problem being handled, clumsily, server-side, in
PersonList.doChangeOfSelectedPerson() in
http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons
. That method is called by its container, Persons, in response to various
events elsewhere on the page. You can see it's just plain messy and brittle.
was (Author: geoffcallender):
[~uklance]
Take your example a step further - what if the messages list has a filter? Only
the client will know the filter value, and therefore only the client will know
the current messages list.
You can see this exact problem being handled, clumsily, server-side, in
PersonList.doChangeOfSelectedPerson() in
http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons
. PersonList.doChangeOfSelectedPerson() is called by its container, Persons,
in response to various events elsewhere on the page. You can see it's just
plain messy and brittle.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121096#comment-14121096
]
Lance edited comment on TAP5-2383 at 9/4/14 8:21 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.
{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.
was (Author: uklance):
{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.
{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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121096#comment-14121096
]
Lance edited comment on TAP5-2383 at 9/4/14 8:22 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.
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.
{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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121110#comment-14121110
]
Lance edited comment on TAP5-2383 at 9/4/14 8:31 AM:
-
{quote}Also why do we need the ComponentResources.createPublishLink? How is the
publish event will be different from existing event types?{quote}
Normal component events first fire on the component that defined them. Normal
events then bubble up the hierarchy (unless true is returned which terminates
the bubbling). It's impossible for a normal component event to bubble to it's
sibling.
What I am proposing is a new class/type of event. This event is published to
all components on the page, regardless of hierarchy, with no way of terminating
the publish. This new publish event allows sibling components to fire each
other.
was (Author: uklance):
{quote}Also why do we need the ComponentResources.createPublishLink? How is the
publish event will be different from existing event types?{quote}
Normal component events first fire on the component that defined them. Normal
events then bubble up the hierarchy (unless true is returned which terminates
the bubbling). It's impossible for a normal component event to bubble to it's
sibling.
What I am proposing is a new class/type of event. This event is published to
all components on the page, regardless of hierarchy, with no way of terminating
the publish. This new publish event allows siblings to fire each other.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121140#comment-14121140
]
Lance edited comment on TAP5-2383 at 9/4/14 8:55 AM:
-
Answering some of Dmitry's questions:
{quote}declaration of event handlers (the naming conventions) event contexts
will work the same isn't it?{quote}
I don't think so, I think these are different types of events. In my example I
used a new annotation @Subscribe(personUpdated). You could have one call the
other if you wish.
{quote}Wouldn't it be better to just add @Publish or @Broadcast annotation to
the event handler instead?{quote}
I'm not sure we understand each other here. I'm suggesting a @Subscribe
annotation for the subscription handler and a service invocation for the
publish.
{quote}Or/and have the ability to publish the event manually using some new
service?{quote}
Did you see my code?
componentResources.publish(personUpdated, person); // new method on
ComponentResources
{quote}And usually you want to do this conditionally{quote}
As I said, publishing is a service invocation. Invoke it when and where you
need.
was (Author: uklance):
Answering some of Dmitry's questions:
{quote}declaration of event handlers (the naming conventions) event contexts
will work the same isn't it?{quote}
I don't think so, I think these are different types of events. In my example I
used a new annotation @Subscribe(personUpdated). But you could easily pass
one to the other.
{quote}Wouldn't it be better to just add @Publish or @Broadcast annotation to
the event handler instead?{quote}
I'm not sure we understand each other here. I'm suggesting a @Subscribe
annotation for the subscription handler and a service invocation for the
publish.
{quote}Or/and have the ability to publish the event manually using some new
service?{quote}
Did you see my code?
componentResources.publish(personUpdated, person); // new method on
ComponentResources
{quote}And usually you want to do this conditionally{quote}
As I said, publishing is a service invocation. Invoke it when and where you
need.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121143#comment-14121143
]
Lance edited comment on TAP5-2383 at 9/4/14 8:59 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. 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.
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.
{code}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.{code}
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121159#comment-14121159
]
Lance edited comment on TAP5-2383 at 9/4/14 9:15 AM:
-
{quote} their parameters cannot be filled unless the conduits from their
containers are instantiated{quote}
Isn't this how normal component events work now? You need to pass everything in
the context that's not either persisted or bound to the activation context? For
a component rendered in a loop, it's ajax event needs to pass the loop context.
My suggestion is a similar mechanism.
Geoff, can you start another jira with a clientside pub/sub proposal? And
perhaps link it to this jira? Then we can compare the two.
was (Author: uklance):
{quote} their parameters cannot be filled unless the conduits from their
containers are instantiated{quote}
Isn't this how normal events work now? You need to pass everything in the
context that's not either persisted or bound to the activation context? For a
component rendered in a loop, it's ajax event needs to pass the loop context.
My suggestion is a similar mechanism.
Geoff, can you start another jira with a clientside pub/sub proposal? And
perhaps link it to this jira? Then we can compare the two.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121159#comment-14121159
]
Lance edited comment on TAP5-2383 at 9/4/14 9:16 AM:
-
{quote} their parameters cannot be filled unless the conduits from their
containers are instantiated{quote}
Isn't this how normal component events work now? You need to pass everything in
the context that's not either persisted, literal or bound to the activation
context? For a component rendered in a loop, any events need to pass the loop
context. My suggestion is a similar mechanism.
Geoff, can you start another jira with a clientside pub/sub proposal? And
perhaps link it to this jira? Then we can compare the two.
was (Author: uklance):
{quote} their parameters cannot be filled unless the conduits from their
containers are instantiated{quote}
Isn't this how normal component events work now? You need to pass everything in
the context that's not either persisted or bound to the activation context? For
a component rendered in a loop, it's ajax event needs to pass the loop context.
My suggestion is a similar mechanism.
Geoff, can you start another jira with a clientside pub/sub proposal? And
perhaps link it to this jira? Then we can compare the two.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121146#comment-14121146
]
Geoff Callender edited comment on TAP5-2383 at 9/4/14 9:26 AM:
---
The problem with doing this server-side in an AJAX request is that the
server-side components can't react because they don't know their state - their
parameters cannot be filled unless the conduits from their containers are
instantiated, and so on up the tree - so the subscriber components cannot know
their state without reconstructing the entire page, which might not even match
the current client-side state.
Their client-side equivalents, however, exactly know their state. Using my
suggestion, the sequence in your example would be this:
- In onSuccessFromPersonForm(), do
ajaxResponseRenderer.publishMessage(personAdded);
- client-side, Tapestry would identify each subscriber, ie. each zone in the
DOM that was created with refreshOnMessage=personAdded; and trigger refresh
on that zone. It would be a second request, but so what? Asynch is the rule
these days, not the exception.
The most likely use of this mechanism would be for something that shows a count
of persons to update itself: Persons (27), just as in the example that prompted
this JIRA:
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Different-Zone-Update-s-tt5728186.html
.
If there's a need for a context, e.g. personId, then I think we could handle
it. Perhaps ajaxResponseRenderer.publishMessage(personAdded).with(personId).
However, I haven't thought through how to handle it in the subscribing zones.
was (Author: geoffcallender):
The problem with doing this server-side in an AJAX request is that the
server-side components can't react because they don't know their state - their
parameters cannot be filled unless the conduits from their containers are
instantiated, and so on up the tree - so they cannot know their state without
reconstructing the entire page, which might not even match the current
client-side state.
Their client-side equivalents, however, exactly know their state. Using my
suggestion, the sequence in your example would be this:
- In onSuccessFromPersonForm(), do
ajaxResponseRenderer.publishMessage(personAdded);
- client-side, Tapestry would identify each subscriber, ie. each zone in the
DOM that was created with refreshOnMessage=personAdded; and trigger refresh
on that zone. It would be a second request, but so what? Asynch is the rule
these days, not the exception.
The most likely use of this mechanism would be for something that shows a count
of persons to update itself: Persons (27), just as in the example that prompted
this JIRA:
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Different-Zone-Update-s-tt5728186.html
.
If there's a need for a context, e.g. personId, then I think we could handle
it. Perhaps ajaxResponseRenderer.publishMessage(personAdded).with(personId).
However, I haven't thought through how to handle it in the subscribing zones.
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}
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121146#comment-14121146
]
Geoff Callender edited comment on TAP5-2383 at 9/4/14 9:27 AM:
---
The problem with doing this server-side in an AJAX request is that the
server-side components can't react because they don't know their state - their
parameters cannot be filled unless the conduits from their containers are
instantiated, and so on up the tree - so the *subscriber components* cannot
know their state without reconstructing the entire page, which might not even
match the current client-side state.
Their client-side equivalents, however, exactly know their state. Using my
suggestion, the sequence in your example would be this:
- In onSuccessFromPersonForm(), do
ajaxResponseRenderer.publishMessage(personAdded);
- client-side, Tapestry would identify each subscriber, ie. each zone in the
DOM that was created with refreshOnMessage=personAdded; and trigger refresh
on that zone. It would be a second request, but so what? Asynch is the rule
these days, not the exception.
The most likely use of this mechanism would be for something that shows a count
of persons to update itself: Persons (27), just as in the example that prompted
this JIRA:
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Different-Zone-Update-s-tt5728186.html
.
If there's a need for a context, e.g. personId, then I think we could handle
it. Perhaps ajaxResponseRenderer.publishMessage(personAdded).with(personId).
However, I haven't thought through how to handle it in the subscribing zones.
was (Author: geoffcallender):
The problem with doing this server-side in an AJAX request is that the
server-side components can't react because they don't know their state - their
parameters cannot be filled unless the conduits from their containers are
instantiated, and so on up the tree - so the subscriber components cannot know
their state without reconstructing the entire page, which might not even match
the current client-side state.
Their client-side equivalents, however, exactly know their state. Using my
suggestion, the sequence in your example would be this:
- In onSuccessFromPersonForm(), do
ajaxResponseRenderer.publishMessage(personAdded);
- client-side, Tapestry would identify each subscriber, ie. each zone in the
DOM that was created with refreshOnMessage=personAdded; and trigger refresh
on that zone. It would be a second request, but so what? Asynch is the rule
these days, not the exception.
The most likely use of this mechanism would be for something that shows a count
of persons to update itself: Persons (27), just as in the example that prompted
this JIRA:
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Different-Zone-Update-s-tt5728186.html
.
If there's a need for a context, e.g. personId, then I think we could handle
it. Perhaps ajaxResponseRenderer.publishMessage(personAdded).with(personId).
However, I haven't thought through how to handle it in the subscribing zones.
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,
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121172#comment-14121172
]
Lance edited comment on TAP5-2383 at 9/4/14 9:30 AM:
-
{quote} Sibling components should not be aware of each other (per
default).{quote}
I totally agree. And pub/sub allows this decoupling.
{quote}If one want to soften this compartmentalization it is a matter of making
your own pub/sub mechanism or use a 3rd party lib.{quote}
Or we could add a new tool to the tapestry toolbox. Which is exactly what this
jira is discussing.
was (Author: uklance):
{quote} Sibling components should not be aware of each other (per
default).{quote}
I totally agree. And pub/sub allows this decoupling.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121172#comment-14121172
]
Lance edited comment on TAP5-2383 at 9/4/14 9:32 AM:
-
{quote} Sibling components should not be aware of each other (per
default).{quote}
I totally agree. And pub/sub allows this decoupling.
{quote}If one want to soften this compartmentalization it is a matter of making
your own pub/sub mechanism or use a 3rd party lib.{quote}
Or we could add a new tool to the tapestry toolbox. Which is exactly what this
jira is discussing. I can see that you are not in favor of it. But others have
come across the use case where one deeply nested component needs to affect
another component on an unrelated section on the page. This solves that problem.
was (Author: uklance):
{quote} Sibling components should not be aware of each other (per
default).{quote}
I totally agree. And pub/sub allows this decoupling.
{quote}If one want to soften this compartmentalization it is a matter of making
your own pub/sub mechanism or use a 3rd party lib.{quote}
Or we could add a new tool to the tapestry toolbox. Which is exactly what this
jira is discussing.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121176#comment-14121176
]
Lance edited comment on TAP5-2383 at 9/4/14 9:42 AM:
-
{quote}I don't think it's necessary to modify {{ComponentResources}}
interface{quote}
I'm not tied to altering ComponentResources, it could easily be a service.
{quote}because there will/might be cross-page publishing{quote}
I disagree. In my proposal the page will distribute the event to all of it's
components, but never to other pages.
was (Author: uklance):
{code}I don't think it's necessary to modify {{ComponentResources}}
interface{code}
I'm not tied to altering ComponentResources, it could easily be a service.
{code}because there will/might be cross-page publishing{code}
I don't agree with this. I feel that the page will distribute the event to all
of it's components, but never to other pages.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121176#comment-14121176
]
Lance edited comment on TAP5-2383 at 9/4/14 9:43 AM:
-
Some more of Dmitry's questions:
{quote}I don't think it's necessary to modify {{ComponentResources}}
interface{quote}
I'm not tied to altering ComponentResources, it could easily be a service.
{quote}because there will/might be cross-page publishing{quote}
I disagree. In my proposal the page will distribute the event to all of it's
components, but never to other pages.
was (Author: uklance):
{quote}I don't think it's necessary to modify {{ComponentResources}}
interface{quote}
I'm not tied to altering ComponentResources, it could easily be a service.
{quote}because there will/might be cross-page publishing{quote}
I disagree. In my proposal the page will distribute the event to all of it's
components, but never to other pages.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121172#comment-14121172
]
Lance edited comment on TAP5-2383 at 9/4/14 9:46 AM:
-
Chris' questions:
{quote} Sibling components should not be aware of each other (per
default).{quote}
I totally agree. And pub/sub allows this decoupling.
{quote}If one want to soften this compartmentalization it is a matter of making
your own pub/sub mechanism or use a 3rd party lib.{quote}
Or option 3 is that we add this useful tool to tapestry-core, which is exactly
what this jira is discussing.
I can see that you are not in favor of it. But others have come across the use
case where one deeply nested component needs to affect another component on an
unrelated section on the page. This solves that problem.
was (Author: uklance):
{quote} Sibling components should not be aware of each other (per
default).{quote}
I totally agree. And pub/sub allows this decoupling.
{quote}If one want to soften this compartmentalization it is a matter of making
your own pub/sub mechanism or use a 3rd party lib.{quote}
Or option 3 is that we add this useful tool to tapestry-core, which is exactly
what this jira is discussing.
I can see that you are not in favor of it. But others have come across the use
case where one deeply nested component needs to affect another component on an
unrelated section on the page. This solves that problem.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121140#comment-14121140
]
Lance edited comment on TAP5-2383 at 9/4/14 9:53 AM:
-
Answering some of Dmitry's questions:
{quote}declaration of event handlers (the naming conventions) event contexts
will work the same isn't it?{quote}
I don't think so, I think these are different types of events. In my example I
used a new annotation @Subscribe(personUpdated). You could have one call the
other if you wish.
{quote}Wouldn't it be better to just add @Publish or @Broadcast annotation to
the event handler instead?{quote}
I'm not sure we understand each other here. I'm suggesting a @Subscribe
annotation for the subscription handler and a service invocation for the
publish. But a subscription handler will never return anything. It doesn't make
sense since the publisher 'fires and forgets'.
{quote}Or/and have the ability to publish the event manually using some new
service?{quote}
Did you see my code?
componentResources.publish(personUpdated, person); // new method on
ComponentResources
{quote}And usually you want to do this conditionally{quote}
As I said, publishing is a service invocation. Invoke it when and where you
need.
was (Author: uklance):
Answering some of Dmitry's questions:
{quote}declaration of event handlers (the naming conventions) event contexts
will work the same isn't it?{quote}
I don't think so, I think these are different types of events. In my example I
used a new annotation @Subscribe(personUpdated). You could have one call the
other if you wish.
{quote}Wouldn't it be better to just add @Publish or @Broadcast annotation to
the event handler instead?{quote}
I'm not sure we understand each other here. I'm suggesting a @Subscribe
annotation for the subscription handler and a service invocation for the
publish.
{quote}Or/and have the ability to publish the event manually using some new
service?{quote}
Did you see my code?
componentResources.publish(personUpdated, person); // new method on
ComponentResources
{quote}And usually you want to do this conditionally{quote}
As I said, publishing is a service invocation. Invoke it when and where you
need.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121188#comment-14121188
]
Lance edited comment on TAP5-2383 at 9/4/14 9:58 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 events
Note that publish event handlers will never return anything and will always be
void.
{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. 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.
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 events
{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. 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.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121188#comment-14121188
]
Lance edited comment on TAP5-2383 at 9/4/14 9:59 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}
I disagree. ComponentResources has a pointer to the containing page. 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.
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 events
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. 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.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121188#comment-14121188
]
Lance edited comment on TAP5-2383 at 9/4/14 9:59 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 events
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. 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.
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 events
Note that publish event handlers will never return anything and will always be
void.
{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. 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.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121188#comment-14121188
]
Lance edited comment on TAP5-2383 at 9/4/14 10:00 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}
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.
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. 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.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121188#comment-14121188
]
Lance edited comment on TAP5-2383 at 9/4/14 10:01 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}
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.
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.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121188#comment-14121188
]
Lance edited comment on TAP5-2383 at 9/4/14 10:03 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}
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)
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.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121188#comment-14121188
]
Lance edited comment on TAP5-2383 at 9/4/14 10:10 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.
I see that Page as the PubSubHub!
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}
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.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121188#comment-14121188
]
Lance edited comment on TAP5-2383 at 9/4/14 10:11 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}ComponentResources 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.
I see that Page as the PubSubHub!
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}
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.
I see that Page as the PubSubHub!
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121215#comment-14121215
]
Lance edited comment on TAP5-2383 at 9/4/14 10:26 AM:
--
{quote}Like I was saying before – I don't feel we need another (second) kind of
event types, because there's no really benefits.{quote}
Normal event handlers will often return block. This feels a bit wrong for a
subscription handler which should return void. I guess we could re-use them.
{quote}This won't work if publisher and subscriber are on different pages, like
when your trigger component is from a block that is from one page, and your
subscribers are from active page that's just rendered the source component via
{{t:deletage ... /}}{quote}
I finally get you. Whilst logically these components are on the same web page,
they are actually on different pages on the serverside. I'd have to have a
think about this case.
I finally see why you think ComponentResources is possibly not the best place!
was (Author: uklance):
{quote}Like I was saying before – I don't feel we need another (second) kind of
event types, because there's no really benefits.{quote}
Normal event handlers will often return block. This feels a bit wrong for a
subscription handler which should return void. I guess we could re-use them.
{quote}This won't work if publisher and subscriber are on different pages, like
when your trigger component is from a block that is from one page, and your
subscribers are from active page that's just rendered the source component via
{{t:deletage ... /}}{quote}
I finally get you. Whilst logically these components are on the same web page,
they are actually on different pages on the serverside. I'd have to have a
think about this case.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121220#comment-14121220
]
Lance edited comment on TAP5-2383 at 9/4/14 10:31 AM:
--
{quote}so you can only get a parent of the component, but you can't get its
children...{quote}
I'm making assumptions here about the actuall implementation. But I was hoping
that as tapestry assembles the page and it's components, the components could
add subscription handlers to the page. Surely the page is in scope as the
components are being assembled?
was (Author: uklance):
{quote}so you can only get a parent of the component, but you can't get its
children...{quote}
I'm making assumptions here about the actuall implementation. But I was hoping
that as tapestry assembles the page and it's components, the components could
add themselves as subscription handlers to the page. Surely the page is in
scope as the components are being assembled?
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121220#comment-14121220
]
Lance edited comment on TAP5-2383 at 9/4/14 10:33 AM:
--
{quote}so you can only get a parent of the component, but you can't get its
children...{quote}
I'm making assumptions here about the actuall implementation. But I was hoping
that as tapestry assembles the page and it's components, the components could
add subscription handlers to the page. Surely the page is in scope as the
components are being assembled?
When the publish service is called, it just notifies all the handlers.
was (Author: uklance):
{quote}so you can only get a parent of the component, but you can't get its
children...{quote}
I'm making assumptions here about the actuall implementation. But I was hoping
that as tapestry assembles the page and it's components, the components could
add subscription handlers to the page. Surely the page is in scope as the
components are being assembled?
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121232#comment-14121232
]
Lance edited comment on TAP5-2383 at 9/4/14 10:52 AM:
--
{quote}It is hard to say without having an actual case.{quote}
I thought Dmitry's use case was an actual case, and a pretty good one!
{quote}You could let UserInfoEditor refresh the whole page{quote}
Of course we can, but this is web 2.0
{quote}You could have UserInfoEditor trigger an event indicating that user info
has changed and have the appropriate container refresh the necessary zones, you
could use a separate page for user editing automatically giving you the full
refresh after edit, you could implement pub/sub on the server side or client
side, whatever you think is best...{quote}
So, your solutions either involve full page refresh or one component knowing
about the zones in another? This is exactly what we are trying to avoid.
was (Author: uklance):
{quote}It is hard to say without having an actual case.{quote}
I thought Dmitry's use case was an actual case, and a pretty good one!
{quote}You could let UserInfoEditor refresh the whole page{quote}
Of course we can, but this is web 2.0
{quote}You could let UserInfoEditor refresh the whole page, you could have
UserInfoEditor trigger an event indicating that user info has changed and have
the appropriate container refresh the necessary zones, you could use a separate
page for user editing automatically giving you the full refresh after edit, you
could implement pub/sub on the server side or client side, whatever you think
is best...{quote}
So, your solutions either involve full page refresh or one component knowing
about the zones in another? This is exactly what we are trying to avoid.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121232#comment-14121232
]
Lance edited comment on TAP5-2383 at 9/4/14 10:54 AM:
--
{quote}It is hard to say without having an actual case.{quote}
I thought Dmitry's use case was an actual case, and a pretty good one!
{quote}You could let UserInfoEditor refresh the whole page{quote}
Of course we can, but this is web 2.0
{quote}You could have UserInfoEditor trigger an event indicating that user info
has changed and have the appropriate container refresh the necessary zones, you
could use a separate page for user editing automatically giving you the full
refresh after edit{quote}
So, your solutions either involve full page refresh or one component knowing
about the zones in another? This is exactly what we are trying to avoid.
{quote}you could implement pub/sub on the server side{quote}
Why not build it in to tapestry-core? If you don't want it... don't use it
was (Author: uklance):
{quote}It is hard to say without having an actual case.{quote}
I thought Dmitry's use case was an actual case, and a pretty good one!
{quote}You could let UserInfoEditor refresh the whole page{quote}
Of course we can, but this is web 2.0
{quote}You could have UserInfoEditor trigger an event indicating that user info
has changed and have the appropriate container refresh the necessary zones, you
could use a separate page for user editing automatically giving you the full
refresh after edit{quote}
So, your solutions either involve full page refresh or one component knowing
about the zones in another? This is exactly what we are trying to avoid.
{quote}you could implement pub/sub on the server side{quote}
Why not allow us to build it in to tapestry-core? If you don't want it... don't
use it
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121232#comment-14121232
]
Lance edited comment on TAP5-2383 at 9/4/14 10:54 AM:
--
{quote}It is hard to say without having an actual case.{quote}
I thought Dmitry's use case was an actual case, and a pretty good one!
{quote}You could let UserInfoEditor refresh the whole page{quote}
Of course we can, but this is web 2.0
{quote}You could have UserInfoEditor trigger an event indicating that user info
has changed and have the appropriate container refresh the necessary zones, you
could use a separate page for user editing automatically giving you the full
refresh after edit{quote}
So, your solutions either involve full page refresh or one component knowing
about the zones in another? This is exactly what we are trying to avoid.
{quote}you could implement pub/sub on the server side{quote}
Why not allow us to build it in to tapestry-core? If you don't want it... don't
use it
was (Author: uklance):
{quote}It is hard to say without having an actual case.{quote}
I thought Dmitry's use case was an actual case, and a pretty good one!
{quote}You could let UserInfoEditor refresh the whole page{quote}
Of course we can, but this is web 2.0
{quote}You could have UserInfoEditor trigger an event indicating that user info
has changed and have the appropriate container refresh the necessary zones, you
could use a separate page for user editing automatically giving you the full
refresh after edit, you could implement pub/sub on the server side or client
side, whatever you think is best...{quote}
So, your solutions either involve full page refresh or one component knowing
about the zones in another? This is exactly what we are trying to avoid.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121247#comment-14121247
]
Lance edited comment on TAP5-2383 at 9/4/14 11:18 AM:
--
Chirs, I'm not sure how many times I can say this
It's nice to think of a components internal zoneId's as being private. The
container should not need to know them. Having the container update zones in
the component is tight coupling. This pub/sub is designed to decouple the
components.
I've given a very simple example. Think of two deeply nested components inside
a complex hierarchy.
was (Author: uklance):
Chirs, I'm not sure how many times I can say this
It's nice to think of a components internal zoneId's as being private. The
container should not need to know them. Having the container update zones in
the component is tight coupling. This pub/sub is designed to decouple the
components.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121247#comment-14121247
]
Lance edited comment on TAP5-2383 at 9/4/14 11:18 AM:
--
Chirs, I'm not sure how many times I can say this
It's nice to think of a components internal zoneId's as being private. The
container should not need to know them. Having the container update zones in
the component is tight coupling. This pub/sub is designed to decouple the
components.
was (Author: uklance):
Chirs, I'm not sure how many times I can say this
It's nice to think of a components internal zoneId's as being private. The
container should not need to know them. Having the container update zones in
the component is tight coupling. This pub/sub is designed to decoupple the
components.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121247#comment-14121247
]
Lance edited comment on TAP5-2383 at 9/4/14 11:20 AM:
--
Chirs, I'm not sure how many times I can say this
It's nice to think of a components internal zoneId's as being private. The
container should not need to know them. If the container (or another component)
is having to think about another container's zoneIds I consider this to be
tight coupling. This pub/sub mechanism is designed to decouple the components.
I've given a very simple example. Think of two deeply nested components inside
a complex hierarchy.
was (Author: uklance):
Chirs, I'm not sure how many times I can say this
It's nice to think of a components internal zoneId's as being private. The
container should not need to know them. Having the container update zones in
the component is tight coupling. This pub/sub is designed to decouple the
components.
I've given a very simple example. Think of two deeply nested components inside
a complex hierarchy.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121247#comment-14121247
]
Lance edited comment on TAP5-2383 at 9/4/14 11:22 AM:
--
Chirs, I'm not sure how many times I can say this
It's nice to think of a components internal zoneId's as being private. The
container should not need to know them. If the container (or another component)
is having to think about another component's zoneIds I consider this to be
tight coupling. This pub/sub mechanism is designed to decouple the components.
If I change the way a component generates it's own internal zone id's I should
be confident that I'm not breaking anything else.
I've given a very simple example. Think of two deeply nested components inside
a complex hierarchy.
was (Author: uklance):
Chirs, I'm not sure how many times I can say this
It's nice to think of a components internal zoneId's as being private. The
container should not need to know them. If the container (or another component)
is having to think about another container's zoneIds I consider this to be
tight coupling. This pub/sub mechanism is designed to decouple the components.
I've given a very simple example. Think of two deeply nested components inside
a complex hierarchy.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121341#comment-14121341
]
Lance edited comment on TAP5-2383 at 9/4/14 1:37 PM:
-
Hi Geoff, I'm starting to see use cases where there's not enough info in the
event context on the server.
{code:xml}
div
t:userInfoEditor user=currentUser /
/div
div
t:loop source=messages value=currentMessage /
t:avatar user=currentMessage.user / ${currentMessage.message}br /
/t:loop
/div
{code}
In this case the context is just the user. But we need to update all
{{t:avatar /}} in the loop. But we don't have the messages collection.
was (Author: uklance):
Hi Geoff, I'm starting to see use cases where there's not enough info in the
event context on the server.
{code:xml}
div
t:userInfoEditor user=currentUser /
/div
div
t:loop source=messages value=currentMessage /
t:avatar user=message.user / ${message.message}br /
/t:loop
/div
{code}
In this case the context is just the user. But we need to update all
{{t:avatar /}} in the loop. But we don't have the messages collection.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121341#comment-14121341
]
Lance edited comment on TAP5-2383 at 9/4/14 1:38 PM:
-
Hi Geoff, I'm starting to see use cases where there's not enough info in the
event context on the server (as you have pointed out).
{code:xml}
div
t:userInfoEditor user=currentUser /
/div
div
t:loop source=messages value=currentMessage /
t:avatar user=currentMessage.user / ${currentMessage.message}br /
/t:loop
/div
{code}
In this case the context is just the user. But we need to update all
{{t:avatar /}} in the loop. But we don't have the messages collection.
was (Author: uklance):
Hi Geoff, I'm starting to see use cases where there's not enough info in the
event context on the server.
{code:xml}
div
t:userInfoEditor user=currentUser /
/div
div
t:loop source=messages value=currentMessage /
t:avatar user=currentMessage.user / ${currentMessage.message}br /
/t:loop
/div
{code}
In this case the context is just the user. But we need to update all
{{t:avatar /}} in the loop. But we don't have the messages collection.
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)
[jira] [Comment Edited] (TAP5-2383) Serverside publish / subscribe mechanism
[
https://issues.apache.org/jira/browse/TAP5-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121341#comment-14121341
]
Lance edited comment on TAP5-2383 at 9/4/14 1:39 PM:
-
Hi Geoff, I'm starting to see use cases where there's not enough info in the
event context on the server (as you have pointed out).
{code:xml}
div
t:userInfoEditor user=currentUser /
/div
div
t:loop source=messages value=currentMessage /
t:avatar user=currentMessage.user / ${currentMessage.message}br /
/t:loop
/div
{code}
In this case the context is just the user but we need to re-render all
{{t:avatar /}} for the updated user. We nned the messages collection to do
this serverside (which is not in the event context).
was (Author: uklance):
Hi Geoff, I'm starting to see use cases where there's not enough info in the
event context on the server (as you have pointed out).
{code:xml}
div
t:userInfoEditor user=currentUser /
/div
div
t:loop source=messages value=currentMessage /
t:avatar user=currentMessage.user / ${currentMessage.message}br /
/t:loop
/div
{code}
In this case the context is just the user. But we need to update all
{{t:avatar /}} in the loop. But we don't have the messages collection.
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)
