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: [email protected]
For additional commands, e-mail: [email protected]
