--- [EMAIL PROTECTED] wrote:
> The issues I currently see:
> - a very important one: localization of error messages
A possible strategy for localization of error messages (and other
messages) is to use the xml:lang attribute:
<xforms:input ref="text">
<xforms:alert xml:lang="en">The age must...</xforms:alert>
<xforms:alert xml:lang="fr">L'age doit...</xforms:alert>
</xforms:input>
xforms-to-xhtml.xsl generates inside the <xhtml:body> element:
<f:alerts>
<f:alert>The age must be...</f:alert>
</f:alerts>
The <f:alerts> contains one <f:alert> for each invalid control. Right now
xforms-to-xhtml.xsl does not take into account the xml:lang attribute and
always takes the first <xforms:alert>. But you/we can change this to
either:
1) Copy the <xforms:alert> with the appropriate locale for the current
user into a <f:alert>.
2) Copy all the <xforsms:alert> in <f:alert> along with the xml:lang
attribute and let the theme decide which one to display (or another
stylesheet downstream in the epilogue).
I prefer the latter as it keeps that logic out of xforms-to-xhtml.xsl. How
does that sound? BTW, I added an RFE for this (http://tinyurl.com/5e4zs).
> - xforms:bind is basically a client side validation therefore it is not
> suitable for many kinds of error validation which involve verification
> of rules of business entities residing on the server. Even if you could
> express some rules it does not seem like the place to put them - an
> issue that immediately occurs to me would for e.g. be reuse of
validation
> logic
I wouldn't say that <xforms:bind> is only for client side validation. You
can define validation rules with <xforms:bind>. The rules can be executed
by an XForms engine on the client side, the server side, or both. The
rules can be simple type checking validation rules, or can be business
logic rules. The latter is often done with XPath expressions, e.g.
<xforms:bind constraint="...">. Some business logic rules cannot be
expressed as XPath expressions, or in some cases expressing the rules as
XPath expressions is not appropriate from a software architecture point of
view. In those cases, you delegate the validation to a "backend service"
that annotates the instance with xxforms:invalid="false" attributes; those
attributes are then correctly understood by the XForms engine. You a few
options here and you can choose the most appropriate one depending on your
situation.
> p.s.: XMLBeans seem to have meningful and correct validation messages.
Yes, that's right. We are using XMLBeans in Studio and had a fairly good
experience with it. So the plan now is to use XMLBeans for validation in
Presentation Server as well.
Alex
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
orbeon-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
