xsltforms-support

[Xsltforms-support] XSLTForms browsers compatibility + Some issues using XSLTForms in server side.

[Javier D. <jd...@ge...>]

Hello,

Firstly I will present myself. I am Javier, I am working in a Spanish
company doing a project for Telefónica.

Recently we have started to develop a new internal web page to manage
some Telefónica internet services. This page has a special feature: we
have to generate as result a xml with data filled from a form by an
operator to do the required operation. After examining some possible
solutions, we realised that using XForms was the best option to generate
the xml from the form because is easy to get it.

Then, to implement the XForms solution, we discovered XSLTForms, and we
decided that for us it was the most suitable solution to get XForms
work, mainly because we have on our server a xslt layer to adapt our web
pages output.

After using the examples with several browsers, we concluded that
XSLTForms seems to work OK with at least Firefox 3, Internet Explorer 7,
Opera and Konqueror. But we have experienced some problems with Firefox
2. So, in first place, we would like to know if there is any list of
browsers that are known to work ok (or no ok) with XSLTForms, to know if
we will experience problems with users that have old browsers when are
using our new web application.

Later, we tried to use the xsl of xsltforms in our server side xslt
layer and we experienced some problems that we managed to solve. These
problems were mainly that our system (based on Java) wasn't able to load
the xsl as it was when we downloaded it from sourceforge, due to using
the server side xsl we didn't have defined any processing instruction.
Commenting out in xslt all lines with commands like
"translate(normalize-space(/processing-instruction('css-conversion')[1]),
'YESNO ', 'yesno')='no'" or
"translate(normalize-space(/processing-instruction('xml-stylesheet')[1])",
we managed to load the xsl and it seems to work ok in our system. We
send you attached to this mail a patch with all changes we have done in
your xsl to make it work.

We would appreciate, if it is possible, to do in your code the necessary
changes to make it work in server side, or let us know if we are using
it incorrectly (for example, maybe we are missing to initialize
something related with the processing instructions).

Thanks in advance,
Javier Díaz

Re: [Xsltforms-support] XSLTForms browsers compatibility + Some issues using XSLTForms in server side.

[COUTHURES A. <ala...@ag...>]

Hello Javier,
> Then, to implement the XForms solution, we discovered XSLTForms, and we
> decided that for us it was the most suitable solution to get XForms
> work, mainly because we have on our server a xslt layer to adapt our web
> pages output.
>   
Thank you for choosing XSLTForms!
> After using the examples with several browsers, we concluded that
> XSLTForms seems to work OK with at least Firefox 3, Internet Explorer 7,
> Opera and Konqueror.
I thought Konqueror had not XSLT engine... Are you talking about a 
server side transformation for Konqueror?
>  But we have experienced some problems with Firefox
> 2. 
Beta 2 release has been successfully tested with FireFox 2.0.0.17 for 
Windows. FF2 support has been a problem in intermediate work version 
because event management in FireFox has been clearly change since FF3.0. 
Workarounds have been implemented for FF2 support. Can you please send 
me a test case where FF2 support is not correct?
> So, in first place, we would like to know if there is any list of
> browsers that are known to work ok (or no ok) with XSLTForms, to know if
> we will experience problems with users that have old browsers when are
> using our new web application.
>   
XSLTForms has also been successfully tested with FF 3.0, FF 3.5, IE6 
latest SP, IE7 latest SP, IE8, Safari 4, Opera 10 and Chrome.
> Later, we tried to use the xsl of xsltforms in our server side xslt
> layer and we experienced some problems that we managed to solve. These
> problems were mainly that our system (based on Java) wasn't able to load
> the xsl as it was when we downloaded it from sourceforge, due to using
> the server side xsl we didn't have defined any processing instruction.
> Commenting out in xslt all lines with commands like
> "translate(normalize-space(/processing-instruction('css-conversion')[1]),
> 'YESNO ', 'yesno')='no'" or
> "translate(normalize-space(/processing-instruction('xml-stylesheet')[1])",
> we managed to load the xsl and it seems to work ok in our system. We
> send you attached to this mail a patch with all changes we have done in
> your xsl to make it work.
>   
In fact, there are more processing-instructions tests in Beta 2 
release... But this should not interfere anymore with server side 
transformation, the parameter "baseuri" having been added to permit 
eXist-db to perform the transformation.

Best regards,

-Alain

Re: [Xsltforms-support] XSLTForms browsers compatibility + Some issues using XSLTForms in server side.

[Javier D. <jd...@ge...>]

COUTHURES Alain escribió:
> Hello Javier,
>> Then, to implement the XForms solution, we discovered XSLTForms, and we
>> decided that for us it was the most suitable solution to get XForms
>> work, mainly because we have on our server a xslt layer to adapt our web
>> pages output.
>>   
> Thank you for choosing XSLTForms!
>> After using the examples with several browsers, we concluded that
>> XSLTForms seems to work OK with at least Firefox 3, Internet Explorer 7,
>> Opera and Konqueror.
> I thought Konqueror had not XSLT engine... Are you talking about a
> server side transformation for Konqueror?
Yes, we do a server side transformation of the xsl and konqueror is
capable to process the javascript and the rest of stuff generated by the
xsl.
>>  But we have experienced some problems with Firefox
>> 2. 
> Beta 2 release has been successfully tested with FireFox 2.0.0.17 for
> Windows. FF2 support has been a problem in intermediate work version
> because event management in FireFox has been clearly change since
> FF3.0. Workarounds have been implemented for FF2 support. Can you
> please send me a test case where FF2 support is not correct?
The person that had problems using Firefox 2 had version 2.0.0.10, so no
problem, we have recommended him to update to last 2.0.0.X or 3.X versions.
>> So, in first place, we would like to know if there is any list of
>> browsers that are known to work ok (or no ok) with XSLTForms, to know if
>> we will experience problems with users that have old browsers when are
>> using our new web application.
>>   
> XSLTForms has also been successfully tested with FF 3.0, FF 3.5, IE6
> latest SP, IE7 latest SP, IE8, Safari 4, Opera 10 and Chrome.
Ok, many thanks :)
>> Later, we tried to use the xsl of xsltforms in our server side xslt
>> layer and we experienced some problems that we managed to solve. These
>> problems were mainly that our system (based on Java) wasn't able to load
>> the xsl as it was when we downloaded it from sourceforge, due to using
>> the server side xsl we didn't have defined any processing instruction.
>> Commenting out in xslt all lines with commands like
>> "translate(normalize-space(/processing-instruction('css-conversion')[1]),
>>
>> 'YESNO ', 'yesno')='no'" or
>> "translate(normalize-space(/processing-instruction('xml-stylesheet')[1])",
>>
>> we managed to load the xsl and it seems to work ok in our system. We
>> send you attached to this mail a patch with all changes we have done in
>> your xsl to make it work.
>>   
> In fact, there are more processing-instructions tests in Beta 2
> release... 
Yes, I attached in the previous email the diff with all the
processing-instructions commented.
> But this should not interfere anymore with server side transformation,
> the parameter "baseuri" having been added to permit eXist-db to
> perform the transformation.
Yes, I use the parameter "baseuri", is very useful to locate the
xslforms archive in a directory instead in webapp root directory.

But using baseuri, if I leave uncommented the first
processing-instruction, I get when loading the xsl:

javax.xml.transform.TransformerConfigurationException: No se ha podido
compilar la hoja de estilos
        at
com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:825)

(No se ha podido compilar la hoja de estilos in spanish means that it
wasn't possible to compile the stylesheet)

The code that is failing is (only fails when we have the processing
instructions):

                                Templates template = null;
                                if( file != null )
                                {
                                        Source xslSource =  new
StreamSource (new File(GRMEntorno.PATH_XSL + GRMEntorno.SEP + file) );
                                        TransformerFactory tFactory =
TransformerFactory.newInstance();
                                        *template =
tFactory.newTemplates( xslSource );*
                                }

¿Are we missing something? I will investigate in eXist-db project how is
dealing with xsls, but I don't see any strange thing in our code...

Best regards,
Javier
>
> Best regards,
>
> -Alain

Re: [Xsltforms-support] XSLTForms browsers compatibility + Some issues using XSLTForms in server side.

[COUTHURES A. <ala...@ag...>]

Hello Javier,
> But using baseuri, if I leave uncommented the first 
> processing-instruction, I get when loading the xsl:
>
> javax.xml.transform.TransformerConfigurationException: No se ha podido 
> compilar la hoja de estilos
>         at 
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:825)
>
> (No se ha podido compilar la hoja de estilos in spanish means that it 
> wasn't possible to compile the stylesheet)
>
> The code that is failing is (only fails when we have the processing 
> instructions):
>
>                                 Templates template = null;
>                                 if( file != null )
>                                 {
>                                         Source xslSource =  new 
> StreamSource (new File(GRMEntorno.PATH_XSL + GRMEntorno.SEP + file) );
>                                         TransformerFactory tFactory = 
> TransformerFactory.newInstance();
>                                         *template = 
> tFactory.newTemplates( xslSource );*
>                                 }
It sounds like a Xalan problem... Did you already have a look at posts 
concerning similar problems : 
http://stackoverflow.com/questions/1235121/java-problem-loading-stylesheet 
, http://dev.eclipse.org/newslists/news.eclipse.webtools/msg18031.html ?

Best regards,

-Alain

Re: [Xsltforms-support] XSLTForms browsers compatibility + Some issues using XSLTForms in server side.

[Javier D. <jd...@ge...>]

Hello Alain,

activating debug mode in xslt compilation, this error appeared:

com.sun.org.apache.bcel.internal.generic.ClassGenException: ICONST can
be used only for value between -1 and 5: 7
        at
com.sun.org.apache.bcel.internal.generic.ICONST.<init>(ICONST.java:81)
        at
com.sun.org.apache.xalan.internal.xsltc.compiler.Step.translatePredicates(Step.java:412)
        at
com.sun.org.apache.xalan.internal.xsltc.compiler.Step.translate(Step.java:237)
        at
com.sun.org.apache.xalan.internal.xsltc.compiler.AbsoluteLocationPath.translate(AbsoluteLocationPath.java:101)
        at
com.sun.org.apache.xalan.internal.xsltc.compiler.CastExpr.translate(CastExpr.java:229)
        at
com.sun.org.apache.xalan.internal.xsltc.compiler.FunctionCall.translate(FunctionCall.java:710)

Then, I tried to simplify the processing-instruction commands, using an
extra variable and it seems that Xalan can process the xsl and it seems
it works ok.
25,26c25
<                       <xsl:variable name="pivaluebck"
select="/processing-instruction('xml-stylesheet')"/>
<                       <xsl:variable name="pivalue"
select="translate(normalize-space($pivaluebck[1]), ' ', '')"/>
---
>                       <xsl:variable name="pivalue"
select="translate(normalize-space(/processing-instruction('xml-stylesheet')[1]),
' ', '')"/>

¿Is it possible to make a change in xsltforms xsl like this to al the
proccessing-instruction lines to be able to use it with Xalan?

In addition, I have seen that you have some processing-instruction lines
duplicated (css-conversion and xsltforms-options ones). Taking in
account that the processing instructions  you have are global, and are
located in the top of xml document if defined, maybe is better to
retrieve its value at the beginning of the document (I completely ignore
if this can affect to your xsl, it is only a suggestion).

Best Regards,
Javier

COUTHURES Alain escribió:
> Hello Javier,
>> But using baseuri, if I leave uncommented the first
>> processing-instruction, I get when loading the xsl:
>>
>> javax.xml.transform.TransformerConfigurationException: No se ha
>> podido compilar la hoja de estilos
>>         at
>> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:825)
>>
>> (No se ha podido compilar la hoja de estilos in spanish means that it
>> wasn't possible to compile the stylesheet)
>>
>> The code that is failing is (only fails when we have the processing
>> instructions):
>>
>>                                 Templates template = null;
>>                                 if( file != null )
>>                                 {
>>                                         Source xslSource =  new
>> StreamSource (new File(GRMEntorno.PATH_XSL + GRMEntorno.SEP + file) );
>>                                         TransformerFactory tFactory =
>> TransformerFactory.newInstance();
>>                                         *template =
>> tFactory.newTemplates( xslSource );*
>>                                 }
> It sounds like a Xalan problem... Did you already have a look at posts
> concerning similar problems :
> http://stackoverflow.com/questions/1235121/java-problem-loading-stylesheet
> , http://dev.eclipse.org/newslists/news.eclipse.webtools/msg18031.html ?
>
> Best regards,
>
> -Alain

Re: [Xsltforms-support] XSLTForms browsers compatibility + Some issues using XSLTForms in server side.

[COUTHURES A. <ala...@ag...>]

Hello Javier,
> activating debug mode in xslt compilation, this error appeared:
>
> com.sun.org.apache.bcel.internal.generic.ClassGenException: ICONST can 
> be used only for value between -1 and 5: 7
>         at 
> com.sun.org.apache.bcel.internal.generic.ICONST.<init>(ICONST.java:81)
>         at 
> com.sun.org.apache.xalan.internal.xsltc.compiler.Step.translatePredicates(Step.java:412)
>         at 
> com.sun.org.apache.xalan.internal.xsltc.compiler.Step.translate(Step.java:237)
>         at 
> com.sun.org.apache.xalan.internal.xsltc.compiler.AbsoluteLocationPath.translate(AbsoluteLocationPath.java:101)
>         at 
> com.sun.org.apache.xalan.internal.xsltc.compiler.CastExpr.translate(CastExpr.java:229)
>         at 
> com.sun.org.apache.xalan.internal.xsltc.compiler.FunctionCall.translate(FunctionCall.java:710)
It seems this exception is already known as a possible bug: 
http://marc.info/?l=xalan-dev&m=117629991417675&w=2

Are you using the latest Xalan version ?
>
> Then, I tried to simplify the processing-instruction commands, using 
> an extra variable and it seems that Xalan can process the xsl and it 
> seems it works ok.
> 25,26c25
> <                       <xsl:variable name="pivaluebck" 
> select="/processing-instruction('xml-stylesheet')"/>
> <                       <xsl:variable name="pivalue" 
> select="translate(normalize-space($pivaluebck[1]), ' ', '')"/>
> ---
> >                       <xsl:variable name="pivalue" 
> select="translate(normalize-space(/processing-instruction('xml-stylesheet')[1]), 
> ' ', '')"/>
>
> ¿Is it possible to make a change in xsltforms xsl like this to al the 
> proccessing-instruction lines to be able to use it with Xalan?
There are already workarounds in XSLTForms like the one you found for 
other XSLT engines problems. So, I will change this in XSLTForms as you 
suggest. I will contact you again when it will be committed.
>
> In addition, I have seen that you have some processing-instruction 
> lines duplicated (css-conversion and xsltforms-options ones). Taking 
> in account that the processing instructions  you have are global, and 
> are located in the top of xml document if defined, maybe is better to 
> retrieve its value at the beginning of the document (I completely 
> ignore if this can affect to your xsl, it is only a suggestion).
Instead of global variables, I prefer having local variables defined and 
used in the corresponding source component (if you have a look at the 
SVN repository, you will see that the xsltforms.xsl file is generated 
from many source components!).

Best regards,

-Alain

Re: [Xsltforms-support] XSLTForms browsers compatibility + Some issues using XSLTForms in server side.

[Javier D. <jd...@ge...>]

COUTHURES Alain escribió:
> Hello Javier,
>> activating debug mode in xslt compilation, this error appeared:
>>
>> com.sun.org.apache.bcel.internal.generic.ClassGenException: ICONST
>> can be used only for value between -1 and 5: 7
>>         at
>> com.sun.org.apache.bcel.internal.generic.ICONST.<init>(ICONST.java:81)
>>         at
>> com.sun.org.apache.xalan.internal.xsltc.compiler.Step.translatePredicates(Step.java:412)
>>         at
>> com.sun.org.apache.xalan.internal.xsltc.compiler.Step.translate(Step.java:237)
>>         at
>> com.sun.org.apache.xalan.internal.xsltc.compiler.AbsoluteLocationPath.translate(AbsoluteLocationPath.java:101)
>>         at
>> com.sun.org.apache.xalan.internal.xsltc.compiler.CastExpr.translate(CastExpr.java:229)
>>         at
>> com.sun.org.apache.xalan.internal.xsltc.compiler.FunctionCall.translate(FunctionCall.java:710)
> It seems this exception is already known as a possible bug:
> http://marc.info/?l=xalan-dev&m=117629991417675&w=2
>
> Are you using the latest Xalan version ?
I'm using the Xalan version that comes with the sun jvm. In my case, it is:

$ java -server -version
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Server VM (build 14.1-b02, mixed mode)


It is one of the latest java 1.6 versions (the last is 1.6.17), so maybe
is a different bug, I suppose the one you indicated is old enough to be
solved.
>>
>> Then, I tried to simplify the processing-instruction commands, using
>> an extra variable and it seems that Xalan can process the xsl and it
>> seems it works ok.
>> 25,26c25
>> <                       <xsl:variable name="pivaluebck"
>> select="/processing-instruction('xml-stylesheet')"/>
>> <                       <xsl:variable name="pivalue"
>> select="translate(normalize-space($pivaluebck[1]), ' ', '')"/>
>> ---
>> >                       <xsl:variable name="pivalue"
>> select="translate(normalize-space(/processing-instruction('xml-stylesheet')[1]),
>> ' ', '')"/>
>>
>> ¿Is it possible to make a change in xsltforms xsl like this to al the
>> proccessing-instruction lines to be able to use it with Xalan?
> There are already workarounds in XSLTForms like the one you found for
> other XSLT engines problems. So, I will change this in XSLTForms as
> you suggest. I will contact you again when it will be committed.
Many thanks :) I will try it as soon as you change it.
>>
>> In addition, I have seen that you have some processing-instruction
>> lines duplicated (css-conversion and xsltforms-options ones). Taking
>> in account that the processing instructions  you have are global, and
>> are located in the top of xml document if defined, maybe is better to
>> retrieve its value at the beginning of the document (I completely
>> ignore if this can affect to your xsl, it is only a suggestion).
> Instead of global variables, I prefer having local variables defined
> and used in the corresponding source component (if you have a look at
> the SVN repository, you will see that the xsltforms.xsl file is
> generated from many source components!).
Oh, I didn't know you split the xsl in several pieces, a good idea if it
gets too long :)
>
> Best regards,
>
> -Alain
>