Re: T5 actionlink, ajax zone and user onclick handler

[Kalle Korhonen <ka...@gmail.com>]

On Tue, Apr 29, 2008 at 9:14 AM, Chris Lewis <ch...@bellsouth.net> wrote:
> Unfortunately I can't think of a clean workaround for that. The issues
> are all in the javascript and how events are dispatched and handled.
> Basically it comes down to 2 problems:

This is an old thread but found it when I run into a similar issue.

> 1) The W3C does not mandate even handler ordering, so if you register a
> handler before another there is no guarantee that it will actually fire
> before the other. Lame.

I wouldn't say it's lame, it's just the way it is. No other event
system I know of would ever allow ordering event handlers. In fact,
treating all handlers equally allows an option for executing them in
parallel (even if current Javascript engines don't do that).

> 2) Stopping the DOM event only stops it's propagation to subsequent DOM
> elements and not subsequent handlers. So that means that even if you
> knew your handler would fire first, stopping the event will not stop the
> zone handler from firing.
> Coincidentally my tests show that the mixin's JS handler is fired first,
> but that's no guarantee. If it was then you could override the

First of all, thanks for the well-written wiki page Chris, it's very
informative. I'd think the right way to solve the problem is to use
event propagation as intended. That is, in the case of confirm(), you
should target the element inside of your actionlink - for example:

<t:actionlink t:id="deleteLink" t:zone="zoneToUpdate"><span
id="confirmDelete">delete</span></t:actionlink>

Then add a handler for the nested element:
Event.observe($('confirmDelete'), 'click', function(event) {if
(!confirm('are you sure to delete this record ?')) event.stop();});
to stop the event from being propagated to the actionlink handler.

You could probably attach the confirm mixin to an Any component
outputting a span. If you put a button inside, it'd be even easier
since you could just do onclick="return confirm(...);". Unfortunately
it's not possible, or at least not trivial, to create a mixin that you
could attach to the parent element but make it listen to a "click"
event of a nested element - and I don't think it would be cool if the
mixing would programmatically modify the parent element (since that's
how I see you could get it done if you really wanted to).

Kalle

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org