cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject [cforms] Uniqueness of IDs and ValidationAware forms
Date Mon, 06 Jun 2005 05:33:50 GMT
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>> Reinhard Poetz wrote:
>>> Sylvain Wallez wrote:
>>>> Now there's also the little-known <ft:validation-error> template 
>>>> instruction that outputs the validation error or any given widget. 
>>>> This can be a good replacement of the message widget, and would 
>>>> allow non-visual widgets to be ValidationAware.
>>> good idea! I implemented the ValidationErrorAware interface in Form 
>>> and Repeater. I fear this will not work in Ajax mode as the errors 
>>> are not reported to the client.
>> uups, sent this mail to quickly. I wanted to add that I don't have the 
>> time to fix this ATM as I would have to dive into the Ajax 
>> implementation to find out how to make this possible.
> The main principle of the Ajax stuff is that each part of the page that 
> can be updated asynchronously (not necessarily a widget) must be fully 
> contained in a tag (span, div, input, whatever) with a unique id. In the 
> case of widgets, this id is the value of widget.getRequestParameterName().

ok, sounds easy

> We therefore need a distinct id for validation errors, which can be e.g. 
> {widget.requestParameterName}.$error, which uses the same $-prefix 
> convention as Java bytecode for synthetic names (those generated by the 
> program).

this means I have to register the errors in the form object in a similar way as 
it is done with widgets (addWidgetUpdate() and getUpdatedWidgets()) and enhance 
the generateValidationError() and flushRoot(ValidationError error) methods so 
that they send the bu: tags with the replacement information. Right?

> Update of the validation error is then linked to a change of its 
> associated widget. For now, change detection is a boolean thing (changed 
> / unchanged) but we may go to something more fine-grained in the future 
> (e.g. value changed / error changed / selection list changed etc).

your explanations have made me think of the uniqueness of names. As long as you 
only have forms of a different type on the page the names are unique, at least 
if you set the id attribute in the form tag of the form definition.

But if you use the same form definition more than once, you'll run into 
problems. These become obvious if you run the same form in two different 
portlets. If the form uses a field of type "date" the date chooser is confused 
because there are two fields with the same id. IIUC this must be a problem for 
Ajax too. Right?

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}



Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:

View raw message