[Proto-Scripty] Re: Stopping event propagation on a event handler added through onClick property
Hi Jay,
No problem. Yes, it was always function for me as well, but I was
feeling paranoid. :-)
-- T.J.
On Mar 19, 8:30 pm, Jay wrote:
> Thanks!!! T.J. that solved it.
> Here is piece of code I have now:
>
> var DOM0Handler = $(n).onclick;
> $(n).onclick = "";
> n.observe('click', function(evt) {
> alert('im done!');
> if (conditiontrue)
> DOM0Handler();
> else
> return;
>
> });
>
> type value of onclick is always function for me so I just need to
> invoke it.
> Thanks a lot!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Stopping event propagation on a event handler added through onClick property
Thanks!!! T.J. that solved it.
Here is piece of code I have now:
var DOM0Handler = $(n).onclick;
$(n).onclick = "";
n.observe('click', function(evt) {
alert('im done!');
if (conditiontrue)
DOM0Handler();
else
return;
});
type value of onclick is always function for me so I just need to
invoke it.
Thanks a lot!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Stopping event propagation on a event handler added through onClick property
Hi Jay,
> > Is it really necessary to use old DOM0-style event handlers (the
> > attribute on the tag) and modern event attachment in the same app?
>
> Sigh.. I absolutely agree with you 100% on this. However, I do not
> have control over how this is.
Yeah, we've all had that problem. :-)
What is the actual goal? To attach a handler to the submit button
that fires before the one attached to the onclick, and (in some cases)
prevents the onclick from happening? Because if it's that, you can
probably grab the DOM0 handler and then disconnect it:
* * * *
// At load time; here it's in a dom:loaded but whatever
document.observe("dom:loaded", function() {
var btnGo;
var dom0handler;
// Get the submit button
btnGo = $('btnGo');
// Grab its current DOM0 handler
dom0handler = btnGo.onclick;
// Clear it
btnGo.onclick = '';
// Hook up your handler
btnGo.observe('click', function(event) {
var rv;
alert("Your logic goes here");
if (/* whatever decides whether to fire the old handler */) {
// Chain to the DOM0 handler, if any
if (Object.isString(dom0handler)) {
rv = eval(dom0handler);
}
else if (Object.isFunction(dom0handler)) {
rv = dom0handler(event);
}
if (!Object.isUndefined(rv) && !rv) {
// Handler returned something false-y, cancel
event.stop();
}
}
});
});
* * * *
(Also on Pastie: http://pastie.org/420790)
Obviously you''ll want to make sure you satisfy the DOM0 handler's
expectations; the above just passes in the Prototype event object, but
doesn't set 'this' or anything like that. You'll have to look at the
DOM0 handler to see what it's expecting. The above *does* check for a
return value and, if found and if false-y, stops the event -- that's
typically what returning false from a DOM0 means. This is not tested
code, although it worked okay on first glance on the browsers I tried
-- FF3, Opera9, IE7, Safari3, Chrome1 (all on Windows).
HTH,
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On Mar 19, 7:08 am, Jay wrote:
> > I don't think input elements have a submit event. Form elements do.
> > So that would be step one. :-)
>
> Ah.. you're right. I did ('myinput').observe('click', foofunc); not
> 'submit'.
> Thanks for catching this. So I'm basically adding another handler tied
> to exact same event as the DOM0 style handler.
>
> > Is it really necessary to use old DOM0-style event handlers (the
> > attribute on the tag) and modern event attachment in the same app?
>
> Sigh.. I absolutely agree with you 100% on this. However, I do not
> have control over how this is.
> The DOM0-style comes from the server and I'm implementing a solution
> that is strictly on client side hence the ugliness of the code.
>
> >Out of curiousity, what kind of input element is it? (That elipsis
> >could cover a lot of ground.) button? submit? text? checkbox?
>
> It is submit button.
> I appreciate any suggestion on how I might solve this problem. Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Stopping event propagation on a event handler added through onClick property
> I don't think input elements have a submit event. Form elements do.
> So that would be step one. :-)
Ah.. you're right. I did ('myinput').observe('click', foofunc); not
'submit'.
Thanks for catching this. So I'm basically adding another handler tied
to exact same event as the DOM0 style handler.
> Is it really necessary to use old DOM0-style event handlers (the
> attribute on the tag) and modern event attachment in the same app?
Sigh.. I absolutely agree with you 100% on this. However, I do not
have control over how this is.
The DOM0-style comes from the server and I'm implementing a solution
that is strictly on client side hence the ugliness of the code.
>Out of curiousity, what kind of input element is it? (That elipsis
>could cover a lot of ground.) button? submit? text? checkbox?
It is submit button.
I appreciate any suggestion on how I might solve this problem. Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Stopping event propagation on a event handler added through onClick property
Hi,
> And later, I'm adding another event handler to it with $
> ('myinput').observe('submit', foofunc);
I don't think input elements have a submit event. Form elements do.
So that would be step one. :-)
Is it really necessary to use old DOM0-style event handlers (the
attribute on the tag) and modern event attachment in the same app?
Wouldn't it be cleaner to use observe() for all of your event
handlers, rather than mix-and-match? Or, I suppose, use DOM0 for
everything, but there's a reason things have moved on in the last
decade and a half or so... ;-)
>
Out of curiousity, what kind of input element is it? (That elipsis
could cover a lot of ground.) button? submit? text? checkbox?
>From your overall question I'm thinking it's probably a submit button,
but...
> It so happens that the handler i've added through observe is always
> getting called first (I'm not 100% of this BTW. Is this true that
> handlers added later will always execute first?)
No, I'm afraid not. The order in which handlers for the *same* event
on the *same* element are called is undefined and implementation-
specific (most browsers do it one way, IE does it a different way).
Separately, the order of DOM0 handlers relative to the chain of modern
handlers is also not defined.
The order of some events (as opposed to handlers) is defined or at
least consistent, though: For instance, if you have a submit button
in a form with a click handler where the form has a submit handler,
the click event on the button fires before the submit event on the
form in every browser I'm aware of (it's probably even defined
somewhere, but I don't have a reference for it).
Probably the best way forward is to step back and tell us what the
ultimate goal and any related constraints are; I'm sure once we know,
one of us will be able to make some helpful suggestions.
FWIW,
--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available
On Mar 18, 5:13 am, Jay wrote:
> I'm using prototype 1.6+ and I can't figure this out.
>
> There is event handler registered through the onclick HTML property.
>
>
>
> And later, I'm adding another event handler to it with $
> ('myinput').observe('submit', foofunc);
> It so happens that the handler i've added through observe is always
> getting called first (I'm not 100% of this BTW. Is this true that
> handlers added later will always execute first?) So far so good.
>
> But based on logic I have in foofunc, I need to stop the propagation
> from exucuting javascript code registered through onClick property but
> I can't do this.
> Calling event.stop() won't help either.
> I'd love any suggestions on this. Thanks.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
