Re: Validation for table column?

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.

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?

Thanks Simon, that makes it clear.

I think nothing special should be done about ordering:
 > Then my solution won't help you much since a map is
not ordered.
That just not true: The map makes no assumptions about
ordering.
A HashMap is not sorted, a TreeMap is, a LinkedHashMap is
ordered
by insertion sequence.
So any specific validator might use what is right for it.

Concerning the regular validator vs. coherenceValidator:
I think your solution uses too much boilerplate.
Can't we get it working with just a single validator, that
implements an interface CoherenceValidator? It would be
called
for each single field and then after the last field the
single
method defined in in the interface validateCoherent() is
called
automatically?
Hm, that would not allow to use the same type of validator
for two
different sets of fields in the same form.
Have to chew on that a little...



Simon Lessard wrote:
> Hello Stephen,
> 
> Comments inline.
> 
> ~ Simon
> 
> On 10/4/07, *Stephen Friedrich* <trinidadeekboom.com 
> <mailto:trinidadeekboom.com>> 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.
>