Hi Remi
and thanks for your answer!
I can see I'm not the only that faced that problem!
Like you said, that forces the dev to think about the validation
outside the ActionBean...
Wouldn't that be a problem if you only want to validate on one of them
and not others?
I was in the source code of the validation process of Stripes jsut now
and I saw that :
public class DefaultValidationMetadataProvider implements
ValidationMetadataProvider {
[........]
protected Map<String, ValidationMetadata> loadForClass(Class<?> beanType) {
[......]
// add all sub-properties referenced in @ValidateNestedProperties
if (nested != null) {
Validate[] validates = nested.value();
if (validates != null) {
for (Validate validate : validates) {
if (validate.field() != null &&
!"".equals(validate.field())) {
String fullName = propertyName +
'.' + validate.field();
if (meta.containsKey(fullName)) {
log.warn("More than one nested
@Validate with same field name: "
+ validate.field() + " on
property " + propertyName);
}
meta.put(fullName, new
ValidationMetadata(fullName, validate));
}
else {
log.warn("Field name missing from
nested @Validate: ", clazz,
", property ", propertyName);
}
}
}
}
[....]
Which is exactly what you overrided. But wouldn't it possible to do
something like :
// add all sub-properties referenced in @ValidateNestedProperties
if (nested != null) {
Validate[] validates = nested.value();
if (validates != null) {
for (Validate validate : validates) {
if (validate.field() != null &&
!"".equals(validate.field())) {
String fullName = propertyName +
'.' + validate.field();
if (meta.containsKey(fullName)) {
log.warn("More than one nested
@Validate with same field name: "
+ validate.field() + " on
property " + propertyName);
}
meta.put(fullName, new
ValidationMetadata(fullName, validate));
}
else {
log.warn("Field name missing from
nested @Validate: ", clazz,
", property ", propertyName);
}
}
ValidateNestedProperties[] nestedProps =
nested.nestedProps();
for (ValidateNestedProperties current :
nestedProps) {
[yada yada]
}
}
}
where in [yada yada] a call to a recursive method could be made ...
and of course modify ValidateNestedProperties annotation to match
that...
What decisions made you code NestedValidationMetadataProvider that way?
There has to be something that I don't see.... but what?
Regards,
Sam
On Thu, Mar 10, 2011 at 7:08 PM, VANKEISBELCK Remi <r...@rvkb.com> wrote:
> Hi Samuel,
>
> Apparently, you're right : @ValidateNestedProperties references @Validate,
> not @ValidateNestedProperties again...
>
> If this can help you, I have a "workaround". I'm using a custom
> NestedValidationMetadataProvider in Woko, that allows you to write
> validation annotations inside your POJOs, and have Stripes use them. Stuff
> like this :
>
> class MyAction implements ActionBean {
> ...
> @ValidateNestedProperties([])
> MyClass myProp
> ...
> }
>
> and
>
> class MyClass {
> @Validate(required=true)
> String foo
> }
>
> The basic idea is that when an action bean property's marked with an empty
> @ValidateNestedProperties, the NestedMetadataValidationProvider recurses
> into the property and applies it's validation info.
> With the example above, request parameter 'myProp.foo' has to be provided.
>
> Of course, the provider can recurse to any depth, which means you can even
> write this :
>
> class MyClass {
> @ValidateNestedProperties([])
> MyOtherClass other
> }
>
> class MyOtherClass {
> @Validate(...)
> String bar
> }
>
> Last, the metadata provider will favor the run-time type of the property.
> You can even write this :
>
> class MyAction implements ActionBean {
> ...
> @ValidateNestedProperties([])
> Object prop
> }
>
> Then the validation metadata provider will (if prop ain't null of course)
> get the runtime type of the instance referenced by 'prop' and introspect for
> validation errors.
>
> I tend to think this behavior should be standard in Stripes. Yeah, I know,
> you shouldn't have dependencies of your Domain Model on Stripes, it's
> baaaad...
> But I often have "collaborators" to my actions that are not part of the
> domain model. They're UI objects. And I don't always know the runtime type
> of the action's properties (hey, inheritance...).
> So I'd like to annotate whatever class I want with @Validate, and if it's
> reachable by the action bean at request processing time, then have Stripes
> validate everything. Feels natural, doesn't it ?
>
> Last, this "nested validation metadata provider" allows for better
> factorization the validation logic : you can delegate to action
> collaborators, and the validation rules will depend on the objects
> referenced by your action bean.
>
> Anyway, in case you're interested :
> https://github.com/vankeisb/woko2/blob/master/stripes-plugins/src/main/java/woko/actions/nestedvalidation/NestedValidationMetadataProvider.java
>
> I'd be happy to have the community feedback on this btw...
>
> HTH
>
> Cheers
>
> Remi
>
> 2011/3/10 samuel baudouin <osenseij...@gmail.com>
>>
>> Hi all!
>>
>> I was wondering : is it possible to do nested validation to more than one
>> level?
>>
>> Lets say I want to validate the name of an Account contained in a
>> WebModel,
>> for instance : getWebModel().getAccount().getName()
>>
>> I know the annotation @ValidateNestedProperties makes it possible to
>> validate one level , but apparently it is impossible to go deeper...
>>
>> I think i ll fall back to validation methods but that would have been
>> nice, no?
>>
>> Any idea?
>>
>> Cheers
>> --
>> Samuel Baudouin
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
--
Samuel Baudouin
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
