cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [CForms] Cardinality check for repeater
Date Wed, 28 Sep 2005 10:11:04 GMT
Thomas Lutz wrote:

> Hi list !
>
> A recent discussion on the users list [1] showed that there is 
> interest in implementing a minimum/maximum number of rows check in 
> CForm's repeaters.
>
> Jorg Heymans submitted a patch to bugzilla [2], that adds the 
> minimum-size and maximum-size attributes to the repeaters definition, 
> and contains a sample on disabling the controls with jx macros...
>
> To complete this feature validation should be added. So, if the 
> current size is lower or greater than the specified values, a 
> validation message should be displayed, and the add-row or remove-row 
> buttons should be disabled.
>
> Now the question for the CForm gurus :-):
>
> What's the best way to do it ?
>
> We've found two scenarios so far:
> -try to add the validation in the validate function of Repeater.java 
> and disable the controls in Repeater.java
> -write a validator class (like the ones described in [3]), set a flag, 
> and leave enabling/disabling of the controls to the presentation layer 
> (the forms-field-styling.xsl, or jx macros..?)
>
> I'll try to implement it, but some advice where to start, and what to 
> touch would really be great, as am I still a CForms greenhorn :-).


Hmm... There are different issues here:

Validation:
We can extend the <fd:range> or <fd:value-count> validators so that they 
can validate a repeater. But the issue then is that a repeater has no 
way to automatically display its error, and therefore it's up the 
template writer not to forget to add a <ft:validation-error> somewhere.

Enabling/disabling controls:
This is different from validation, as the controls must be disabled to 
ensure that we don't go outside of the specified constraints. This 
cannot be implemented as a validator (which is called too late in the 
process), and requires the concept of min and max rows to be built into 
the repeater itself.

I would go for this second solution, as it provides a better user 
experience (you can't do the action, rather than having to correct it 
afterwards), but this requires some changes to the repeater code:
- add min-rows/max-rows properties
- add support for repeater listeners, so that repeater-actions and 
row-actions can register themselves on the repeater and automatically 
change their state according to the size of the repeater.

Sylvain

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


Mime
View raw message