cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject Re: [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 Tue, 02 Aug 2005 07:58:46 GMT
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 Cei
Tech Blog:
Open Source Zone:
Wine & Food Blog:

View raw message