[jira] [Created] (TAP5-2416) Client-side publish/subscribe mechanism

["Geoff Callender (JIRA)" <ji...@apache.org>]

Geoff Callender created TAP5-2416:
-------------------------------------

             Summary: Client-side publish/subscribe mechanism
                 Key: TAP5-2416
                 URL: https://issues.apache.org/jira/browse/TAP5-2416
             Project: Tapestry 5
          Issue Type: New Feature
          Components: tapestry-core
    Affects Versions: 5.4
            Reporter: Geoff Callender
            Priority: Minor


In some cases, a component may want to respond to an AJAX event in another component. For example a component that display a user's name would want to know when a user-editing component in the same page has successfully updated the user via AJAX.

In simple pages it can be handled this way: the server-side event handler bubbles up a "user changed" event up to its container, and the container can call down to any interested component it contains. The container could also bubble up the event, and so on up to the page level.

However, in more complex pages it would be nice to use a publish/subscribe mechanism. But should it be server-side or client-side?

Server-side has a fundamental stumbling block: the server-side is usually stateless. An AJAX request can contain enough info to tell the server-side component what state is required, but typically it would be only enough for that component. It could publish its success, but the subscribing components may not have enough information to correctly mimic their client-side's current state and would therefore be unable to do anything useful. This has been discussed extensively in TAP5-2383 .

In contrast, the client-side knows exactly the state of every component, so it is the ideal place to do the publish/subscribe.

Quoting from TAP5-2383...

How about a mechanism along these lines:
- give the Zone component a "refreshOnMessage" parameter, specifying a message string; and
- give AjaxResponseRenderer a publishMessage(String s) method; and
Tapestry could do the rest, client-side: it receives the message string, identifies all the zone instances that asked to be refreshed when that string appears, and triggers a refresh of each one.

For example:

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




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)