Hi Geoff, Maybe the very interesting Dmitri's contribution can help here. It implements the publisher-subscriber pattern for Tapestry5 pages/components.
https://github.com/anjlab/anjlab-tapestry-commons/wiki/Publisher-API Nourredine. 2014-03-19 13:45 GMT+01:00 Geoff Callender < geoff.callender.jumpst...@gmail.com>: > So it seems we're pretty much agreed that each AJAX-capable component > needs a context parameter, which its containing component can use to > restore its state (usually its parameters) before it makes any decisions. > > > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Discussion-on-all-AJAX-requests-needing-context-tt5726132.html > > But what if other components on the page need to know their state, too, > before they can update their zoned contents? > > For example, a list of persons, L, in one part of the page might need to > refresh itself whenever a person is edited in component E somewhere else on > the page. That's easy (with a bit of bubbling up and perhaps some calls > down, or perhaps a bit of pub-sub), unless L is filtered, like this: > > > http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons > > E doesn't know about L or its filter, and nor should it, so the context on > the submit in E will not contain filter info. > > In that example I found an OK-ish solution but I'm looking for a better > way. The solution I found was to make L return javascript that submits the > filter form. I made use of the fact that the client knows its state. But > I'd prefer not to have that extra round-trip. > > So here's a crazy idea... > > What if, when the filter is submitted, we could do something like this: > > ajaxResponseRenderer.setQueryParameters("filter", filterValue); > > and Tapestry, client-side, would set that parameter on *every* Form, > EventLink, Select, etc. in the page. That way, no matter what event request > comes to the server, its request will be carrying the latest filter value. > In the example above, L would always be able to find out the current filter: > > String filterValue = request.getParameter("filter"); > > Crazy, right? > > I suppose that each component that wants to use this facility would need a > way to tell Tapestry its initial values. Perhaps this could be declarative. > > Thoughts? > > Cheers, > > Geoff > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
