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?
* 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.
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine & Food Blog: http://www.divinocibo.it/
