On Mon, 2005-08-01 at 13:19 -0600, Jason Johnston wrote: > You are correct, it is not "produced" by anything besides the template > author. It's simply a styling hint, much like fi:group, which is > handled entirely by the XSLT. > > Unfortunately this means that it is never included in the AJAX browser- > update XML since there's nothing to ensure it's wrapped in a <bu:update> > element. (Hmm, would manually wrapping it in a <bu:update> in the > template do the trick? I wonder. It would definitely need an id > attribute though.) I think there's a definite usefulness in having it > AJAX-enabled, so perhaps it needs to be handled further upstream, e.g. > in FormsTemplateTransformer. Should it become an ft-namespaced element > instead like <ft:validation-errors id="someId" />? Thoughts? I'm > willing to take a whack at putting together a patch, with guidance.
Some more thoughts on a possible approach: 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. ------------ Things to figure out/think about: * 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. * Since this approach builds the list of validation errors from the widget tree rather than the template, the order of the errors may not be the same as the order the fields appear on the page. Would there be a way to control this ordering in the template transformer so the ordering would match? * A possible enhancement might be to make ft:validation-errors sensitive to the widget context in which it is invoked, for instance an ft:validation-errors within an ft:group would only aggregate the validation errors for widgets within that fd:group. We might want a way to override this though, and/or add an attribute (@context-path or something) to allow authors to specify the context widget. Thoughts? --Jason
