Re: Discussion on AJAX requests need even more than a context?
Yes, you're right. You would need the current field values to be passed
along with the submit. @Persist cookie would work.
Or a mechanism like the onevent mixin would work where a list of field ids
is required and passed from client to server. But as you said, you don't
like this because one component needs knowledge of the other.
If the list of fields was passed from the containing page (or component)
I'm thinking it's ok. Perhaps each component could register it's fields
with the container so it's more transparent?
On 26 Mar 2014 00:49, Geoff Callender geoff.callender.jumpst...@gmail.com
wrote:
Sorry, but I've read the solution below 10 times now and it hurts my head
every time! :-) I don't see how it gets around the problem that when E is
AJAX-submitted, the server-side elements can find ways to prod L to refresh
but they cannot tell L the current value of F. The server-side doesn't know
the current value of F, unless we make the server-side stateful (no thank
you), or we somehow include the value of F in every request.
What I'm aiming for is a solution which works declaratively. You know,
where you don't see the plumbing. Just like @ActivationRequestParameter,
but at the component level.
On 21/03/2014, at 2:35 AM, Lance Java wrote:
I'm imagining the pub sub would work like...
public class L {
@Inject
private Publisher publisher;
@Inject
private Block someBlock;
/**
* Fired when the select menu changes
*/
public Object onFilterChange(Entity entity) {
publisher.publish(changeEntity, entity);
return someBlock;
}
}
public class E {
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Zone someZone;
@Property
private Entity entity;
@Subscribe(topic=changeEntity)
void subscribeChangeEntity(Entity entity) {
this.entity = entity;
ajaxResponseRenderer.addRender(someZone;
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
Maybe L (which contains F) just needs to use:
@Persist(cookie)
private String filterValue
Downsides might be it's not bookmarkable, and the client-side state persists
beyond the page.
On 26/03/2014, at 11:47 AM, Geoff Callender wrote:
Sorry, but I've read the solution below 10 times now and it hurts my head
every time! :-) I don't see how it gets around the problem that when E is
AJAX-submitted, the server-side elements can find ways to prod L to refresh
but they cannot tell L the current value of F. The server-side doesn't know
the current value of F, unless we make the server-side stateful (no thank
you), or we somehow include the value of F in every request.
What I'm aiming for is a solution which works declaratively. You know, where
you don't see the plumbing. Just like @ActivationRequestParameter, but at the
component level.
On 21/03/2014, at 2:35 AM, Lance Java wrote:
I'm imagining the pub sub would work like...
public class L {
@Inject
private Publisher publisher;
@Inject
private Block someBlock;
/**
* Fired when the select menu changes
*/
public Object onFilterChange(Entity entity) {
publisher.publish(changeEntity, entity);
return someBlock;
}
}
public class E {
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Zone someZone;
@Property
private Entity entity;
@Subscribe(topic=changeEntity)
void subscribeChangeEntity(Entity entity) {
this.entity = entity;
ajaxResponseRenderer.addRender(someZone;
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
Sorry, but I've read the solution below 10 times now and it hurts my head every
time! :-) I don't see how it gets around the problem that when E is
AJAX-submitted, the server-side elements can find ways to prod L to refresh but
they cannot tell L the current value of F. The server-side doesn't know the
current value of F, unless we make the server-side stateful (no thank you), or
we somehow include the value of F in every request.
What I'm aiming for is a solution which works declaratively. You know, where
you don't see the plumbing. Just like @ActivationRequestParameter, but at the
component level.
On 21/03/2014, at 2:35 AM, Lance Java wrote:
I'm imagining the pub sub would work like...
public class L {
@Inject
private Publisher publisher;
@Inject
private Block someBlock;
/**
* Fired when the select menu changes
*/
public Object onFilterChange(Entity entity) {
publisher.publish(changeEntity, entity);
return someBlock;
}
}
public class E {
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Zone someZone;
@Property
private Entity entity;
@Subscribe(topic=changeEntity)
void subscribeChangeEntity(Entity entity) {
this.entity = entity;
ajaxResponseRenderer.addRender(someZone;
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
If both L and E accepted a fields parameter (ListString) you could pass in the extra field ids to each. So you would pass L's filter clientId to E and pass E's filter clientId to L. When either L's filter or E's filter change, both filters are passed to the serverside event(s). The group of fields demo on tapestry-stitch shows an example of four fields rendered in a loop. When any of the four fields change all four values (and the loop context) are sent to the serverside event. It's similar to this use case except text fields instead of select. On 19 Mar 2014 22:43, Geoff Callender geoff.callender.jumpst...@gmail.com wrote: Are you sure? How can @OnEvent solve the example I gave? Keep in mind that L and E are separate components. E is a reusable editor that doesn't know about L. L is a reusable filter and list that doesn't know about E, and which kindly provides a public method to allow others to ask it to refresh itself. On 20/03/2014, at 12:42 AM, Lance Java wrote: Hi Geoff, I'm thinking this can also be done with the onevent mixin I mentioned earlier. Since it can send a (configurable) list of clientside field values to the serverside event, you can send all field values that your event cares about. If two fields (eg select menus, text fields) determine the behaviour, send both. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
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
Re: Discussion on AJAX requests need even more than a context?
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
Re: Discussion on AJAX requests need even more than a context?
Doesn't that mean that E is no longer independent, because it has to know how many clientIds will arrive in each request? One thing I like about what I'm proposing is the way it scopes the request parameters to the component that needs them, ie. other components don't know anything about them. If there's a name clash then perhaps Tapestry could warn us in dev, or perhaps it could handle it transparently. Can @OnEvent be used with a Submit/POST like E uses? On 20/03/2014, at 8:15 PM, Lance Java wrote: If both L and E accepted a fields parameter (ListString) you could pass in the extra field ids to each. So you would pass L's filter clientId to E and pass E's filter clientId to L. When either L's filter or E's filter change, both filters are passed to the serverside event(s). The group of fields demo on tapestry-stitch shows an example of four fields rendered in a loop. When any of the four fields change all four values (and the loop context) are sent to the serverside event. It's similar to this use case except text fields instead of select. On 19 Mar 2014 22:43, Geoff Callender geoff.callender.jumpst...@gmail.com wrote: Are you sure? How can @OnEvent solve the example I gave? Keep in mind that L and E are separate components. E is a reusable editor that doesn't know about L. L is a reusable filter and list that doesn't know about E, and which kindly provides a public method to allow others to ask it to refresh itself. On 20/03/2014, at 12:42 AM, Lance Java wrote: Hi Geoff, I'm thinking this can also be done with the onevent mixin I mentioned earlier. Since it can send a (configurable) list of clientside field values to the serverside event, you can send all field values that your event cares about. If two fields (eg select menus, text fields) determine the behaviour, send both. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
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
Re: Discussion on AJAX requests need even more than a context?
Hi Nourredine, I like Dmitry's pub-sub, especially for non-AJAX communication between components in a page. However, I don't think it can address my example problem in the AJAX world. That problem is this: if E is independent of L (it is), then E won't publish what L needs (ie. L's filter value). Geoff On 20/03/2014, at 8:21 PM, Nourredine K. 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 - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
I'm imagining the pub sub would work like...
public class L {
@Inject
private Publisher publisher;
@Inject
private Block someBlock;
/**
* Fired when the select menu changes
*/
public Object onFilterChange(Entity entity) {
publisher.publish(changeEntity, entity);
return someBlock;
}
}
public class E {
@Inject
private AjaxResponseRenderer ajaxResponseRenderer;
@Inject
private Zone someZone;
@Property
private Entity entity;
@Subscribe(topic=changeEntity)
void subscribeChangeEntity(Entity entity) {
this.entity = entity;
ajaxResponseRenderer.addRender(someZone;
}
}
Re: Discussion on AJAX requests need even more than a context?
Hi Geoff, I'm thinking this can also be done with the onevent mixin I mentioned earlier. Since it can send a (configurable) list of clientside field values to the serverside event, you can send all field values that your event cares about. If two fields (eg select menus, text fields) determine the behaviour, send both.
Re: Discussion on AJAX requests need even more than a context?
Hi, The over all idea is really interesting and nice, but I think it is a hard one to implement correctly in the framework. Having complete page state in GET requests (as context/parameters) may be troublesome for complex pages with a lot of state (there seem to be an URL size limit around 2000 chars). Using POST may be an option for some things or a totally different paradigm where state is kept server side and the key to locate the state is passed around could be possible... Even though the existing solutions with the server side state clearly has their own set of issues. The discussion is very interesting though ;) -- Chris On Wed, Mar 19, 2014 at 2:42 PM, Lance Java lance.j...@googlemail.comwrote: Hi Geoff, I'm thinking this can also be done with the onevent mixin I mentioned earlier. Since it can send a (configurable) list of clientside field values to the serverside event, you can send all field values that your event cares about. If two fields (eg select menus, text fields) determine the behaviour, send both.
Re: Discussion on AJAX requests need even more than a context?
Are you sure? How can @OnEvent solve the example I gave? Keep in mind that L and E are separate components. E is a reusable editor that doesn't know about L. L is a reusable filter and list that doesn't know about E, and which kindly provides a public method to allow others to ask it to refresh itself. On 20/03/2014, at 12:42 AM, Lance Java wrote: Hi Geoff, I'm thinking this can also be done with the onevent mixin I mentioned earlier. Since it can send a (configurable) list of clientside field values to the serverside event, you can send all field values that your event cares about. If two fields (eg select menus, text fields) determine the behaviour, send both. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
No, there's no need for complete page state in any request. In the example I gave, we restored the necessary state with just one query parameter: filter. Component contexts looked after the rest. Think of it as bringing @ActivationRequestParameter down from the page level to the component/zone level, just for AJAX. When there's no AJAX, @ActivationRequestParameter works fine: during page render every requester in the page (Form, EventLink, etc) gets the activation request parameters baked into its URLs. Every request that comes in sets the @ActivationRequestParameter. But when there is AJAX, each server-side component needs a way to return its activation request parameters and have the client-side update every URL in the page, not just the URLs in the returned zone(s). That's all I'm proposing. On 20/03/2014, at 12:59 AM, Chris Poulsen wrote: Hi, The over all idea is really interesting and nice, but I think it is a hard one to implement correctly in the framework. Having complete page state in GET requests (as context/parameters) may be troublesome for complex pages with a lot of state (there seem to be an URL size limit around 2000 chars). Using POST may be an option for some things or a totally different paradigm where state is kept server side and the key to locate the state is passed around could be possible... Even though the existing solutions with the server side state clearly has their own set of issues. The discussion is very interesting though ;) -- Chris - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
