Hi Martin!
> Well, the thing is that a merge is way off on the timeline.
> And Cagatay has something right now, why not take it in?
No, I didnt meant to NOT take Cagatys work now. In fact I'd love to see
it imported soon. Its just the converter stuff I was thinking about.
But now I also think we should put our hands on the converter stuff,
just, as far as I can see, in Trinidad they implemented a real client
validator with getAsObject and getAsString - to say the truth, I dont
like this.
If we say a converter has also a role as validator (I dont like this
idea too, but its by their nature that they do validation) I would love
to see them simply use the same ClientValidator interface than the
normal validator - On client side we just would like to validate and NOT
to convert in first place.
Mario,
Two reasons why you really want both methods.
(1) Validators should operate on typesafe objects in JS,
just as they do in Java. Otherwise, how could you ever
write a client validator for DateRangeValidator without
duplicating the formatting knowledge of the converter?
Therefore, Converters and Validators *aren't* just the same
thing in JS. You need to first call the Converter (if present),
then call all the Validators with the converted value.
(2) It is very useful to support getAsString() on
Converters in JS, because you can write a Converter that
supports multiple input formats, but canonicalizes to
the preferred format automatically.
(Public APIs in Trinidad generally received quite a lot of team
design effort, so it's usually the case that we *did* have
a reason for designing things the way we did.)
-- Adam
Later, when we see that we really need a client side converter we can
implement this stuff too, we dont need it for date and number converter,
the possibility to check onkeypress is much more important.
I think the client side converter approach isnt really that usable - how
do you convert a complex (maybe serialized) java object?
So +1 for allowing the ClientValidator interface on the converter too.
Ciao,
Mario
