xsl-list
[Top] [All Lists]

Re: [xsl] Preventing second click

2006-09-28 15:58:19
Oleg Konovalov wrote:
No, I don't use AJAX or CSS [and not planning to do that].
What I don't understand why on the "grandparent" form
I can not get a value for that button declared on its grandchild.
So for "document.formname.btnname" or "window.document.formname.btnname"
I get "undefined" on that grandparent,
for "document.formname.btnname.disabled" I get nothing at all
[probably causes a Javascript error], no "alert".

What should I do ?

This rather sounds more like a javascript discussion to me than an xslt discussion, but since it appears to be related in this case, let me give it a try.

From your first post, I may have missed some details, or you may not have mentioned it. You talk about several xslt files making up your html form. You call it a "web XSLT application", which I translated as an application doing client side xslt transformation. Reading your post again, I think you do the XSLT transformation on the server and sending the results as HTML back to the client (how you can do that without CSS, even inline CSS, like the style attribute, is beyond me), right? Well, in that case only the result counts (result of HTML).

You wrote:
<body onload="if (document.myBtn.disabled) document.myBtn.disabled=false;" />

This will always make your button disabled, at least when there's an element with ID/Name "myBtn". If there isn't, it should raise an error. If it does not raise an error, you either have your browser off on errors, or you have a global error handler somewhere in your scripts (or in Cocoon).

You wrote:
<input name=myBtn onclick="this.disable=true;" />

This will do nothing, as the "disable" property of the 'this' object. Use 'disabled' instead.

To me it sounds that you are mixing client side and server side. Client side is, once it is generated, completely oblivious of what happens on the serverside. It really doesn't matter a sip if your code is in the parent xslt or in the xsl:include'd xslt. It only matter if the objects you talk about are there or not and if you use the correct syntax. I suggest you use document.getElementById('btnId') to get the button you want, instead of the IE-only syntax in your example. Of course, the ID-attribute must be unique.

Another solution often used where a form is submitted and sends the same page again as a result, is the following. The value can be set by taking the name of the button used to perform the submit (it is send in the http request with all the other fields), if there is no button name, there is no form request.
<input type="hidden" name="result-from" value="btnX" />

Then, you can use the following on the button itself:
<input name=myBtn onclick="this.disabled=true;" />

One thing ponders me in the whole story. If you managed previously to set the button to disabled using javascript on the onclick handler, it must have been re-enabled after the refresh. And if you do not have a refresh, how do you do that without using Ajax or related advanced technology?

If I'm off-topic or misinterpreted your question, please provide enough details and give a clear example what does work and what does not, possibly including the offending xslt (though I doubt if that's the issue here).

Cheers,

Abel Braaksma
http://www.nuntia.com

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>