Hi Nourredine, I like Dmitry's pub-sub, especially for non-AJAX communication between components in a page.
However, I don't think it can address my example problem in the AJAX world. That problem is this: if E is independent of L (it is), then E won't publish what L needs (ie. L's filter value). Geoff On 20/03/2014, at 8:21 PM, Nourredine K. wrote: > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
