Ugo Cei wrote:
Il giorno 01/ago/05, alle 22:37, Jason Johnston ha scritto:
We create a new template element, <ft:validation-errors />. When this
element is encountered by FormsTemplateTransformer (or the jx macros),
the widget tree is walked and each widget is checked for a validation
error. If one is present it is added to the transformer output, for
example:
<fi:validation-errors id="forms-validation-errors-0">
<fi:validation-error widget-id="street">Validation error for street
widget</fi:validation-error>
<fi:validation-error widget-id="companyInfo.companyName">Validation
error for company name widget</fi:validation-error>
<!-- etc. for each validation error in the form -->
</fi:validation-errors>
The @id in that output is autogenerated, and the number on the end is an
index so that we can allow the template element to appear multiple times
in the document and avoid duplicate ids (if necessary, just a thought.)
In terms of XSLT styling, if there are no errors present then it would
be presented like fi:placeholder (create an element with the matching
@id so the AJAX code knows where to insert its replacement). If there
are errors present then it would be presented much like the current
fi:validation-errors.
Looks good to me. AFAIK, Ajax support works only with the template
macros, so it might not make sense to add this feature to the
transformer also. What is the orientation of the community towards the
transformer/macros ambiguity? I'd like to have just one recommended
implementation of this, so if macros are the way to go, what about
deprecating the forms transformer?
Well, macros are more powerful because they allow to do more than
templating with the widgets. A straightforward example is conditional
templating, e.g. displaying "There are now contacts" rather than an
empty table. This is not possible with a transformer, unless we add an
expression language and some control structures which will make it yet
another programming-language-in-XML...
OTOH, the transformer is useful when JXTG is not a option e.g. when the
generator is an XSP...
* How, if at all, would be retain compatibility with the old
fi:validation-errors styling element? One approach might be to check
for the presence of the @id attribute in the XSLT and if it isn't there
use the old xsl:template.
Anoother possibility would be using a totally different name for the
element you are proposing here. But I think I like your idea more. We
can put a comment before the old template stating that it is there for
backward compatibility reasons only, and in one of the next releases
modify it to output a deprecation warning message.
Yup.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
