Apparent subforms breakage in r595?

[C. M. Sperberg-McQueen]

Is anyone else having trouble with subforms in r595?

When I test my forms with r595 (and add a third argument
to transform()), some of my forms appear to work fine.
However, subforms are not appearing.

I've just downloaded the writers.xml and books.xml example
from http://www.agencexml.com/xsltforms/writers and find
that it works fine with my local copy of release 1.0RC but
not with r595.

Symptoms: at first load, everything is displayed as usual,
as seen in this screen shot:

[C. M. Sperberg-McQueen]

...
When I click on the Show Books button for Camus, however,
instead of the list of his books I see what looks like the end of
an XML comment ("xsltforms-subform-1 -->"), ...

Inserting alert() calls into xsltforms.js, it appears that line 9895
of xsltforms.js is assigning the following string to the innerHTML
property of the target xf:group element:

<!-- xsltforms-subform-0 --></body></html> xsltforms-subform-0 -->

My guess, after more tracing, is that xsltforms.xsl has been modified
to insert one more XsltForms_MagicSeparator string, and so the
references to the array of parts of the loaded subform are (some
of them) off by one.

If I change the reference to sp[4] in line 9888 to refer instead to
sp[3], I get a more plausible-looking value assigned to innerHTML
(reformatted for legibility):

<!-- xsltforms-subform-0 -->
<div xmlns=""
id="xsltforms-subform-0-repeat-0"
class="xforms-disabled xforms-repeat">
<div class="xforms-repeat-item">
<span xmlns="http://www.w3.org/1999/xhtml"
id="xsltforms-subform-0-output-0"
class="xforms-disabled xforms-control xforms-output xforms-appearance-minimal">
<span class="value">
<span class="xforms-value">&nbsp;</span>
</span>
<span class="xforms-alert">
<span class="xforms-alert-icon">&nbsp;</span>
</span>
</span>
-
<span xmlns="http://www.w3.org/1999/xhtml"
id="xsltforms-subform-0-output-1"
class="xforms-disabled xforms-control xforms-output xforms-appearance-minimal">
<span class="value">
<span class="xforms-value">&nbsp;</span>
</span>
<span class="xforms-alert">
<span class="xforms-alert-icon">&nbsp;</span>
</span>
</span>
</div>
</div>
<div id="xsltforms_console">&nbsp;</div>
<div id="statusPanel">... Loading ...&nbsp;</div>
<!-- xsltforms-subform-0 -->

But I regret to see that the subform itself still does not become
visible, which means that there is more to it than sp[4] becoming
sp[3].

Similar code seems to occur in the handling of components, by
the way, which means they also may need attention.

[Alain Couthures]

Sorry, I cannot reproduce this issue with latest versions of Firefox, IE
and Chrome for Windows, the XSLT stylesheet being applied at client-side...

Did you try with different browsers, different computers? Did you clear
caches? Might the server be acting differently about encoding? Where is
the XSLT stylesheet applied?

Thank you for your feedback!

-Alain

Post by C. M. Sperberg-McQueen

...
When I click on the Show Books button for Camus, however,
instead of the list of his books I see what looks like the end of
an XML comment ("xsltforms-subform-1 -->"), ...

Inserting alert() calls into xsltforms.js, it appears that line 9895
of xsltforms.js is assigning the following string to the innerHTML
<!-- xsltforms-subform-0 --></body></html> xsltforms-subform-0 -->
My guess, after more tracing, is that xsltforms.xsl has been modified
to insert one more XsltForms_MagicSeparator string, and so the
references to the array of parts of the loaded subform are (some
of them) off by one.
If I change the reference to sp[4] in line 9888 to refer instead to
sp[3], I get a more plausible-looking value assigned to innerHTML
<!-- xsltforms-subform-0 -->
<div xmlns=""
id="xsltforms-subform-0-repeat-0"
class="xforms-disabled xforms-repeat">
<div class="xforms-repeat-item">
<span xmlns="http://www.w3.org/1999/xhtml"
id="xsltforms-subform-0-output-0"
class="xforms-disabled xforms-control xforms-output xforms-appearance-minimal">
<span class="value">
<span class="xforms-value">&nbsp;</span>
</span>
<span class="xforms-alert">
<span class="xforms-alert-icon">&nbsp;</span>
</span>
</span>
-
<span xmlns="http://www.w3.org/1999/xhtml"
id="xsltforms-subform-0-output-1"
class="xforms-disabled xforms-control xforms-output xforms-appearance-minimal">
<span class="value">
<span class="xforms-value">&nbsp;</span>
</span>
<span class="xforms-alert">
<span class="xforms-alert-icon">&nbsp;</span>
</span>
</span>
</div>
</div>
<div id="xsltforms_console">&nbsp;</div>
<div id="statusPanel">... Loading ...&nbsp;</div>
<!-- xsltforms-subform-0 -->
But I regret to see that the subform itself still does not become
visible, which means that there is more to it than sp[4] becoming
sp[3].
Similar code seems to occur in the handling of components, by
the way, which means they also may need attention.

[C. M. Sperberg-McQueen]

Post by Alain Couthures
Sorry, I cannot reproduce this issue with latest versions of Firefox, IE
and Chrome for Windows, the XSLT stylesheet being applied at client-side...
Did you try with different browsers, different computers? Did you clear
caches? Might the server be acting differently about encoding? Where is
the XSLT stylesheet applied?

I have observed this behavior on my local copy of
r595 (checked out from sourceforge and copied from
the build directory to my localhost document area)
in Safari 5.1.0, Firefox 28.0, Chrome 34.0.1847.131,
and Opera 12.16, all running under Mac OS X 10.6.8.

In all cases, the transformation is being applied in the
client.

When I point the writers and books files to xsltforms-1.0RC
instead of -595, I get the normal behavior (although I
confess I haven't done this with every one of those
browsers).

I had no trouble replicating both the good and the bad
behavior in Safari, going back and forth, but just to be
sure, I've selected Disable caches there, and replicated
the problem.

Interestingly, when I point the browsers to the copy of the
form at http://www.agencexml.com/xsltforms/writers.xml
they all have no trouble with it. It appears to be running
595, so it's no wonder you cannot replicate the problem.

The xsltforms.xsl, xsltforms.js, and xsltforms.css retrieved
by curl from agencexml.com/xsltforms/xsltforms/ are all
the same as my local copies (with the exception of
the alert() calls I've inserted into my local copy, and with
the exception of a correction in the error message for
number of arguments for the transform() function).

I will try to replicate the problem on a public server and
will send an address if I succeed in doing so.

[C. M. Sperberg-McQueen]

Post by C. M. Sperberg-McQueen

Post by Alain Couthures
Sorry, I cannot reproduce this issue with latest versions of Firefox, IE
and Chrome for Windows, the XSLT stylesheet being applied at client-side...
Did you try with different browsers, different computers? Did you clear
caches? Might the server be acting differently about encoding? Where is
the XSLT stylesheet applied?

I have observed this behavior on my local copy of
r595 (checked out from sourceforge and copied from
the build directory to my localhost document area)
in Safari 5.1.0, Firefox 28.0, Chrome 34.0.1847.131,
and Opera 12.16, all running under Mac OS X 10.6.8.
...
I will try to replicate the problem on a public server and
will send an address if I succeed in doing so.

Thank you, Alain.

It was apparently a cache problem -- partly local browser
cache and possibly partly a local caching proxy.

I am baffled trying to understand how the cache could
cause this problem, given that the 1.0RC and 595 releases
of XForms are in different directories and should therefore
have different URIs. But after rebooting, deleting the caches
in all my browsers, and circumventing my local caching
proxy, I am unable to replicate the issue.

Sorry for the false alarm.