Re: Discussion on AJAX requests need even more than a context?

2014-03-20 Thread Lance Java
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?

2014-03-20 Thread Lance Java
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?

2014-03-20 Thread Dmitry Gusev
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?

2014-03-20 Thread Geoff Callender
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?

2014-03-20 Thread Geoff Callender
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?

2014-03-20 Thread Geoff Callender
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?

2014-03-20 Thread Lance Java
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: Tapestry 5.4 and java8

2014-03-20 Thread Joachim Van der Auwera

THanks Kalle for doing this.

Kind regards,
Joachim

On 03/18/2014 08:32 PM, Joachim Van der Auwera wrote:

Java8 is now officially available.
ASM 5.0 has also been released (see 
http://forge.ow2.org/forum/forum.php?forum_id=2302)


Could the ASM5 be integrated in Tapestry 5.4 and a new beta release 
built? This way Tapestry could be used in Java8.


Kind regards,
Joachim

-
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: Tapestry 5.4 and java8

2014-03-20 Thread Kalle Korhonen
Sure, no problem. We still need it released but that might have to wait
till 5.4 GA release. Easy enough for those who need it to build it
themselves though.

Kalle


On Thu, Mar 20, 2014 at 1:03 PM, Joachim Van der Auwera li...@progs.bewrote:

 THanks Kalle for doing this.

 Kind regards,
 Joachim


 On 03/18/2014 08:32 PM, Joachim Van der Auwera wrote:

 Java8 is now officially available.
 ASM 5.0 has also been released (see http://forge.ow2.org/forum/
 forum.php?forum_id=2302)

 Could the ASM5 be integrated in Tapestry 5.4 and a new beta release
 built? This way Tapestry could be used in Java8.

 Kind regards,
 Joachim

 -
 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: Tapestry 5.4 and java8

2014-03-20 Thread Lenny Primak
We should make a 5.3.x release that's compatible with java 8 ASAP. 



 On Mar 20, 2014, at 4:15 PM, Kalle Korhonen kalle.o.korho...@gmail.com 
 wrote:
 
 Sure, no problem. We still need it released but that might have to wait
 till 5.4 GA release. Easy enough for those who need it to build it
 themselves though.
 
 Kalle
 
 
 On Thu, Mar 20, 2014 at 1:03 PM, Joachim Van der Auwera li...@progs.bewrote:
 
 THanks Kalle for doing this.
 
 Kind regards,
 Joachim
 
 
 On 03/18/2014 08:32 PM, Joachim Van der Auwera wrote:
 
 Java8 is now officially available.
 ASM 5.0 has also been released (see http://forge.ow2.org/forum/
 forum.php?forum_id=2302)
 
 Could the ASM5 be integrated in Tapestry 5.4 and a new beta release
 built? This way Tapestry could be used in Java8.
 
 Kind regards,
 Joachim
 
 -
 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
 
 

-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org