sorry its taken me so long to get back in here and reply but I've been
fighting with my own ignorance heh. I got so caught up in the
initial problem in here I forgot details about the extra logic I
needed, to do exactly what I want when the buttons are clicked.
I am disabling each and every input button on the page when one is
clicked. When i added this code it was stopping the form from
submitting ( in ie6) it just took waisting several hours scratching me
head to remember that disabling submit buttons on click stops form
submission in IE(not sure about newer IE versions but it does this in
6). Initally i was just using alert("clicked"); to troubleshoot
problem. The actual code w/ logic now looks like
document.observe('click',function(evt){
var elm = evt.element();
if (elm.tagName == 'A' ){
if (elm.getAttribute('href') != "#"){
$('processing_gif').show()
};
}else if( elm.getAttribute("type") == 'submit' ){
$('processing_gif').show();
$$('input[type="submit"]').invoke('disable');
elm.up('form').submit();
}
} );
as you can see I'm handling the buttons and anchors differently.
Anchors are simply showing the animated spinner. while buttons show
the spinner and disable the rest of the buttons on that page. the
current problem is elm.up('form').submit(); is failing. I discovered
it is because when these pages were initially written the input
buttons have the type, value, and, name all set to submit. which is
bombing submit(). If I change the name of the submit buttons
everything functions correctly. Which leads me to the question. Is
there a way for submit() to function with <input name="submit"
type="submit" /> because that is so ingrained into the html and back
end code that if I cannot I need to re approach a different way in
javascript.
Thanks again for all of your help.
On May 23, 2:59 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> Hi,
>
> > This does bring into question in my mind the order of onclick vs.
> > forum submission. right now the 2 buttons i've been testing this with
>
> FWIW, I think the question you have to ask is why you're seeing this
> behavior but I'm not, and moreover, I haven't heard of it either --
> this suggests there's something very strange going on specific to your
> page. At first I thought it was form submission too, but a quick
> check with IE6 showed that I got the alert before the form was
> submitted. Here's the page I was testing with.[1] As shown there, it
> will alert and then submit the form to blank.html, but there's some
> commented-out code to prevent the form submission. Either way, I got
> the click alert.
>
> [1]http://pastie.org/487167
>
> HTH,
> --
> T.J. Crowder
> tj / crowder software / com
> Independent Software Engineer, consulting services available
>
> On May 22, 5:29 pm, ykaerflila <ykaerfl...@gmail.com> wrote:
>
> > well its not a version issue. I just copied the js files from to
> > another to confirm and the issue still persists with dom:loaded
>
> > as far as timing goes the submit buttons I'm observing for clicks are
> > static HTML elements. I had been assuming all static HTML is loaded
> > upon dom:load (but admittedly I've never looked to confirm that it
> > just seem to make sense =)
>
> > This does bring into question in my mind the order of onclick vs.
> > forum submission. right now the 2 buttons i've been testing this with
> > submit a form when clicked. In FF I see the alert window telling me
> > the 'click' observer is firing off before the form is getting
> > submitted. in IE6 I see nothing so is there a possibility that the
> > form is actually getting submitted before the 'click' observer fires
> > off?
>
> > Then again maybe I'm going about all of this the wrong way. what I'm
> > shooting for here is to show a loading spinner on the page on each
> > click of links and selected input buttons. hence the $$
> > ('a','.processing'). The site I'm working on has some AJAX and each
> > AJAX request shows/hides a processing spinner. some of the bigger page
> > requests and during peak times users are multi clicking buttons
> > because they are looking for the AJAX processing spinner(even on non
> > ajax requests) rather than watching the IE window and thinking nothing
> > is going on. so what i sat out to do was simply show the processing
> > spinner via each click of an anchor tag or button which has
> > the .processing class attached to it. all it needs to do is .show()
> > the spinner div onclick but i'd rather not have to go through each
> > link and button to add onclick="$('spinner').show()". IE 6 is
> > important because this runs in XPe terminals which of course are all
> > running IE6 =)
>
> > On May 22, 9:53 am, Walter Lee Davis <wa...@wdstudio.com> wrote:
>
> > > You may find that you are using the same version on both sites, which
> > > means that my solution fixed the problem, but not for the reason I
> > > thought.
>
> > > There may be a timing/latency issue somewhere else in your code that
> > > is resolved by the DOM being completely settled (onload is very late
> > > in the game, the page is already visible in its entirety in the
> > > browser).
>
> > > You might want to look through for some cases where you expect a thing
> > > to be there -- if you act on any element blindly assuming its
> > > existence -- and see if wrapping that up in a condition makes the site
> > > work again under dom:loaded.
>
> > > It's just a hunch, mind you.
>
> > > Walter
>
> > > On May 22, 2009, at 9:58 AM, ykaerflila wrote:
>
> > > > That worked like a champ. I changed
> > > > document.observe("dom:loaded", code.launch );
> > > > to
> > > > Event.observe(window,'load', function(event){
> > > > $$('.processing').invoke('observe', 'click', function(ev) {
> > > > alert('clicked');
> > > > });
> > > > });
>
> > > > Now everything is working as expected. I'm using the same
> > > > document.observer("dom:loaded"... in another script as I mentioned
> > > > which is working properly( its only being used on checkboxes and divs)
> > > > so now I'm curious heh. I was pretty sure I used the exact same
> > > > version of prototype on the 2 sites, guess I'll go double check just
> > > > to see.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
