cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <jason.johns...@Intrado.com>
Subject [cforms] fi:validation-errors in AJAX mode (was: svn commit: r226493 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/resources/forms-field-styling.xsl)
Date Mon, 01 Aug 2005 20:37:52 GMT
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

Mime
View raw message