Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42EF3BAD.3070706@apache.org>
Date: Tue, 02 Aug 2005 11:23:57 +0200
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [cforms] fi:validation-errors in AJAX mode
References: <20050730110115.56812.qmail@minotaur.apache.org>
 <42EE229A.102@anyware-tech.com> <f19abd484ea2509a96e3df9fb7a9026c@apache.org>
 <42EE2A60.1050106@apache.org> <edde4204adf6ec91f08dae46a532cd6f@apache.org>
 <42EE33E7.2080500@apache.org> <1122923964.16625.9.camel@jjohnston>
 <1122928672.16625.49.camel@jjohnston>
 <9a0f60ba562b599ffc6ff69432a04842@apache.org>
In-Reply-To: <9a0f60ba562b599ffc6ff69432a04842@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.


Yup.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director