Hi Geoff,
How would you know on the client-side which URLs you have to update? What
if some form or a link in client-side DOM isn't a tapestry URL and
shouldn't be updated?
Or what if I generated some event URLs on the server-side and passed them
via JS initializer specification to client-side and they're located in
JavaScript objects or stored as data-* attributes in DOM -- how would these
URLs be updated?
As for your example, it's not clear to me. You said you have filter F, list
L, and editor E. Imagine that only list and filter are on screen and all
event links updated on filter submit as you suggested. Then you're clicking
on some link (from the list?) to display the editor E. New editor will be
rendered on the server side and will appear in client-side via zone update.
Note that though you will have the "filter" request parameter on the server
side during E rendering - you can't do anything with it, because you said
that E is generic and doesn't know about filters. Later if you click submit
on editor, it's submit link won't contain filter information on
client-side, because you invoked
ajaxResponseRenderer.setQueryParameters("filter",
filterValue); before editor E appeared in the client-side DOM and it's
submit link haven't been updated. Am I missing something?
On Wed, Mar 19, 2014 at 4:45 PM, Geoff Callender <
geoff.callender.jumpst...@gmail.com> wrote:
> 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
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
