That's an interesting concept. I like the sound of it. On 20 Mar 2014 09:22, "Nourredine K." <nourredin...@gmail.com> 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 > > > > >
