xsltforms-support — XSLTForms support list

[Xsltforms-support] internationalisation (2)

[Stephen C. <ste...@gm...>]

using @xml:id doesn't seem to improve the speed

Frorm the profiler.

XPath Expressions Cumulative Evaluation Time:

   - "label-set[@xml:id='add']/label[@lang=../../@lang]": 673ms
   - "label-set[@xml:id='back']/label[@lang=../../@lang]": 499ms
   - "label-set[@xml:id='instr-number-max']/label[@lang=../../@lang]": 208ms
   - "label-set[@xml:id=current()/@id]/label[@lang=../../@lang]": 192ms
   - "label-set[@xml:id='pattern']/label[@lang=../../@lang]": 180ms
   - "label-set[@xml:id='true-false']/label[@lang=../../@lang]": 174ms
   - "label-set[@xml:id='add-pattern-restr']/label[@lang=../../@lang]": 170
   ms
   - "label-set[@xml:id='instr-add-enum']/label[@lang=../../@lang]": 170ms
   - "label-set[@xml:id='insert-cloned']/label[@lang=../../@lang]": 169ms
   - "label-set[@xml:id='number-min-incl']/label[@lang=../../@lang]": 169ms
   - "label-set[@xml:id='add-enumeration']/label[@lang=../../@lang]": 168ms
   - "label-set[@xml:id='number-min-excl']/label[@lang=../../@lang]": 167ms
   - "label-set[@xml:id='number-max-incl']/label[@lang=../../@lang]": 165ms
   - "label-set[@xml:id='number-max-excl']/label[@lang=../../@lang]": 164ms
   -
   "if(@type='xs:string',instance('labels')/label-set[@xml:id='its-length-or-valid']/label[@lang=../../@lang],instance('labels')/label-set[@xml:id='valid-range-of']/label[@lang=../../@lang])":
   156ms
   - "label-set[@xml:id='length']/label[@lang=../../@lang]": 106ms
   - "label-set[@xml:id='maximum-length']/label[@lang=../../@lang]": 101ms
   - "label-set[@xml:id='minimum-length']/label[@lang=../../@lang]": 100ms
   - "label-set[@xml:id='delete']/label[@lang=../../@lang]": 88ms
   - "label-set[@xml:id='instr-number-min']/label[@lang=../../@lang]": 88ms
   - Others: 5102ms
   - Total: 9009ms

[Xsltforms-support] XForms form internationalisation, an optimal means?

[Stephen C. <ste...@gm...>]

Hi

I have an XForm that is internationalised (ized), and it seems now via use
of the profiler that alot of the slowness in my form might be attributable
to that fact. So I am interested to find a better way if possible to
achieve the same goal as what I currently have.

I see that @ref is now supported on <xf:label> elements, so that is
something to try:
http://www.agencexml.com/xforms-tests/testsuite/XForms1.1/Edition1/Chapt08/8.2/8.2.1/8.2.1.a.xhtml

What I have a present is a second model for my label strings and this has a
single instance with data of the following structure:

<?xml version="1.0" encoding="UTF-8"?>
<labels lang="en">
   <languages>
      <language lang="en">English</language>
      <language lang="es">Español</language>
      <language lang="fr">Français</language>
   </languages>
   <label-set id="header-title">
      <label lang="en">Forms-Wizard Designer (alpha)</label>
      <label lang="es">Forms-Wizard Designer (alpha)</label>
      <label lang="fr">Forms-Wizard Designer (alpha)</label>
   </label-set>

The label-set strings are used in the following way in the form:

<xf:input ref="@name">
   <xf:label>
     <xf:output model="model2"
ref="label-set[@id='name']/label[@lang=../../@lang]" />
   </xf:label>

Apparently these label <xf:output> references get re-evaluated each time
there is a recalculation of the form. I did imagine (naively) that this
would not happen if they where placed into a second model, but that doesn't
seem to be what is happening in practice.

Also, I should be able to make that @xml:id to get a quicker scan of the
labels model I suppose, but does XSLTForms support @id attributes as unique
identifiers in data models?

Thanks for your insights.

Steve Cameron

Re: [Xsltforms-support] Forms loaded from local filesystem

[Alain C. <ala...@ag...>]

Hi Mats,

XSLTForms is currently considering that submissions from a local form 
are always for the local disk but, in your case, the corresponding 
resource should be starting with "http://", is that right?

Could you please test replacing:

at 7813,
    window.location.href.substr(0, 7) === "file://"
with
    (window.location.href.substr(0, 7) === "file://" && action.substr(0, 
7) !== "http://")

at 7942,
    (window.location.href.substr(0, 7) === "file://" && method !== "get")
with
    (window.location.href.substr(0, 7) === "file://" && action.substr(0, 
7) !== "http://" && method !== "get")

Thank you for your feedback!

--Alain

Le 01/06/2014 22:20, Mats Eklund a écrit :
> Hi,
>
> I have noticed that XSLTForms does not seem to support the scenario of 
> xforms submission to a web server when the form or instance document 
> is loaded from local file system (file://).
>
> I believe this is so since normally such submissions are disallowed in 
> accordance with the browser's implementation of the Same-Origin Policy.
>
> However, since there are methods for disabling the Same-Origin Policy 
> (e.g. using Cross-Origin Resource Sharing (CORS) on the destination 
> server or by disabling Same-Origin Policy in the browser (can be done 
> in Chrome for example)), it would be nice if XSLTForms could support 
> the mentioned scenario.
>
> For my own purposes, I got the scenario to work by making changes to 
> xsltforms.js (Rev 595):
>
> 7942: modified test in IF statement to never return true (allows for 
> normal processing of xf:submission even if form loaded from file system)
> 7813: modified test in IF statement to never return true (prevents an 
> unnecessary java applet from being loaded)
>
> These are however only quick and dirty fixes. It would be nice if 
> XSLTForms could support this scenario!
>
> Kind regards,
> Mats
>

Re: [Xsltforms-support] Dialog vertical position problems on the last revisions

[Alain C. <ala...@ag...>]

Hi Ioan,

I have now changed to the old version in the latest build. It will stay 
as this as long as I haven't yet found a good way to support dialogs 
popup from an IFRAME...

Thanks!

--Alain

Le 07/05/2014 14:50, Ioan Fericel a écrit :
> Hi Alain,
>
> I find a solution for this problem, but not sure that is generally
> valid. In xsltforms.js, at line 232 in latest revision (595):
>> myHeight = document.body ? document.body.clientHeight :
>> document.documentElement.clientHeight;
> I changed to the old version:
>> myHeight = document.documentElement.clientHeight;
> Now modal dialog is centered correctly in visible area, both in Firefox
> and Chrome. Is it possible to affect other parts or could be changed in
> the next version to work correctly also in this case?
>
> Merci et bonne journée,
> Ioan
>

Re: [Xsltforms-support] media type relating to results from a 'replace=all' submission

[Alain C. <ala...@ag...>]

Hello,

Submission with replace=all is a problem for XSLTForms because 
XmlHttpRequest() has to be used. All the current page is to be replaced 
by the response: you can have a look at 
XsltForms_submission.prototype.submit() method, you will see 'if 
(subm.replace === "all") {' and how it is performed in Javascript.

I have not been able to find a way to force the browser to consider a 
Javascript string as if it received it as a new page. But, it is 
possible for you to write your own XML tree renderer (with HTML tags and 
styles) in Javascript!

If you want the browser to render an XML tree by itself, you might use a 
specific method named "xml-urlencoded-post" which I added as an 
extension to XSLTForms: instead of using XmlHttpRequest() to post the 
XML data, an HTML form is added with a unique field named "postdata" in 
which the submitted XML is serialized. With this method, the server has 
to extract the XML data from the postdata field but the browser will 
effectively have a new location and render the returned data according 
to the content-type.

What do you think?

--Alain

Le 04/06/2014 12:03, Chris H. a écrit :
> Hello xsltforms-support, good morning
>
>
>  Question:
> Initially before I go into this matter deeper, please can Alain, or 
> any one else, briefly explain what happens in xsltforms for a 
> submission where the attribute replace="all" is present?
>
> I am particularly interested in how content-type/media-type is handled 
> and where in the .js this happens.
>
>  Background:
> As background to this, I have an xform returned from a GET to a xquery 
> in eXist-db. This is displayed correctly, however the content type 
> showing in latest FF using the tools/pageinfo menu option, is 
> text/html, where as 'LiveHeaders' addon shows application/xhtml+xml 
> was, as coded, sent for the traced Response part.
>
> When I submit from this form using a 'POST' method with 'replace' set  
> as 'all', the xquery called, returns correctly formed xml  as 
> application/xml.    Unfortunately, it is only seen as text/html and 
> doesnt display as an XML tree as would be expected. It just displays 
> as text.
>
> If I just call the xquery directly (without using xsltforms), then all 
> works correctly and the xml returned is shown as application/xml and 
> displays as an xml tree.
>
> This is why Im interested in clarification on content-type handling 
> and what happens during a submission, particularly with a 
> replace="all" attribute.
>
> Thank you for your insight.
> Habs
>

Re: [Xsltforms-support] r 595 xsltforms.xsl is not validating

[Alain C. <ala...@ag...>]

Leonid,

Sorry, I did not try the XSLT validator in XML Spy and the error below 
does not help...

Please be sure to have cleared caches.

Can you run examples successfully?

--Alain

Le 04/06/2014 20:23, Leonid Kagan a écrit :
> Alain,
> First of all thank you for continued support of this project.
>
> As many other people here we downloaded the latest release to fix 
> Chrome 34 and IE 11 issues with previous release. As we started to 
> test our forms, there where some issues. I wanted to debug them in 
> XMLSpy, but found that it fails to validate xsltforms.xsl. The error 
> happens on JScript compilation (line 47). Below is an error I get. I'm 
> curious if there is a quick fix for it.
> Thanks again,
>
> --Leonid
> ==================== Error below =======================
> File C:\DevTools\xsltforms-beta3RC\xsltforms\xsltforms.xsl is not valid.
> Script Compile Error(s) (relative to script begin):
> Line 1, Character 4: Syntax error
> Line 1, Character 33: Expected identifier
> "
>             this['node-set'] =  function (x) {
>             return x;
>             }
>         "
>

[Xsltforms-support] r 595 xsltforms.xsl is not validating

[Leonid K. <lk...@li...>]

Alain, 
First of all thank you for continued support of this project. 

As many other people here we downloaded the latest release to fix Chrome 34 and IE 11 issues with previous release. As we started to test our forms, there where some issues. I wanted to debug them in XMLSpy, but found that it fails to validate xsltforms.xsl. The error happens on JScript compilation (line 47). Below is an error I get. I'm curious if there is a quick fix for it. 
Thanks again, 

--Leonid 
==================== Error below ======================= 
File C:\DevTools\xsltforms-beta3RC\xsltforms\xsltforms.xsl is not valid. 
Script Compile Error(s) (relative to script begin): 
Line 1, Character 4: Syntax error 
Line 1, Character 33: Expected identifier 
" 
this['node-set'] = function (x) { 
return x; 
} 
" 

[Xsltforms-support] media type relating to results from a 'replace=all' submission

[Chris H. <bc...@sh...>]

Hello xsltforms-support, good morning


 Question:
Initially before I go into this matter deeper, please can Alain, or any one
else, briefly explain what happens in xsltforms for a submission where the
attribute replace="all" is present?

I am particularly interested in how content-type/media-type is handled and
where in the .js this happens.

 Background:
As background to this, I have an xform returned from a GET to a xquery in
eXist-db. This is displayed correctly, however the content type showing in
latest FF using the tools/pageinfo menu option, is text/html, where as
'LiveHeaders' addon shows application/xhtml+xml was, as coded, sent for the
traced Response part.

When I submit from this form using a 'POST' method with 'replace' set  as
'all', the xquery called, returns correctly formed xml  as
application/xml.    Unfortunately, it is only seen as text/html and doesnt
display as an XML tree as would be expected. It just displays as text.

If I just call the xquery directly (without using xsltforms), then all
works correctly and the xml returned is shown as application/xml and
displays as an xml tree.

This is why Im interested in clarification on content-type handling and
what happens during a submission, particularly with a replace="all"
attribute.

Thank you for your insight.
Habs

[Xsltforms-support] Forms loaded from local filesystem

[Mats E. <mat...@ya...>]

Hi,

I have noticed that XSLTForms does not seem to support the scenario of xforms submission to a web server when the form or instance document is loaded from local file system (file://). 

I believe this is so since normally such submissions are disallowed in accordance with the browser's implementation of the Same-Origin Policy. 

However, since there are methods for disabling the Same-Origin Policy (e.g. using Cross-Origin Resource Sharing (CORS) on the destination server or by disabling Same-Origin Policy in the browser (can be done in Chrome for example)), it would be nice if XSLTForms could support the mentioned scenario.

For my own purposes, I got the scenario to work by making changes to xsltforms.js (Rev 595):

7942: modified test in IF statement to never return true (allows for normal processing of xf:submission even if form loaded from file system)
7813: modified test in IF statement to never return true (prevents an unnecessary java applet from being loaded)

These are however only quick and dirty fixes. It would be nice if XSLTForms could support this scenario!

Kind regards,
Mats

Re: [Xsltforms-support] Booting XsltForms from an instance data document

[Mats E. <mat...@ya...>]

Hi Alain,

Ok, I investigated the issue and found that things work after the following changes in xsltforms.xsl:

* On line 63, change <xsl:apply-templates select="$piformdoc/*" mode="script"/> to <xsl:apply-templates select="$piformdoc" mode="script"/> (This fixes the id mismatches)
* On lines 51, 52 and 56 (x2), change "$piform" to "concat(' ', $piform)" (This fixes a problem that xsltforms does not recognize all parameters set on the xml-forms processing instruction)

Hope these fixes can be incorporated into the official source.

Kind regards,
Mats


________________________________
 From: Alain Couthures <ala...@ag...>
To: Mats Eklund <mat...@ya...>; "xsl...@li..." <xsl...@li...> 
Sent: Sunday, May 4, 2014 3:54 PM
Subject: Re: [Xsltforms-support] Booting XsltForms from an instance data document
 


Hi Mats,

At line 9455, an exception occurs when an id for an XForms element
      is not found. This consistency issue might be due to an invalid id
      generation during the XSLT transformation.

-Alain


Le 04/05/2014 15:21, Mats Eklund a écrit :

Hi Alain,
>
>I have managed to implement the javascript approach, and it
        works, so I have a fallback solution.
>
>Meanwhile I was able to resolve the (first) problem with the
        ?xml-form approach: I realized that the ?xml-form/@href of the
        form had to be relative to the XSLTForms XSL document rather
        than the source XML document. Now I however get a javascript
        exception at line 9455 in xsltforms.js. Consistent behavior in
        all browsers. If I open the referenced form directly (with same
        instance data), it loads without problem.
>
>Any idea what this could be, or how to best troubleshoot?
>
>Kind regards,
>Mats
>
>

Re: [Xsltforms-support] Language support

[Alain C. <ala...@ag...>]

Hi Weston,

Language support is, by default, based on browser localized version, 
which is different from language settings (because language settings 
cannot be accessed with Javascript instructions).

That's why, with a French version of browsers, I get French labels with 
the address demo.

It is possible to force the language within the config.xsl file and the 
lang option can also be used, as you mentioned.

I will change priority between config file and lang option in the next 
commit so lang option will have higher priority.

Are you in a hurry?

Thanks!

-Alain

Le 18/05/2014 16:20, Weston Renoud a écrit :
> Hi all,
>
> I'm trying to get language support, as in the address demo 
> (http://www.agencexml.com/xsltforms/address.xml) to work, but I can't 
> get anything other than english to show.
>
> I have revision 597, and I'm in Chrome 34.
>
> On the copy on my server I've tried adding the 'lang' attribute to the 
> xsltforms-options:
>
> <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
> <?xsltforms-options debug="yes" lang="fr"?>
>
> But it doesn't seem to have any effect.
>
> What am I missing?
>
> Thanks,
> Weston Renoud
>

[Xsltforms-support] Language support

[Weston R. <wes...@le...>]

Hi all,

I'm trying to get language support, as in the address demo (
http://www.agencexml.com/xsltforms/address.xml) to work, but I can't get
anything other than english to show.

I have revision 597, and I'm in Chrome 34.

On the copy on my server I've tried adding the 'lang' attribute to the
xsltforms-options:

<?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
<?xsltforms-options debug="yes" lang="fr"?>

But it doesn't seem to have any effect.

What am I missing?

Thanks,
Weston Renoud

[Xsltforms-support] Upload filename supported?

[Mats E. <mat...@ya...>]

Hi,

I am experimenting with the xf:upload/xf:filename element, but not getting it to work. 

I'm using latest source. At line 11826 a call is made to a function at line 2947 that just calls alert("Error").

Thanks for any advise!

Kind regards,
Mats

Re: [Xsltforms-support] xforms-model-destruct event

[William V. <wve...@vi...>]

Looking inside xsltforms.js, this event is fired under two circumstances:
1. When a xf:submission replaces the content of the model
2. When the event body.onunload is fired by the browser

The event onunload has an history of not being not widely supported by all browsers. 

Maybe you are using an old Chrome or Chrome browser.

HTH,

- Bill

-----Mensaje original-----
De: Sabine Teubner [mailto:st...@ba...] 
Enviado el: miércoles, 14 de mayo de 2014 3:48 a. m.
Para: xsl...@li...
Asunto: [Xsltforms-support] xforms-model-destruct event

Dear all

In one of my models I am trying to respond to the xforms-model-destruct event. For starters I just tried to display a message when the event is dispatched:

 <xforms:model .>

  ...

   <xforms:message level="modal" ev:event="xforms-model-destruct">
      xforms-model-destruct dispatched
    </xforms:message>

  </xforms:model>

However, the message is never displayed. Am I wrong in assuming that the event is dispatched "automatically", just as for example xforms-ready? If it is not, is there a way that I can dispatch the event when the user tries to close/leave the web page for which the model was constructed?

Thanks and best wishes
Sabine

--
Sabine Teubner, BaseX GmbH, http://basex.org
|-- Firmensitz: Blarerstrasse 56, 78462 Konstanz
|-- Registergericht Freiburg, HRB: 708285, Geschäftsführer:
|   Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle
`-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Xsltforms-support mailing list
Xsl...@li...
https://lists.sourceforge.net/lists/listinfo/xsltforms-support

[Xsltforms-support] xforms-model-destruct event

[Sabine T. <st...@ba...>]

Dear all

In one of my models I am trying to respond to the xforms-model-destruct event. For starters I just tried to display a message when the event is dispatched:

 <xforms:model …>

  ...

   <xforms:message level="modal" ev:event="xforms-model-destruct">
      xforms-model-destruct dispatched
    </xforms:message>

  </xforms:model>

However, the message is never displayed. Am I wrong in assuming that the event is dispatched „automatically“, just as for example xforms-ready? If it is not, is there a way that I can dispatch the event when the user tries to close/leave the web page for which the model was constructed?

Thanks and best wishes
Sabine

--
Sabine Teubner, BaseX GmbH, http://basex.org
|-- Firmensitz: Blarerstrasse 56, 78462 Konstanz
|-- Registergericht Freiburg, HRB: 708285, Geschäftsführer:
|   Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle
`-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22

Re: [Xsltforms-support] blur() alert in r595

[Alain C. <ala...@ag...>]

Sorry for the inconvenience.

This is the first time I heard about this debugging instruction being 
activated.

I will remove this alert() call.

Thank you for your feedback!

-Alain

Le 12/05/2014 17:52, C. M. Sperberg-McQueen a écrit :
> Just a note for eventual action by Alain and for users of r595 who may
> be as startled by it as I was:  there is some (debugging?) code in r595
> which raises a Javascript alert when it sees certain events, so the user
> is confronted with a dialog box giving the host's name and reading "Blur?".
>
> My initial instinct when this happened to me this morning was to assume
> that my machine had been hacked (too much time in too many
> Internet cafes?  aggressive neighbors?); no panic, however, is necessary.
>
> Concretely, this happens in XsltForms.globals.blur() when the try
> wrapped around this.focus.blur() fails (ie it's in the catch).  So far,
> I've experienced it only in Safari, when clicking to move from one
> textarea to the next.
>

[Xsltforms-support] blur() alert in r595

[C. M. Sperberg-M. <cm...@bl...>]

Just a note for eventual action by Alain and for users of r595 who may
be as startled by it as I was:  there is some (debugging?) code in r595 
which raises a Javascript alert when it sees certain events, so the user
is confronted with a dialog box giving the host's name and reading "Blur?".  

My initial instinct when this happened to me this morning was to assume
that my machine had been hacked (too much time in too many
Internet cafes?  aggressive neighbors?); no panic, however, is necessary.

Concretely, this happens in XsltForms.globals.blur() when the try 
wrapped around this.focus.blur() fails (ie it's in the catch).  So far,
I've experienced it only in Safari, when clicking to move from one
textarea to the next.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] Apparent subforms breakage in r595?

[C. M. Sperberg-M. <cm...@bl...>]

On May 8, 2014, at 4:02 PM, C. M. Sperberg-McQueen wrote:

> 
> On May 8, 2014, at 1:35 PM, Alain Couthures wrote:
> 
>> 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.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] Apparent subforms breakage in r595?

[C. M. Sperberg-M. <cm...@bl...>]

On May 8, 2014, at 1:35 PM, Alain Couthures wrote:

> 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, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] Apparent subforms breakage in r595?

[Alain C. <ala...@ag...>]

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

Le 08/05/2014 20:24, C. M. Sperberg-McQueen a écrit :
> On May 8, 2014, at 8:31 AM, C. M. Sperberg-McQueen wrote:
>> ...
>>
>> 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.

Re: [Xsltforms-support] Apparent subforms breakage in r595?

[C. M. Sperberg-M. <cm...@bl...>]

On May 8, 2014, at 8:31 AM, C. M. Sperberg-McQueen wrote:
> ...
> 
> 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.
-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

[Xsltforms-support] Apparent subforms breakage in r595?

[C. M. Sperberg-M. <cm...@bl...>]

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:

Re: [Xsltforms-support] Dialog vertical position problems on the last revisions

[Ioan F. <mi...@gm...>]

Hi Alain,

I find a solution for this problem, but not sure that is generally 
valid. In xsltforms.js, at line 232 in latest revision (595):
> myHeight = document.body ? document.body.clientHeight : 
> document.documentElement.clientHeight;
I changed to the old version:
> myHeight = document.documentElement.clientHeight;

Now modal dialog is centered correctly in visible area, both in Firefox 
and Chrome. Is it possible to affect other parts or could be changed in 
the next version to work correctly also in this case?

Merci et bonne journée,
Ioan


On 05/02/2014 11:06 AM, Ioan Fericel wrote:
> Hello!
>
> The problem appear on the pages with many positions, with scroll, on 
> tabular repeat. Openning an dialog box for editing or adding line, 
> this appear somewhere below the page, centered on entire page, not on 
> the visible area.
>
> I noticed the trouble on versions 593 and subsequent. The last one I 
> used it work properly was 586 and I could not understand what has 
> changed.
>
> I tried various ways of positioning in CSS, but I did not succeed to 
> get normal functionality. Please could you give me an idea for solving.
>
> Thanks,
> Ioan

[Xsltforms-support] transform() function in 595

[C. M. Sperberg-M. <cm...@bl...>]

A project I'm involved with is running into problems with Chrome 34; I was glad
to see that there is already a workaround for them, so I have checked out
version 595 and am testing it.  I have run into a problem.

The form I am testing uses the transform() function to display nicely formatted
read-only versions of some complex information.  Under 1.0RC it works as
intended (except in Chrome 34 -- but that's where this story started, isn't it?). 
Under 595, when the user loads a document, I get a long series (one per
item in a repeat) of error alerts reading:

  http://localhost
  XSLTForms Exception
  ----------------
  Error evaluating the following XPath expression:
  transform(., 'display-segments-aligned.xsl')
  transform() : Invalid number of arguments
  transform() function must have two arguments exactly

The cause appears to be that the error message transformInvalidArgumentsNumber
has not changed, but at some point the argument-checking in the transform
function changed from 

  if (arguments.length !== 2) {
     throw XsltForms_xpathFunctionExceptions.transformInvalidArgumentsNumber;
  }

to

  if (arguments.length < 3) {
     throw XsltForms_xpathFunctionExceptions.transformInvalidArgumentsNumber;
  }

It's easy enough to add a third argument to my calls to transform() -- if I have
understood correctly, it should be 'false' -- or to supply false as the default.

Question 1:  am I right that the third argument should be 'false'
for external stylesheets, and 'true' for strings containing an XSLT stylesheet?

Question 2:  What are arguments 4 and following for?  They appear to be
for stylesheet parameters (which would really make me happy); is that true?

Question 3:  Is this documented somewhere?  (One of the reasons I like
XForms is that I don't want to have to learn to read Javascript really fluently.)

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

[Xsltforms-support] Possible regression on <upload/> since r576

[Benoit V. <bvi...@la...>]

Hi Alain,

It's me again. Now I have trouble with <xf:upload/> control in r595 on 
FFox and Chrome.

A)
When I use it I get an "Error" alert.
I found that this message come from the 
"XsltForms_binding.prototype.bind_evaluate()" function introduced since 
the r576 to replace "XsltForms_binding.prototype.evaluate()".
I'm afraid you forgot to change "evaluate()" to "bind_evaluate()" in 
<xf:upload/> control in "XsltForms_upload.prototype.directclick()" and 
"XsltForms_upload.prototype.change()".

B)
After I made this change in my code, my forms works again but I steal 
have a small problem on the <xf:filename/> element :

        <xf:upload ref="content">
             <xf:filename ref="@name"/>
        </xf:upload>

The xf:filename/@ref seems not relative to the xf:upload/@ref like 
before the r576. For now I use absolute xpath :

        <xf:upload ref="content">
             <xf:filename ref="instance("ins_doc")/content/@name"/>
        </xf:upload>

and it works. Have you any idea on these problems?

Thank's for your help.

         Benoit