XForms language 'peculiarities' in OPS

Hello,

In the process of writing XForms pages compatible with both OPS and
Mozilla, I have found a few 'strange' differences.
For example, to create a trigger rendered as a link,
@appearance="xxforms:link" has te be used in OPS, whereas the same
behavior is achieved in Mozilla with @appearance="compact".
I can understand here that the reason is because the spec remains
silent on this topic... but I really don't understand, say, the choice
concerning buttons in the form of an image.
So, in OPS, for a submit, it looks like :

  <xforms:submit submission="main-submission" appearance="xxforms:image">
    <xxforms:img src="images/submit.gif"/>
    <xforms:label>Submit</xforms:label>
  </xforms:submit>

Whereas, what I understand is "the right way to do it" looks like :

  <xforms:submit submission="main-submission">
    <xforms:label><xhtml:img src="images/submit.gif"/></xforms:label>
  </xforms:submit>

I have also some remarks concerning XPath, as you made the choice to
use XPath *2.0* (if() function, etc) -- which is AFAIK not supported
by Mozilla.
How could we come up with a compatible solution ? I was wondering
about using fully qualified XPath function names but I don't think
this is technically possible.
Or maybe it's possible to configure OPS to evaluate XPath calls either
using 1.0 or 2.0 version by default.

I am sure there are some other 'peculiarities' in OPS which I haven't
seen yet. It may be interesting to list them ?

Cheers,

--
Damiano ALBANI



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

  Damiano,

 > For example, to create a trigger rendered as a link,
 > @appearance="xxforms:link" has te be used in OPS, whereas the same
 > behavior is achieved in Mozilla with @appearance="compact".
 > I can understand here that the reason is because the spec remains
 > silent on this topic...

The two examples you provide above are good ones, and we agree that we
should support these "right ways" and in time deprecate xxforms:link
and xxforms:image.

The reasons for these choices are purely historical. When we started
implementing XForms back in 2002, XForms 1.0 was not even a
recomendation yet (it only became one in late 2003). Even today, the
specifics of integration between XForms and XHTML 1.x are not
specified at all, just hinted at, which means that implementors have
over time been experimenting and discussing the best ways of
implementing certain common features, such as "triggers as links" or
"triggers as images".

In a way this is very good, following the philosophy of implementing
code and experimenting first, and then only standardize.

A note regarding the case of the image: you could also want the result
to look like an HTML <button> element (which can contain HTML markup
inside). So I think that if you just want a clickable image, it is
reasonable to use @appearance="minimal" (this is, AFAIK, what
FormPlayer supports):

   <xforms:trigger appearance="minimal">
     <xforms:label>
       <img src="/images/edit.gif" alt="Edit" />
     </xforms:label>
   </xforms:trigger>

Does Mozilla use this appearance, or not? If it doesn't, I think it
should ;-) The semantic of this appearance would then simply be to
mandate the use of a link instead of a regular button.

To get back to the actual reasons we don't support these two
particular mechanisms you mention, the main one is that we have very
limited resources and so much to do! But I think the code is now very
close to being able to support xhtml:img in xforms:label: since very
recent builds, we support XHTML in xforms:help, and xforms:label in a
trigger shouldn't be much harder to support. I entered an RFE to track
this:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=306057&group_id=168&atid=350207

 > I have also some remarks concerning XPath, as you made the choice to
 > use XPath *2.0* (if() function, etc) -- which is AFAIK not supported
 > by Mozilla.

That's right.

 > How could we come up with a compatible solution ? I was wondering
 > about using fully qualified XPath function names but I don't think
 > this is technically possible.

Save for providing an XPath 1.0 implementation, it is not possible to
get a fully compatible solution, mainly because of that quite stupid
if() function introduced in XForms 1.0.

Note that we did support that standard function under the name xfif()
(which was named way also for historical reasons). It is now also
bound to the name xxforms:if(), which we recommend you use (xfif() is
just plain ugly!).

 > Or maybe it's possible to configure OPS to evaluate XPath calls either
 > using 1.0 or 2.0 version by default.

That would be the ideal solution, but it would be some work to support
XPath 1.0 (you have to use a completely different XPath
implementation), and so far we have decided that there are higher
priorities in OPS. But we do have this as a bug:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=303758&group_id=168&atid=350207

 > I am sure there are some other 'peculiarities' in OPS which I haven't
 > seen yet. It may be interesting to list them ?

I think that support for XPath 2.0 is the main one. Otherwise, I think
we are talking about incompatibilities between implementations rather
than issues of conformance to the spec. Now those should be listed,
and we still have to build an up-to-date conformance table. We have a
placeholder for it here:

   http://www.orbeon.com/ops/doc/reference-xforms-compliance

I have added documentation about the use of the xxforms:if() and
native XPath 2.0 if... then... else construct there.

Thanks for the feedback, and please keep sending such
incompatibilities if you find more!

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 8/28/06, Erik Bruchez <[hidden email]> wrote:

> The reasons for these choices are purely historical.

Ok, I see.


> A note regarding the case of the image: you could also want the result
> to look like an HTML <button> element (which can contain HTML markup
> inside). So I think that if you just want a clickable image, it is
> reasonable to use @appearance="minimal" (this is, AFAIK, what
> FormPlayer supports):

Yes, Mozilla renders it correctly, with only the image (doesn't look
like a 'button').

> To get back to the actual reasons we don't support these two
> particular mechanisms you mention, the main one is that we have very
> limited resources and so much to do! But I think the code is now very
> close to being able to support xhtml:img in xforms:label: since very
> recent builds, we support XHTML in xforms:help, and xforms:label in a
> trigger shouldn't be much harder to support.

I'll *try* to see if I can find my way inside the code and modify it
accordingly :-)

>
> Save for providing an XPath 1.0 implementation, it is not possible to
> get a fully compatible solution, mainly because of that quite stupid
> if() function introduced in XForms 1.0.
>
> Note that we did support that standard function under the name xfif()
> (which was named way also for historical reasons). It is now also
> bound to the name xxforms:if(), which we recommend you use (xfif() is
> just plain ugly!).

I've just seen your commit concerning this -- thanks !
But I fail to see how that could work with Mozilla, as you put this
if() function inside xxforms NS. Because, in regard to the specs, it
should the other way around : XForms 1.0's if() in xforms NS and OPS's
preferred XPath 2.0-based if() in xxforms NS, shouldn't it ?

> Thanks for the feedback, and please keep sending such
> incompatibilities if you find more!

I found another one I think :
OPS introduces an xxforms:@format attribute to format a date for example.

  <xforms:output ref="myDate"

xxforms:format="format-dateTime(xs:dateTime(.), '[D] [Mn] [Y]', 'fr',
(), ())"/>

To get the same result and be XForms 1.0 valid, I thought of something like :

  <xforms:output value="exslt:format-dateTime(xs:dateTime(myDate),
'[D] [Mn] [Y]', 'fr', (), ())"/>

along with a :

  <xforms:model xmlns:exslt="http://exslt.org/dates-and-times"
                         functions="exslt:format-dateTime">...

to make sure EXSLT functions are supported.

What do you think ?

--
Damiano ALBANI



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Damiano Albani wrote:

  Hi

> To get the same result and be XForms 1.0 valid, I thought of
> something like :

>   <xforms:output value="exslt:format-dateTime(xs:dateTime(myDate),
> '[D] [Mn] [Y]', 'fr', (), ())"/>

  Do you mean to be XPath 1.0-compatible (I'm not sure)?  In this case
you'll have an error telling you the xs:dateTime() function is unknown,
as constructors from XML Schemas are defined in XPath 2.0.

  Regards,

--drkm





















       
 p4.vert.ukl.yahoo.com uncompressed/chunked Mon Aug 28 11:13:44 GMT 2006
       
               
___________________________________________________________________________
Découvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet !
Yahoo! Questions/Réponses pour partager vos connaissances, vos opinions et vos expériences.
http://fr.answers.yahoo.com 




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 8/28/06, Florent Georges <[hidden email]> wrote: Yes, I meant XForms 1.0 compatible. But as you say that xs:dateTime()
constructor is in XPath 2.0... :/
Anyway, AFAIK, xs:dateTime datatype is "supported" in XForms 1.0 and
EXSLT functions are compatible.
So that means that with a proper XML Schema associated with my
xforms:model, it must be possible to format a date corresponding to a
node in an instance ?

--
Damiano ALBANI



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Damiano,

 >> Note that we did support that standard function under the name xfif()
 >> (which was named way also for historical reasons). It is now also
 >> bound to the name xxforms:if(), which we recommend you use (xfif() is
 >> just plain ugly!).
 >
 > I've just seen your commit concerning this -- thanks !
 > But I fail to see how that could work with Mozilla, as you put this
 > if() function inside xxforms NS. Because, in regard to the specs, it
 > should the other way around : XForms 1.0's if() in xforms NS and OPS's
 > preferred XPath 2.0-based if() in xxforms NS, shouldn't it ?

As I said, AFAIK there is no way you can get compatibility with XPath
2.0 because the if() function clashes with XPath 2.0's built-in if()
construct. The standard XForms 1.0 function library, including the
if() function, are not in a namespace, and I don't think they are
allowed to be! On the other hand the XPath 2.0 if() construct is built
into the language: it's not a function, and is not allowed to be in a
namespace. So we are stuck ;-)

My only point was that you can minimize the changes required between
implementations by using xxforms:if() as it has the same syntax as the
standard XForms if(). But this still does not make XPath expressions
compatible between XPath 1.0 and 2.0.

 > I found another one I think :
 > OPS introduces an xxforms:@format attribute to format a date for example.
 >
 >  <xforms:output ref="myDate"
 >
 > xxforms:format="format-dateTime(xs:dateTime(.), '[D] [Mn] [Y]', 'fr',
 > (), ())"/>
 >
 > To get the same result and be XForms 1.0 valid, I thought of something
 > like :
 >
 >  <xforms:output value="exslt:format-dateTime(xs:dateTime(myDate),
 > '[D] [Mn] [Y]', 'fr', (), ())"/>
 >
 > along with a :
 >
 >  <xforms:model xmlns:exslt="http://exslt.org/dates-and-times"
 >                         functions="exslt:format-dateTime">...
 >
 > to make sure EXSLT functions are supported.

What we are using is actually an XSLT 2.0 function, not an EXSLT
function (EXSLT functions are XPath 1.0 functions, not 2.0). So
certainly I wouldn't use the EXSLT namespace, but possibly the xxforms
namespace.

I this particular case though, xxforms:format is an OPS extension, so
there is no point to worry about this as you are using an extension
anyway. But your point would stand if you use format-dateTime() in
other places, and a case could be made that we shouldn't import XSLT
2.0 functions in no namespace. Still, all XPath 2.0 functions woul be
built-in anyway and in no namespace.

So again, I think the ideal approach would be to support XPath 1.0
only by default, and have a switch to support XPath 2.0 and its
extensive function library.

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Damiano,

 > Anyway, AFAIK, xs:dateTime datatype is "supported" in XForms 1.0 and
 > EXSLT functions are compatible.

xs:dateTime is not supported in XForms 1.0's XPath expressions. You
can use a schema or the bind/@type attribute to:

o *Validate* instance data with this type.

o *Assign* a type to the node, that can be used by controls bound to
   the node.

However, XPath expressions in XForms 1.0 will still not know anything
about the type! (In particular, because XPath 1.0 only knows about
string, number and boolean types.)

This is different from XSLT 2.0's @as attribute, for example, which
actually assigns a type to the item, and then that type will be used
in XPath expressions using the item.

I think that once XForms support XPath 2.0 officially, then the
semantic of bind/@type should be updated to reflect what happens with
XSLT 2.0 and not only use the type for validation and binding
purposes.

 > So that means that with a proper XML Schema associated with my
 > xforms:model, it must be possible to format a date corresponding to
 > a node in an instance ?

Formatting has nothing to do with validation. Validation will just
check that the lexical value of your instance data is allowed by the
xs:dateTime type and mark the node as invalid if necessary.

In addition, xforms:output is allowed to format data according to the
type assigned by a bind. This is what we do in OPS.

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 8/29/06, Erik Bruchez <[hidden email]> wrote: Phew! Quite complex indeed :)
I think I know what I'll do : use xxforms:if() construct and tell OPS
to pass my pages through a proper XSLT stylesheet to remove the NS
when the page is to be loaded as "pure" XForms.

> What we are using is actually an XSLT 2.0 function, not an EXSLT
> function (EXSLT functions are XPath 1.0 functions, not 2.0). So
> certainly I wouldn't use the EXSLT namespace, but possibly the xxforms
> namespace.

Oh I see, I wasn't aware you used format-date() function from XSLT 2.0.
Anyway, neither XSLT 2.0 or EXLST seems to be supported in the Mozilla
API at the moment... So it seems I'll have to forget date formating in
Mozilla.

> I this particular case though, xxforms:format is an OPS extension, so
> there is no point to worry about this as you are using an extension
> anyway. But your point would stand if you use format-dateTime() in
> other places, and a case could be made that we shouldn't import XSLT
> 2.0 functions in no namespace. Still, all XPath 2.0 functions woul be
> built-in anyway and in no namespace.

What do you think of the design of XSLT/XPath 2.0 concerning this
"no-namespace functions" topic ? Was it done on purpose at the W3C ?

> So again, I think the ideal approach would be to support XPath 1.0
> only by default, and have a switch to support XPath 2.0 and its
> extensive function library.

Quite a lot of work apparently as you said :/

Cheers,

--
Damiano ALBANI



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Erik,

Back to my xforms:trigger appearance stuff, I have had a look at OPS code.

Adding the support for xforms:trigger to look as a link with
@appearance="minimal" was trivial (see diff attached) -- maintaining
compatibility with current practice.

But that's a bit different concerning a trigger with an image label.
Let's say we use this sample label :
  <xforms:label><xhtml:img src="abc.png"/></xforms:label>

There are 2 different cases as we said :

 1. @apperance="minimal"
 2. @apperance="compact"

For 1., the OPS generated (X)HTML could be :

  <xhtml:button name="..." value="..." type="submit">
    <xhtml:img src="abc.png" alt="..." title="..."/>
  </xhtml:button>

But for 2. (minimal) we don't want to see the "grey button" style :

  <xforms:input type="image" src="star.png" title="..." alt="..." name="..."/>

Now, what complicates the matter is that, AFAIU, xforms:label (and
others) have a "mixed" content type. So one could write :

  <xforms:label>Hello <xhtml:img src="star.png"/> World!</xforms:label>

Which means <html:div> will be required to display the whole "widget" properly.

BTW, in XFormsControl.java, one can read :

    private String label;

Working with the content of <xforms:label> (and its children) will
require to consider it as an element, not as a 'blackbox-like' string
of characters (as <xforms:help> and <xforms:hint> containing HTML
markup). What is your opinion ?

Cheers,

--
Damiano ALBANI


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Oops, small typo in the patch.

--
Damiano ALBANI


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi,

Hi All,

I would appreciate your help on this. Hopefully for the experts the problem
should be obvious.

I've installed ops.war on windows with tomcat 4.1.31 and can browse through
the examples with no problem.

I had been unsuccessful at building ops.war from source code and deploying
it on Sun's AppServer, JBOSS 4.0 or even tomcat for that matter.

I wasn't sure how I could practically get rid of the default Orbeon
Presentation Server look and feel with the example applications without
trying to modify the source code and build a lighter version where I would
have only files related to me application. I'm just starting with OPS...

The OPS guide doesn't go into how an application can be developed from
scratch but rather as a sub-application within the examples application and
then it just goes straight into how to use the different modules and
processors (of course as far I could tell, I'm probably wrong about this
too).

So after wasting a lot of time I decided to go back to basics and follow the
tutorial as much as possible. I created a subfolder underneath
resources/examples. I modified the examples-list.xml and now I can get to my
very own sub app as an entry in a new section of the OPS examples
frame/pane.

However I'm now stuck at figuring out why the xu:update which is meant to
copy instance data from one page to another seems not to copy anything.

Here's the page-flow.xml

<config xmlns="http://www.orbeon.com/oxf/controller"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:xu="http://www.xmldb.org/xupdate"
        xmlns:oxf="http://www.orbeon.com/oxf/processors">
   
   <page id="ask-name" path-info="/nnl-mts1" xforms="xforms-model.xml"
view="ask-name-view.xhtml">
      <action when="/myform/action = 'next'">
         <result page="display-name">
            <xu:update select="/myform/name">
               <xu:value-of select="document('oxf:instance')/myform/name"/>
            </xu:update>
         </result>
      </action>
   </page>
   
   <page id="display-name" path-info="/nnl-mts1/display-name"
xforms="xforms-model.xml" view="display-name-view.xhtml">  
      <action when="/myform/action = 'back'">
         <result page="ask-name"/>
      </action>  
   </page>
   <epilogue url="oxf:/config/epilogue.xpl"/>
</config>

Here's the ask-name-view.xhtml

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:xforms="http://www.w3.org/2002/xforms"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xsl:version="2.0">
      <head>
         <title>mFATE Test Server</title>
      </head>
      <body>
         <xforms:group>
            <p>
               Please enter testsuite:
               <xforms:input ref="/myform/name"/>
               <xforms:submit>
                  <xforms:label>Search</xforms:label>
                  <xforms:setvalue
ref="/myform/action">next</xforms:setvalue>
               </xforms:submit>
            </p>
         </xforms:group>
      </body>
</html>

The display-name-view.xhtml

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:xforms="http://www.w3.org/2002/xforms"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xsl:version="2.0">
      <head>
         <title>mFATE Test Server</title>
      </head>
      <body>
         <xforms:group>
            <p>Name <xsl:value-of select="/myform/name" /> Launched!</p>  
            <xforms:submit>
               <xforms:label>Back</xforms:label>
               <xforms:setvalue ref="/myform/action">back</xforms:setvalue>
            </xforms:submit>            
         </xforms:group>
      </body>
</html>

The xforms-model.xml

<xforms:model xmlns:xforms="http://www.w3.org/2002/xforms">
   <xforms:instance xmlns="">
      <myform>
         <action/>      
         <name/>
         <description/>
      </myform>
   </xforms:instance>
</xforms:model>

The relevant bit in the examples-list.xml is

   <section label="Newport Networks">
      <example id="nnl-mts1" path="nnl/mts1" label="mFATE Test Server"/>
      <example id="nnl-mfate" path="nnl/mfate" label="mFATE Web Application
Server 1.0"/>
   </section>

The Next and Back buttons work alright. But the xsl:value-of in
display-name-view.xhtml instance seems to be empty because I only see Name !
instead of Name <whatever I typed in the other page>!

Any ideas?

MZ


-----Original Message-----
From: Damiano Albani [mailto:[hidden email]]
Sent: 29 August 2006 14:46
To: [hidden email]
Subject: Re: [ops-users] XForms language 'peculiarities' in OPS

On 8/29/06, Erik Bruchez <[hidden email]> wrote: Phew! Quite complex indeed :)
I think I know what I'll do : use xxforms:if() construct and tell OPS
to pass my pages through a proper XSLT stylesheet to remove the NS
when the page is to be loaded as "pure" XForms.

> What we are using is actually an XSLT 2.0 function, not an EXSLT
> function (EXSLT functions are XPath 1.0 functions, not 2.0). So
> certainly I wouldn't use the EXSLT namespace, but possibly the xxforms
> namespace.

Oh I see, I wasn't aware you used format-date() function from XSLT 2.0.
Anyway, neither XSLT 2.0 or EXLST seems to be supported in the Mozilla
API at the moment... So it seems I'll have to forget date formating in
Mozilla.

> I this particular case though, xxforms:format is an OPS extension, so
> there is no point to worry about this as you are using an extension
> anyway. But your point would stand if you use format-dateTime() in
> other places, and a case could be made that we shouldn't import XSLT
> 2.0 functions in no namespace. Still, all XPath 2.0 functions woul be
> built-in anyway and in no namespace.

What do you think of the design of XSLT/XPath 2.0 concerning this
"no-namespace functions" topic ? Was it done on purpose at the W3C ?

> So again, I think the ideal approach would be to support XPath 1.0
> only by default, and have a switch to support XPath 2.0 and its
> extensive function library.

Quite a lot of work apparently as you said :/

Cheers,

--
Damiano ALBANI





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Damiano Albani wrote:

>> I this particular case though, xxforms:format is an OPS extension, so
>> there is no point to worry about this as you are using an extension
>> anyway. But your point would stand if you use format-dateTime() in
>> other places, and a case could be made that we shouldn't import XSLT
>> 2.0 functions in no namespace. Still, all XPath 2.0 functions woul be
>> built-in anyway and in no namespace.
>
> What do you think of the design of XSLT/XPath 2.0 concerning this
> "no-namespace functions" topic ? Was it done on purpose at the W3C ?

This was the case in XSLT 1.0 already. I can see why you wouldn't want
to require that users specify a namespace prefix all the time for
standard functions: this would make the syntax much heavier. I can only
guess that this philosophy was just carried over to XSLT 2.0. So I am
sure this was done on purpose, but I do not know the tradeoffs /
discussions that were involved if any when working on XSLT 2.0.

Note that tomorrow you can invent your own language called foobar and
import the standard XPath 2.0 standard library in a namespace if you
think that this is a good idea.

Now you clearly have an issue when a language like XForms adds its own
functions to XPath, doesn't use a namespace, and then is not careful to
make sure that its function names do not conflict with XPath 2.0 (which
was already well under way in late 2003), as is the case with the "if"
function. Big mistake in my opinion.

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello,

Thanks Erik for your explanation.
I resolved my "xxforms:if()" issue by removing the prefix with an
appropriate XSLT stylesheet before serving to Mozilla XForms clients.
As for date formatting, I shifted this functionality on the server
side, accessed through a simple webservice -- hack hack !

Now I was wondering how hard it would be to support the different
"standard" <xforms:trigger> @appearance modes. And more importantly,
to consider that the <xforms:label> element carries *mixed* (HTML)
content.

That would amount to 'evaluate' and replace all xforms:* element
inside it (as done currently for the xforms:output) and then enclose
the result (HTML markup) into a big <xhtml:button> element.

And, in case of @appearance="minimal", apply some kind of CSS to this
button, like :
  { border: 0; background: inherit; }

That would be quite nice to have OPS XForms compliant on this topic ! :-)
Maybe there are technical difficulties I'm not aware of, though.

--
Damiano ALBANI



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Damiano,

 > Now I was wondering how hard it would be to support the different
 > "standard" <xforms:trigger> @appearance modes. And more importantly,
 > to consider that the <xforms:label> element carries *mixed* (HTML)
 > content.

 > That would amount to 'evaluate' and replace all xforms:* element
 > inside it (as done currently for the xforms:output) and then enclose
 > the result (HTML markup) into a big <xhtml:button> element.

We are pretty close from this, since xforms:help supports that now. So
I would say "not too hard".

 > And, in case of @appearance="minimal", apply some kind of CSS to this
 > button, like :
 >  { border: 0; background: inherit; }
 >
 > That would be quite nice to have OPS XForms compliant on this topic ! :-)

It's not compliance per se (XForms does not specify how these things
should work), just enhanced compatibility with other implementations!

 > Maybe there are technical difficulties I'm not aware of, though.

No particularly, it's just that days only have 24 hours ;-)

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws