Re: T5's Ajax/Zone implementation has substantial limitations
Is there a Jira for this to vote on? - Original Message - From: Chuck Kring cjkr...@pacbell.net To: Tapestry users users@tapestry.apache.org Sent: Thursday, 8 January, 2009 7:25:47 PM GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: T5's Ajax/Zone implementation has substantial limitations I think it's important to separate the core tapestry zone infrastructure from the Javascript zone wrappers. I have a lot of Ajax in my application - it's a systems management console /dashboard - and pretty early on I decided to use the Tapestry zone Javascript as template and use my own javascript against the standard tapestry core.I do things like update zones from a Javascript poller (calling an actionlink from a Javascript function) and updating multiple zones with one server call (the JSON key is not contents but there are several objects keyed by the zone name). Given a suitable Tapestry JSON layer, I believe that zones should be handled as a component library issue. My main issue with the T5 zone is is the need to instantiate all components in the template. In general, this is an example of the dynamic rendering issue that comes up occasionally. I should NOT have to put all possible components into my template a-priori. In my case, I have a number of alarm conditions that require user input and use AJAX components in a div provide condition-based user response. Right now it's a pain to add components to the template for the 10 user conditions I current have, but what happens over time when I have 100's of possible user responses. In other words, I agree with Francois to a point. I think Tapestry5 was designed to render pages and doesn't naturally handle dynamic updates. That paradigm works well for rendered pages but should be relaxed for components rendered via JSON XHR requests. If I have a div in the template and want to change the contents T5 should let me drop in any component I want even it it hasn't been defined in the template. Another area where zones break is in embedded forms and form support. I'd love to be able to register a component with a form, drop it into the page, then later deregister the component and put in another. I'm summary, I think zones need: 1) JSON components returned via XHR should have their own render cycle and should not have to be defined in the template . 2) API support to 'register' a component with a form, then to deregister if when that component is replace. 3) A stable JSON/XHR interface in Tapestry core that will allow component developers to create zone-like components that do things like update cells in grids, extend forms based upon a select, etc. Regards, Chuck Kring Francois Armand wrote: Avi Cherry wrote: First off, I want to say that I'm a huge supporter, advocate (and long time user) of Tapestry, particularly T5. Hello Avi, [...] a lot of intersting things To be honest, the Ajax support on Tapestry 5 is one of the rare things that seems to be not _just_rigth_ on the framework, as if it has been an afterthougth (one of the other is the four types of translator/encoder, but that's for an other thread). So, thank you for having some time to start this thread. My personal experience is rather similar than yours: Tapestry component abstraction seems to leak with Ajax (perhaps it's the price for T5 component not being fully statefull, and perhaps it's better like that). As soon as you want to do Ajaxified components, you have to take care by hand to a lot of more things than for normal request: component id and id availability (you are not in a standards Render cycle, ids are not available), you must differentiate normal/xhr request on event handler, you must enforce component bounds... Now, what can we actually purpose ? You're approach (a component return null on XHR = refresh himself, return a component on XHR = refresh this component) seems to me more consistent with T5. But it seems to be a major evolution, the kind that will be difficult to sell along with easy update of T5. Moreover, as you said, it's likelly that somewhere, the full dom tree will have to be build, and it seems not really efficient. And finally, it's too late for Tapestry 5.0 final. So, for now, what I REALLY need and want with priority #1 is a lot of documentation on how using AJAX with T5 the right way: general pifalls to avoid, what information are available (state of the server view of the DOM on XHR, etc), what are all the differences with normal request (you don't have access to a bunch of things), etc. And for the long run, yes, perhaps we have to see how to make AJAX simpler. Perhaps just a different handler naming convention for xhr would be a good start, as they are actually differents (onMyeventFromComponent and onXhrMyeventFromComponent ? So that user would have to really take care of the two case
Re: T5's Ajax/Zone implementation has substantial limitations
Hi, 2009/1/7 Francois Armand farm...@linagora.com So, for now, what I REALLY need and want with priority #1 is a lot of documentation on how using AJAX with T5 the right way: general pifalls to avoid, what information are available (state of the server view of the DOM on XHR, etc), what are all the differences with normal request (you don't have access to a bunch of things), etc. and several small EXAMPLES with comments/explanations that should be available in a Ajax tutorial. Right now, one must hunt for the T5 projects available on the net, download and examine them. Some of them you will find outdated and for none of them one can not be sure if they are done the right way. Can a list of such educational examples be made in a new thread? Cheers, Borut
Re: T5's Ajax/Zone implementation has substantial limitations
I think it's important to separate the core tapestry zone infrastructure from the Javascript zone wrappers. I have a lot of Ajax in my application - it's a systems management console /dashboard - and pretty early on I decided to use the Tapestry zone Javascript as template and use my own javascript against the standard tapestry core.I do things like update zones from a Javascript poller (calling an actionlink from a Javascript function) and updating multiple zones with one server call (the JSON key is not contents but there are several objects keyed by the zone name). Given a suitable Tapestry JSON layer, I believe that zones should be handled as a component library issue. My main issue with the T5 zone is is the need to instantiate all components in the template. In general, this is an example of the dynamic rendering issue that comes up occasionally. I should NOT have to put all possible components into my template a-priori. In my case, I have a number of alarm conditions that require user input and use AJAX components in a div provide condition-based user response. Right now it's a pain to add components to the template for the 10 user conditions I current have, but what happens over time when I have 100's of possible user responses. In other words, I agree with Francois to a point. I think Tapestry5 was designed to render pages and doesn't naturally handle dynamic updates. That paradigm works well for rendered pages but should be relaxed for components rendered via JSON XHR requests. If I have a div in the template and want to change the contents T5 should let me drop in any component I want even it it hasn't been defined in the template. Another area where zones break is in embedded forms and form support. I'd love to be able to register a component with a form, drop it into the page, then later deregister the component and put in another. I'm summary, I think zones need: 1) JSON components returned via XHR should have their own render cycle and should not have to be defined in the template . 2) API support to 'register' a component with a form, then to deregister if when that component is replace. 3) A stable JSON/XHR interface in Tapestry core that will allow component developers to create zone-like components that do things like update cells in grids, extend forms based upon a select, etc. Regards, Chuck Kring Francois Armand wrote: Avi Cherry wrote: First off, I want to say that I'm a huge supporter, advocate (and long time user) of Tapestry, particularly T5. Hello Avi, [...] a lot of intersting things To be honest, the Ajax support on Tapestry 5 is one of the rare things that seems to be not _just_rigth_ on the framework, as if it has been an afterthougth (one of the other is the four types of translator/encoder, but that's for an other thread). So, thank you for having some time to start this thread. My personal experience is rather similar than yours: Tapestry component abstraction seems to leak with Ajax (perhaps it's the price for T5 component not being fully statefull, and perhaps it's better like that). As soon as you want to do Ajaxified components, you have to take care by hand to a lot of more things than for normal request: component id and id availability (you are not in a standards Render cycle, ids are not available), you must differentiate normal/xhr request on event handler, you must enforce component bounds... Now, what can we actually purpose ? You're approach (a component return null on XHR = refresh himself, return a component on XHR = refresh this component) seems to me more consistent with T5. But it seems to be a major evolution, the kind that will be difficult to sell along with easy update of T5. Moreover, as you said, it's likelly that somewhere, the full dom tree will have to be build, and it seems not really efficient. And finally, it's too late for Tapestry 5.0 final. So, for now, what I REALLY need and want with priority #1 is a lot of documentation on how using AJAX with T5 the right way: general pifalls to avoid, what information are available (state of the server view of the DOM on XHR, etc), what are all the differences with normal request (you don't have access to a bunch of things), etc. And for the long run, yes, perhaps we have to see how to make AJAX simpler. Perhaps just a different handler naming convention for xhr would be a good start, as they are actually differents (onMyeventFromComponent and onXhrMyeventFromComponent ? So that user would have to really take care of the two case ?) - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5's Ajax/Zone implementation has substantial limitations
Avi Cherry wrote: First off, I want to say that I'm a huge supporter, advocate (and long time user) of Tapestry, particularly T5. Hello Avi, [...] a lot of intersting things To be honest, the Ajax support on Tapestry 5 is one of the rare things that seems to be not _just_rigth_ on the framework, as if it has been an afterthougth (one of the other is the four types of translator/encoder, but that's for an other thread). So, thank you for having some time to start this thread. My personal experience is rather similar than yours: Tapestry component abstraction seems to leak with Ajax (perhaps it's the price for T5 component not being fully statefull, and perhaps it's better like that). As soon as you want to do Ajaxified components, you have to take care by hand to a lot of more things than for normal request: component id and id availability (you are not in a standards Render cycle, ids are not available), you must differentiate normal/xhr request on event handler, you must enforce component bounds... Now, what can we actually purpose ? You're approach (a component return null on XHR = refresh himself, return a component on XHR = refresh this component) seems to me more consistent with T5. But it seems to be a major evolution, the kind that will be difficult to sell along with easy update of T5. Moreover, as you said, it's likelly that somewhere, the full dom tree will have to be build, and it seems not really efficient. And finally, it's too late for Tapestry 5.0 final. So, for now, what I REALLY need and want with priority #1 is a lot of documentation on how using AJAX with T5 the right way: general pifalls to avoid, what information are available (state of the server view of the DOM on XHR, etc), what are all the differences with normal request (you don't have access to a bunch of things), etc. And for the long run, yes, perhaps we have to see how to make AJAX simpler. Perhaps just a different handler naming convention for xhr would be a good start, as they are actually differents (onMyeventFromComponent and onXhrMyeventFromComponent ? So that user would have to really take care of the two case ?) -- Francois Armand Etudes Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- http://fanf42.blogspot.com InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5's Ajax/Zone implementation has substantial limitations
Hi Avi! First I've to say I really like tapestry 5 and its huge improvements over T4. Most of all the live class reloading! At the moment I am trying to do an integration of T5 with extjs. Till now it seems to go quite good. I can render ext components over to the client use informal parameters on them and use the inheritance of components to do in a very lean way. Some days ago I started with the AJAX part. So first thing I needed was the use of tapestry event handlers to add client side event. Things are going quite well, now I am at the point where I add an @OnEvent annotation or have an event listener method signature (on) the event handler is added on the fly to the client side component. But now I am at the point where I am fiddling arround with updates to the client side. For me the easiest thing would be to get the output of a specific rendered component, which is nothing different than some json objects that I can integrate into my return value (which is again a json object). With this approach. Several components could get updated, added or any other operation executed on the client. This would be all I need for ajax (as far as i can consider now). Has someone an idea if this is already possible and how this could get achieved, or if the approach is not useful at all? Kind regards, Robert Am 07.01.2009 um 03:05 schrieb Avi Cherry: First off, I want to say that I'm a huge supporter, advocate (and long time user) of Tapestry, particularly T5. Secondly, I'd like to say that I hope this can be the start of a rational discussion about the merits and limitations of the current 'Zone' approach as well as possible ways to improve the model. Finally, I'm hoping that Howard, if available, would be able to comment on some of this so that the current design's goals could be more apparent as well as future plans for Ajax support. So, the approach that T5 has now for implementing ajax requests and zones is as follows: A XHR is made to the server, triggering an event. The event optionally returns a reference to a component that gets rendered (more or less) in isolation, turned into a JSON message and returned to the client. On the client, the contents of the zone specified by the form or link is replaced by the 'content' portion of the JSON reply payload. If no component is returned, the target zone is emptied. So broken down, this approach has the following characteristics: 1) The content returned to client can be dynamically chosen by the event handler. 2) The target 'zone' for any form/link is static, so any link or form can only ever update the same zone, regardless of the results of the event. I believe the zone a link is bound to -can- be changed on the client, but only -before- a request is made, not as the result of an event. It cannot be changed based on the results of an event on the server. 3) Only a single zone can be updated in any one request 4) A component being rendered within a zone can easily be in an inconsistent state, since surrounding components may or may not have been rendered, depending on where the 'zone' is placed. 5) Relying on the state of a component while it's handling an event is essentially impossible unless its state at rendering is serialized. This, I believe, can only be done if the component is inside of a Form. I believe this is an inherent limitation of Tapestry's event handling and not specific to the Ajax support, but I still believe that this is a severe 'leak' in the abstraction that Tapestry attempts to provide. Characteristic #1 seems okay to me, but -nearly- all of the time, I have found that I want a component to re-render in place, rather than to replace the content inside of the zone with a different component. The remaining characteristics each provide particular roadblocks when attempting to to use AJAX in otherwise common situations. Characteristic #2 is a problem. Going back to #1, I would nearly always find it more useful to be able to specify in the event handler where on the page I want components to re-render themselves, rather than what component I want to insert into the position specified by the zone. A combination of #1 and #2 together provide a rather different behavior of event handlers depending on if they're XHR or not. Making them behave exactly the same is clearly not possible, but I see there as being a fairly major discrepancy between the two: When a page handling a standard request event wants to merely refresh the page, it can either return null or have a method with a void return value. A component that handles an event can additionally achieve a content refresh by returning null or void from the event handler method. The component does NOT have to have any knowledge of the page that it is inside in order to re-fresh the contents of that page. When a page
