You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Geoff Callender <ge...@gmail.com> on 2014/03/19 13:45:58 UTC
Discussion on AJAX requests need even more than a context?
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
Re: Discussion on AJAX requests need even more than a context?
Posted by Lance Java <la...@googlemail.com>.
That's an interesting concept. I like the sound of it.
On 20 Mar 2014 09:22, "Nourredine K." <no...@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.jumpstart@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-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
Re: Discussion on AJAX requests need even more than a context?
Posted by Lance Java <la...@googlemail.com>.
I realise what I'm saying is similar to your original suggestion
ajaxResponseRenderer.setQueryParameters("filter", filterValue);
In your suggestion, the value (filterValue) is known serverside. I think we
need the ability to pass a clientside value that the server may not know
about.
Let's think about things we might want to pass from client to server:
1. The current value of a field
2. The current location of the mouse
3. The size of the client's screen
4. A serverside value known at render time.
A future proof solution would allow a component to register a javascript
closure to be executed and the resultant value is sent to the server. A
default/builtin closure implementation can get the current value of a
clientside field.
On 27 Mar 2014 09:21, "Lance Java" <la...@googlemail.com> wrote:
> 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.jumpstart@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
Re: Discussion on AJAX requests need even more than a context?
Posted by Lance Java <la...@googlemail.com>.
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" <ge...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: Discussion on AJAX requests need even more than a context?
Posted by Geoff Callender <ge...@gmail.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
Posted by Geoff Callender <ge...@gmail.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
Posted by Lance Java <la...@googlemail.com>.
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?
Posted by Geoff Callender <ge...@gmail.com>.
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.jumpstart@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
Posted by "Nourredine K." <no...@gmail.com>.
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.jumpstart@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: Discussion on AJAX requests need even more than a context?
Posted by Geoff Callender <ge...@gmail.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
Posted by Chris Poulsen <ma...@nesluop.dk>.
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 <la...@googlemail.com>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.
>
Re: Discussion on AJAX requests need even more than a context?
Posted by Geoff Callender <ge...@gmail.com>.
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 (List<String>) 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" <ge...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
Posted by Lance Java <la...@googlemail.com>.
If both L and E accepted a fields parameter (List<String>) 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" <ge...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: Discussion on AJAX requests need even more than a context?
Posted by Geoff Callender <ge...@gmail.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
Posted by Lance Java <la...@googlemail.com>.
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?
Posted by Geoff Callender <ge...@gmail.com>.
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.jumpstart@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Discussion on AJAX requests need even more than a context?
Posted by Dmitry Gusev <dm...@gmail.com>.
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.jumpstart@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com