On Monday, September 15, 2003, at 03:07 PM, Fabricio Voznika wrote:
>> 4.Since Cayenne imports Jakarta org.apache.commons.beanutils, there
>> is no need for a custom implementation of property reading in
>> Validator class. Just use BeanUtils.readSimpleProperty(..). But note
>> that for DataObjects, a special handling using
>> "CayenneDataObject.readNestedProperty(..)" is preferable since it is
>> *much* faster than reflection.
>
> BeanUtils returns only a string representation of the object :-(.
True.... This sucks indeed. OK... still Cayenne has something to offer:
...util.PropertyComparator. If it doesn't have all we need for
validation, I'd rather expand this class then create a duplicate
implementation.
> readNestedProperty() breaks object encapsulation (it's not calling
> the getter) and works only with properties defined in Cayenne.
> The idea of Validator is to add utilities methods for manual
> validation. There are only 3 method there now, but the idea it to have
> much more (checkLessThan, checkLength, checkDateFormat, etc)
Well, general methods are good for people who extend the validation
mechanism, and I am all for it. For specific validation of DataObjects
though we will have to use readNestedProperty() (1) for performance and
(2) this is the way Cayenne retrieves values for internal purposes
anyway, so if we are validating simple persistent properties this is
quiet appropriate. Since Validator class is simply a collection of
utility methods, CayenneDataObject.validateForSave() doesn't have to
use it. Besides in this context CayenneDataObject can always safely
call "this.readNestedProperty()".
>> An alternative to 3. and 4. would be using class generation to create
>> validateForSave for each class, but for now I am still unsure if this
>> is the way to go. Doing too many things via class generation is a
>> conceptual shift in Cayenne and requires more thought.
>
> I was afraid it would be costly to make the validations on the fly,
> but thinking more about it, it shouldn't be so bad I guess. I'll
> implement it and if it's bad you help me optimize it, ok?
Sure, bring it on ;-)
Andrus
This archive was generated by hypermail 2.0.0 : Mon Sep 15 2003 - 15:20:39 EDT