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 ?) > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
