If you want to learn about how zones are implemented, this is the code
you'll have to review:
in tapestry.js:
Tapestry.ZoneManager
Tapestry.Initializer.zone
Tapestry.Initializer.linkZone
in java:
ClientBehaviorSupport.addZone
ClientBehaviorSupport.linkZone
RenderSupport.addInit
Essentially, when you do <t:zone>, it calls
ClientBehaviorSupport.addZone, which calls Tapestry.Initializer.zone,
which ties a ZoneManager to that element.
Once you have a zone manager, that is the actual code that manages the
update/show/geturl, etc..
when you have a form or link that use zones, they call
ClientBehaviorSupport.linkZone, then Tapestry.Initializer.linkZone
hijacks the submit/click events and pipe them through the zoneManager
instead to update only the desired Zone.
So.. the ZoneManager is what would have to be enhanced.. to add more
concepts of callbacks/effects.. etc.
As to the single click, I think it would be best to do in the client
side. really.. why for the us tapestry developers to keep adding cruft
around all of our action/form/events etc.. and have to deal with global
locks/semaphores!! :) When you can simply have the ZoneManager track a
single variable on the client side :) :) Of course I'm not talking
about critical pieces of code, just for general cleanliness, and avoid
user confusion if they click multiple times and it updates multiple
times without them expecting it.
Lutz Hühnken wrote:
Fernando,
I agree with you, especially your suggestion (1) would be very helpful
and a welcome addition. The form/zone combination could maybe include
more callback hooks. I think I have a case of Rails envy, look at the
callbacks you can use for the remote_form_tag:
The callbacks that may be specified are (in order):
:loading: Called when the remote document is being loaded with data by
the browser.
:loaded: Called when the browser has finished loading the remote
document.
:interactive: Called when the user can interact with the remote document,
even though it
has not finished loading.
:success: Called when the XMLHttpRequest is completed,
and the HTTP status code is in the 2XX range.
:failure: Called when the XMLHttpRequest is completed,
and the HTTP status code is not in the 2XX range.
:complete: Called when the XMLHttpRequest is complete (fires after
success/failure if
they are present).
You can further refine :success and :failure by adding additional callbacks for
specific
status codes. A status code callback overrides the success/failure handlers if
present.
If you for some reason or another need synchronous processing (that'll block
the
browser while the request is happening), you can specify options[:type] =
:synchronous.
You can customize further browser side call logic by passing in JavaScript code
snippets via some optional parameters. In their order of use these are:
:confirm: Adds confirmation dialog.
:condition: Perform remote request conditionally by this expression.
Use this to describe browser-side conditions when request should not be
initiated.
:before: Called before request is initiated.
:after: Called immediately after request was initiated and before :loading.
:submit: Specifies the DOM element ID that's used as the parent of the
form elements.
By default this is the current form, but it could just as well be the ID of a
table
row or any other DOM element.
:with: A JavaScript expression specifying the parameters for the
XMLHttpRequest.
Any expressions should return a valid URL query string.
With this, you could easily show a DIV with a spinner gif / busy
indicator "after" the click, and hide it again when on "complete":
<% form_remote_tag :url => { :action => "search" },
:after => "Element.show('loading');
Element.hide('results')",
:update => :results,
:complete =>
"Element.hide('loading'); Element.show('results')" do %>
Oh, I'd love to have that in Tapestry. Doesn't Rails use
script.aculo.us, just like Tapestry? Wouldn't that be easy to
implement, given the hard part is done by script.aculo.us anyway? I've
never really looked at it, but I think the Tapestry tags don't produce
script.aculo.us code directly, the library is wrapped and thereby only
a reduced functionality is available. Thinking about it.. in
script.aculo.us, you can customize the effects (like the highlight and
fade) with parameters, such as hightlight time and colour. This also
is lost in Tapestry.
Assuming I would wish to extend the script.aculo.us integration, in
order to provide all those AJAX form callbacks, and effects
parameters.. what would be the way to go? What would be a good place
to start?
About (2) - I think that could maybe be more easily handled on the
server-side, using a transaction/synchronization token, like you would
to prevent regular forms from being double-submitted.
Lutz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
