Hi Dmitry,
Every URL on the client-side could be updated. What we're talking about is
setting a query parameter in every URL, eg. putting filter=filterValue in every
URL, whether it needs it or not. It's harmless! That's the beauty of named
parameters.
In my example, if no AJAX was involved then the page render would tack
&filter=filterValue onto every URL. If AJAX is involved, then following a
submit of a new list filter, the response would be AJAX and something on the
client-side would find every URL and make sure it includes filter=filterValue.
As a result, the client-side page would end up exactly the same as if we'd done
a full page render.
Regarding your scenario where E is added to the DOM after the latest change in
F, maybe the answer is for Tapestry on the client-side to keep a cache of the
activation request parameters and apply them to new URLs it finds in all
responses, ie. it would add/update query parameters in those URLs.
On 20/03/2014, at 9:15 PM, Dmitry Gusev wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
