You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Avi Cherry <av...@cherrydev.com> on 2009/01/07 03:05:06 UTC
T5's Ajax/Zone implementation has substantial limitations
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 handling an XHR request wants to refresh a zone, the event
handler must explicitly return the particular component or zone that
will be refreshed. In addition, this must match the zone bound to the
form or the link in order to achieve a refresh. Even worse, if an
event handler on a -component- wishes to achieve a refresh of a zone
within a request the component is involved with, there is effectively
no way to do this unless that component itself was the source of the
event or otherwise explicitly binding the zone -again- to the component.
If you wish to see an example of how complicated it can be to
implement a solution to a seemingly simple problem of an in-place
component refresh when there are multiple collaborating components,
one need only look at Tapestry's built-in Grid component:
When inPlace is flagged true, on the grid, the following code
artifacts must be implemented:
1) Grid must synthesize a zone to contain itself
2) Grid must pass this zone to the GridPager it contains
3) GridPager has to explicitly 'link' the Links that it generates to
the zone passed by Grid
4) GridPager must trigger a secondary event during handling of the
'action' events
5) Grid must handle this secondary event, but since it's not the
primary event (I assume this is the reason?), it must explicitly call
into the componentEventResultProcessor in order to re-render itself
into the JSON result.
If the return value of an event handler behaved in such a way that on
an XHR request, the component that was returned was automatically
refreshed, the implementation would be more like:
1) GridPager implements an onAction event handler that changes the
current page and returns false to indicate the event may not have been
completely handled. This handler behaves identically for a non XHR
request.
2) Grid implements an onAction event handler as well. It would return
itself, or perhaps null, to indicate that it should re-render in
place. Again, this handler behaves identically for a non XHR request.
Characteristic #3 is a rather large limitation. Take, for example, a
page that's laid out such that there is a 'status' area in the
'layout' component that would display some status messages pushed to
it by the service/business layer and then in the mail body of the
page, an active area that has links/form that can perform actions.
There is no simple way to update both the status area and the active
area on the page. I believe a mechanism that allows for multiple
parts of the page to be updated in a single request would be extremely
valuable in making the Ajax support more useful. I've been able to
partially work-around this by getting ajax requests to cascade: The
first ajax reply includes a script in the JSON payload that triggers a
2nd ajax link/form.
Characteristic #4 is really, really tricky... I believe that parts of
this had to be overcome to allow for Forms to work at ALL when they
have zones inside of them. The only complete solution that I can
think of is to do a complete render of the page and cherry-pick
portions of the DOM to send back to the client. This is obviously far
from ideal, but seems to be an inherent limitation of any system that
uses nested components.
Characteristic #5 I don't think I really want to get into right now,
since I honestly have a large gap of knowledge as to what is going on
here.
So, my extremely rough-draft proposal would be as follows:
Get rid of the concept of zones, since I don't believe they're
necessary in my model.
Components that update during an XHR request will always refresh
themselves in-place.
A component that terminates an event (by returning anything other than
false) will refresh refresh itself when the return value is void or
null or will trigger a refresh of any component explicitly returned.
This is rather similar to the behavior of non-Ajax event handlers now
There should be some mechanism for allowing the refresh of multiple
components. This could either be done entirely by the event handler
by returning a Collection of components, or with an injected Tapestry
service that allows an event handler to add components to a queue.
If you wanted to then achieve the -effect- of the current ability to
place an arbitrary component chosen by the event handler into a zone
(say with a tab view, for example), you could achieve it in exactly
the same way that you achieve it in a non-ajax page, with delegates
and blocks, where you simply re-render the delegate which will then
render a block from a property.
What I haven't though about much is what happens if a component that
you want to refresh is inside of a loop, but I believe in the current
implementation you have to use the special-purpose AjaxFormLoop inside
of a Form to be able to make use of any ajax inside of a loop.
I'm really, really hoping that I'll get some feedback on these ideas
and to hear other people's experience using T5's current Ajax
implementation.
Ideas? Feedback?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5's Ajax/Zone implementation has substantial limitations
Posted by Robert Binna <r....@synedra.com>.
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 handling an XHR request wants to refresh a zone, the
> event handler must explicitly return the particular component or
> zone that will be refreshed. In addition, this must match the zone
> bound to the form or the link in order to achieve a refresh. Even
> worse, if an event handler on a -component- wishes to achieve a
> refresh of a zone within a request the component is involved with,
> there is effectively no way to do this unless that component itself
> was the source of the event or otherwise explicitly binding the zone
> -again- to the component.
>
> If you wish to see an example of how complicated it can be to
> implement a solution to a seemingly simple problem of an in-place
> component refresh when there are multiple collaborating components,
> one need only look at Tapestry's built-in Grid component:
> When inPlace is flagged true, on the grid, the following code
> artifacts must be implemented:
> 1) Grid must synthesize a zone to contain itself
> 2) Grid must pass this zone to the GridPager it contains
> 3) GridPager has to explicitly 'link' the Links that it generates to
> the zone passed by Grid
> 4) GridPager must trigger a secondary event during handling of the
> 'action' events
> 5) Grid must handle this secondary event, but since it's not the
> primary event (I assume this is the reason?), it must explicitly
> call into the componentEventResultProcessor in order to re-render
> itself into the JSON result.
>
> If the return value of an event handler behaved in such a way that
> on an XHR request, the component that was returned was automatically
> refreshed, the implementation would be more like:
> 1) GridPager implements an onAction event handler that changes the
> current page and returns false to indicate the event may not have
> been completely handled. This handler behaves identically for a non
> XHR request.
> 2) Grid implements an onAction event handler as well. It would
> return itself, or perhaps null, to indicate that it should re-render
> in place. Again, this handler behaves identically for a non XHR
> request.
>
> Characteristic #3 is a rather large limitation. Take, for example,
> a page that's laid out such that there is a 'status' area in the
> 'layout' component that would display some status messages pushed to
> it by the service/business layer and then in the mail body of the
> page, an active area that has links/form that can perform actions.
> There is no simple way to update both the status area and the active
> area on the page. I believe a mechanism that allows for multiple
> parts of the page to be updated in a single request would be
> extremely valuable in making the Ajax support more useful. I've
> been able to partially work-around this by getting ajax requests to
> cascade: The first ajax reply includes a script in the JSON payload
> that triggers a 2nd ajax link/form.
>
> Characteristic #4 is really, really tricky... I believe that parts
> of this had to be overcome to allow for Forms to work at ALL when
> they have zones inside of them. The only complete solution that I
> can think of is to do a complete render of the page and cherry-pick
> portions of the DOM to send back to the client. This is obviously
> far from ideal, but seems to be an inherent limitation of any system
> that uses nested components.
>
> Characteristic #5 I don't think I really want to get into right now,
> since I honestly have a large gap of knowledge as to what is going
> on here.
>
>
> So, my extremely rough-draft proposal would be as follows:
>
> Get rid of the concept of zones, since I don't believe they're
> necessary in my model.
> Components that update during an XHR request will always refresh
> themselves in-place.
> A component that terminates an event (by returning anything other
> than false) will refresh refresh itself when the return value is
> void or null or will trigger a refresh of any component explicitly
> returned. This is rather similar to the behavior of non-Ajax event
> handlers now
> There should be some mechanism for allowing the refresh of multiple
> components. This could either be done entirely by the event handler
> by returning a Collection of components, or with an injected
> Tapestry service that allows an event handler to add components to a
> queue.
>
> If you wanted to then achieve the -effect- of the current ability to
> place an arbitrary component chosen by the event handler into a zone
> (say with a tab view, for example), you could achieve it in exactly
> the same way that you achieve it in a non-ajax page, with delegates
> and blocks, where you simply re-render the delegate which will then
> render a block from a property.
>
> What I haven't though about much is what happens if a component that
> you want to refresh is inside of a loop, but I believe in the
> current implementation you have to use the special-purpose
> AjaxFormLoop inside of a Form to be able to make use of any ajax
> inside of a loop.
>
> I'm really, really hoping that I'll get some feedback on these ideas
> and to hear other people's experience using T5's current Ajax
> implementation.
>
> Ideas? Feedback?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5's Ajax/Zone implementation has substantial limitations
Posted by Peter Stavrinides <P....@albourne.com>.
Is there a Jira for this to vote on?
----- Original Message -----
From: "Chuck Kring" <cj...@pacbell.net>
To: "Tapestry users" <us...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5's Ajax/Zone implementation has substantial limitations
Posted by Chuck Kring <cj...@pacbell.net>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5's Ajax/Zone implementation has substantial limitations
Posted by Borut Bolčina <bo...@gmail.com>.
Hi,
2009/1/7 Francois Armand <fa...@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
Posted by Francois Armand <fa...@linagora.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org