validators on form components that don't directly get input from the request

[Eelco Hillenius <ee...@gmail.com>]

Hi,

I have an interesting issue to be solved, which is the fact that the
way our form(component) processing currently works pressumes that all
form components get their input from request parameters. But a
component like DateTimeField (or any FormComponentPanel probably)
doesn't work like that, as it's nested children receive the actual
input, and DateTimeField just combines that.

However, it's a bit of a pitty that it's not possible (or more
preceise, it's a noop) to add say a DateValidator to DateTimeField. I
can think of various hacks, including very specific ones for the
DateTimeField, but so far nothing I really like.

Can anyone think of an elegant, generic way that components such as
DateTimeField can work nicely together with validators (and elegant
imo is *not* passing validators to e.g. the date field, ignoring the
time fields). It's quite an ugly limitation, so any ideas are more
than welcome.

Eelco

Re: validators on form components that don't directly get input from the request

[Igor Vaynberg <ig...@gmail.com>]

On 5/1/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > protected Object convertValue(String[] value) {
> >   // we can ignore passed in value, but what we do instead is create an
> > object based on child components
> >   LocalTime time=(LocalTime)timepicker.getconvertedinput();
> >   DateTime datetime=time.withDate
> > ((LocalDate)datepicker.getConvertedInput());
> >   return datetime;
> > }
>
> Yeah, this was the direction I've been thinking as well. What I didn't
> like about this is that the String[] argument is passed in - even
> though it can't be ignored it just doesn't look great, and like you
> say...


yep. the question is do we want to change the api? it is easy, that array
comes from getInputAsArray(),  no magic.

> you have to do a bit of extra chicking still because validatation hasnt
> yet
> > passed on the date and time pickers, only coversion. this can be
> improved
> > imho. we can do conversion+validation sequentially in a single pass
> instead
> > of in multiple separate passes.
>
> it's only half way done. Imho, even would be even cooler if model
> updating would have been done for those kids as well, so that I don't
> have to know about converted input (imo an internal method) but can
> just get the model objects directly.


no no no. you cannot update the model unless you know the whole thing is
valid! this is because you dont know how the models are constructed. there
is no guarantee that formcomponentpanel will encapsulate the model somehow,
it could just pass its own model to its children. and if we do what you
propose that some parts of the root form model can get updated even though
the form is not valid - a big no no.

Which makes me think of something... what should we do if anything
> fails (conversion, validation) for child components. You typically
> want to process siblings like we've always done for formcomponents
> that are not nested in other formcomponents, but I don't think we
> should visit deeper (go up the hierarchy as we traverse post order)
> for any of the steps (conversion, validation and updatemodel) when one
> of them fails. WDYT?


that is already done. formcomponent.isvalid() now checks its children as
well, so if something inside fails  ancestors are not checked.

> i can probably make this change soon.
>
> Excellent! :)


done.

-igor


Eelco
>

Re: validators on form components that don't directly get input from the request

[Eelco Hillenius <ee...@gmail.com>]

> protected Object convertValue(String[] value) {
>   // we can ignore passed in value, but what we do instead is create an
> object based on child components
>   LocalTime time=(LocalTime)timepicker.getconvertedinput();
>   DateTime datetime=time.withDate
> ((LocalDate)datepicker.getConvertedInput());
>   return datetime;
> }

Yeah, this was the direction I've been thinking as well. What I didn't
like about this is that the String[] argument is passed in - even
though it can't be ignored it just doesn't look great, and like you
say...

> you have to do a bit of extra chicking still because validatation hasnt yet
> passed on the date and time pickers, only coversion. this can be improved
> imho. we can do conversion+validation sequentially in a single pass instead
> of in multiple separate passes.

it's only half way done. Imho, even would be even cooler if model
updating would have been done for those kids as well, so that I don't
have to know about converted input (imo an internal method) but can
just get the model objects directly.

Which makes me think of something... what should we do if anything
fails (conversion, validation) for child components. You typically
want to process siblings like we've always done for formcomponents
that are not nested in other formcomponents, but I don't think we
should visit deeper (go up the hierarchy as we traverse post order)
for any of the steps (conversion, validation and updatemodel) when one
of them fails. WDYT?

> i can probably make this change soon.

Excellent! :)

Eelco

Re: validators on form components that don't directly get input from the request

[Igor Vaynberg <ig...@gmail.com>]

this is already possible, and is very elegant!

all you have to do is something like this

protected Object convertValue(String[] value) {
  // we can ignore passed in value, but what we do instead is create an
object based on child components
  LocalTime time=(LocalTime)timepicker.getconvertedinput();
  DateTime datetime=time.withDate
((LocalDate)datepicker.getConvertedInput());
  return datetime;
}

and voila, validators and model is now populated with the datetime object
which is constructed from timepicker and datepicker child components.

you have to do a bit of extra chicking still because validatation hasnt yet
passed on the date and time pickers, only coversion. this can be improved
imho. we can do conversion+validation sequentially in a single pass instead
of in multiple separate passes. i can probably make this change soon.

-igor


On 4/30/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> Hi,
>
> I have an interesting issue to be solved, which is the fact that the
> way our form(component) processing currently works pressumes that all
> form components get their input from request parameters. But a
> component like DateTimeField (or any FormComponentPanel probably)
> doesn't work like that, as it's nested children receive the actual
> input, and DateTimeField just combines that.
>
> However, it's a bit of a pitty that it's not possible (or more
> preceise, it's a noop) to add say a DateValidator to DateTimeField. I
> can think of various hacks, including very specific ones for the
> DateTimeField, but so far nothing I really like.
>
> Can anyone think of an elegant, generic way that components such as
> DateTimeField can work nicely together with validators (and elegant
> imo is *not* passing validators to e.g. the date field, ignoring the
> time fields). It's quite an ugly limitation, so any ideas are more
> than welcome.
>
> Eelco
>