xsl-list
[Top] [All Lists]

Re: [xsl] Preventing second click

2006-09-28 14:21:32
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 ?



On 9/28/06, Abel Braaksma <abel(_dot_)online(_at_)xs4all(_dot_)nl> wrote:
Oleg Konovalov wrote:
>
> The complication is that the <body> and <input> are in different XSL
> files,
> i.e. if the button is in the "grandchild" of the <body> form (child
> xsl:include's the parent which includes a grandparent containg the
> <body>).
> Do they really share a "document" ?
> Doesn't seem to work for me.
>
> Or is there a nicer solution ?
>


Sounds to me you are trying the following: Data (xml) + XSLT for several
sections of your page. Sounds like AJAX + xslt and sounds like you
should best use Prototype JS library (http://prototype.conio.net/ for
1.4, newer version is delivered with the http://script.aculo.us library
or from svn).

I develop a web application for managing tables and text blocks for
which every visual part is done with multiple xml+xslt client side
transformations. To add logic to this, where the javascript comes from
XSLT, it will not always be well interpreted, especially not on IE.
Using a result-dom and adding it to the html dom one way or the other,
may (or will) result in problems. Only exception: when you use the
onxxxx handlers like you did (but these are deprecated)

The best and easiest bets you have is: right after the xslt-transform
(when the button is created) use an addEventHandler function to add the
javascript function to the onclick handler of this button. This is by
far the easiest way and imho the best, if not merely because you do not
mix javascript inside xslt, which should be about layout. Leave the js
in the js files, where they belong.

The second bet is: use Prototype (or write it yourself) to automatically
interprete any script that is inside the result-dom and interpret it.

It should not matter whether you use separate xslt files or not, as long
as you keep in mind that not all objects are ready at any given time.
Meaning: if you call a script (when the user clicks or automatically)
that needs objects from another xslt transform, you must be sure that
the other xslt transformation (does it get its data async or not?) is
finished and has its objects rendered.

Doing it in "pure" xslt without javascript but with css styles can only
be achieved with a trick. Use a link and make it look like a button. Use
pseudo class :visited and set it to hidden in css, make sure the link is
different each time (just add a timestamp or something). This will make
it invisible when clicked, but once SQL has finished, you make it
visible again using javascript (cannot be done with only css of course).

Good luck,

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>
--~--



--~------------------------------------------------------------------
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>