tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Callender <geoff.callender.jumpst...@gmail.com>
Subject Discussion on AJAX requests need even more than a context?
Date Wed, 19 Mar 2014 12:45:58 GMT
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message