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
