You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Fernando Padilla <fe...@alum.mit.edu> on 2009/01/13 08:00:45 UTC
zone enhancements?
We are starting to use zones a lot more and they are a great and simple
concept. I was wondering if anyone had any comments or had put any
legwork towards these simple enhancements.
1) updatingEffects
along the lines of the showEffect and updateEffect currently
supported, except that this would be an effect to run while the
zoneManager was fetching the content (ajax request).
Could be as simple as a modal gray out, with a loading spinner...
or completely remove previous content, and replace with "Loading..."
2) no outstanding updates
if I keep clicking on a link while the zone is still fetching the new
content, it will keep firing off ajax calls.. add a way to ignore new
update requests, until the currently running one finishes..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: zone enhancements?
Posted by Fernando Padilla <fe...@alum.mit.edu>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: zone enhancements?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 13 Jan 2009 10:28:48 -0300, Lutz Hühnken
<lh...@googlemail.com> escreveu:
> 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:
On the other hand, Prototype provides some global callbacks that can be
used for any XMLHttpRequest request in a given page. AFAIK it can be a way
to implement mixins that provide some behaviour like disabling the whole
page and showing an animated GIF during a request, etc.
It's documented here: http://www.prototypejs.org/api/ajax/responders.
Disclaimer: I have never used it yet, but it does looks interesting. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: zone enhancements?
Posted by Lutz Hühnken <lh...@googlemail.com>.
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
--
altocon GmbH
http://www.altocon.de/
Software Development, Consulting
Hamburg, Germany
On Tue, Jan 13, 2009 at 8:00 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> We are starting to use zones a lot more and they are a great and simple
> concept. I was wondering if anyone had any comments or had put any legwork
> towards these simple enhancements.
>
>
> 1) updatingEffects
> along the lines of the showEffect and updateEffect currently supported,
> except that this would be an effect to run while the zoneManager was
> fetching the content (ajax request).
>
> Could be as simple as a modal gray out, with a loading spinner...
> or completely remove previous content, and replace with "Loading..."
>
>
> 2) no outstanding updates
> if I keep clicking on a link while the zone is still fetching the new
> content, it will keep firing off ajax calls.. add a way to ignore new update
> requests, until the currently running one finishes..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org