cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [cforms] fi:validation-errors in AJAX mode
Date Tue, 02 Aug 2005 09:23:57 GMT
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.



Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message