Hello Stephen, Comments inline.
~ Simon On 10/4/07, Stephen Friedrich <[EMAIL PROTECTED]> wrote: > > Thanks a lot, Simon! > > There's a looming dead line, so currently I care more for the > "gets-the-job-done" than for "wow, thats' great!". > > I got your first solution working - and even understand it, now that it > gave me somewhere to start looking. ;-) > (I am not using binding: In my validator, I simply traverse from the > hidden > input field (to which I attached my custom validator) up to the form and > down to the table.) > > Something along the line of "coherence validators" would be great. As long > as you have multiple > "non-collection" fields, you always get along ok by attaching a single > validator to the last field and accessing the other value > programmatically. > But when using a table for example it really gets kind of ugly. > > I do not really understand your proposed solution: > I see how you specify to which fields a coherence validator applies, but > how does that validator access the fields at runtime? After all there > still > is only a single "stamp" component. Since a validationGroup (which is really a validator) item is added to the component, it's called for every rows (like a normal validator would). However, that special validator only push the current value (received in the validate method) into a request map using clientId as a key to be later used by the coherenceValidator Also I do not understand your comment about ordering: "if the fields are > not one after another in the page". Err, how other than "one after > another" > can they be? Imagine a strange use case where you have: field 1 field 2 field 3 Now, for some obscure reason, you want to make sure field1 > field3 > field2. Then my solution won't help you much since a map is not ordered. And even if it was, the ordering would follow the order of appearance in the page, thus 1 -> 2 -> 3.
