[ExtVal] PropertyValidationInterceptor and BeanVal Model validation

[Rudy De Busscher <rd...@gmail.com>]

hi,

I have following test scenario:
A class with 3 properties that are shown on a screen and were a
BeanValidation ModelValidation annotation is placed on the type.

@MyModelValidation(message = "{person.notallowed}")
@BeanValidation(modelValidation = @ModelValidation(isActive = true))

It is a bit difficult to describe the situation but I give it a try.  I hope
I don't loose too many people during the explanation.
The *BeanValidationMetaDataExtractorInterceptor *adds for every property (3
in my case) a *ModelValidationEntry *to the storage. As component it places
the different properties in the *ModelValidationEntry *.
A custom *PropertyValidationInterceptor*, which is registered in the system,
receives a before and after event for each property in the bean which is
placed on the screen.  This is from the Validation phase where the
validation of the fields itself is performed and thus normal.

Then the *ModelValidationPhaseListener *kicks in (in the after update model
phase). The custom registered interceptor receives now for each
*ModelValidationEntry
*a before event, with the UIComponent as a parameter but with the model
object as converted object.
After the first before event, the actual validation by the JSR303 provider
is performed, and later on blocked by keeping the validated object in a Map
(together with the Group for which the validation took place.).
The after event of the interceptor is finally called with no parameters
(except the facesContext) at all.

So my point is:

In case of a modelValidation, the use of a validator interceptor is not very
functional and confusing.
- The before method is called twice for each component, once with the actual
converted object from the screen and once with the model object.  But there
is no indication of what kind of ModelValidation will be performed and thus
difficult to determine if the validation should continue.
- The after method is called but no info about was is done is available.

Since PropertyValidationInterceptor is marked API, we can't change it to
have more parameters that can be used in case of a model validation.
So I think we need a *ModelValidationIntercepter *with parameters that can
be used to make some decision of what to do (before method to block the
validation and after to do some additional things.)
One of the things the after method should receive is the list of
ModelValidationResult objects, so the interceptor can change these.

Too late for x.x.3 , I guess ??

PS I came to this issue when I tried to create a beanValidation version of
the transactional model validation light addon.  Need to test it more but
commit to sandboxos890 will follow.


regards,
Rudy

Re: [ExtVal] PropertyValidationInterceptor and BeanVal Model validation

[Gerhard Petracek <ge...@gmail.com>]

hi rudy,

to keep it short - it isn't too late for r3. i'll start with the first steps
of the release (which have to be done before the release-vote) as soon as
leonardo is available. so if we find a nice solution for it without api
changes, it might be possible to include it in r3. with a workaround it's
possible (right now). i didn't publish it so far because it's just a
workaround and not that nice. however, it's possible to use it in an add-on.

regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2010/2/26 Rudy De Busscher <rd...@gmail.com>

> hi,
>
> I have following test scenario:
> A class with 3 properties that are shown on a screen and were a
> BeanValidation ModelValidation annotation is placed on the type.
>
> @MyModelValidation(message = "{person.notallowed}")
> @BeanValidation(modelValidation = @ModelValidation(isActive = true))
>
> It is a bit difficult to describe the situation but I give it a try.  I
> hope I don't loose too many people during the explanation.
> The *BeanValidationMetaDataExtractorInterceptor *adds for every property
> (3 in my case) a *ModelValidationEntry *to the storage. As component it
> places the different properties in the *ModelValidationEntry *.
> A custom *PropertyValidationInterceptor*, which is registered in the
> system, receives a before and after event for each property in the bean
> which is placed on the screen.  This is from the Validation phase where the
> validation of the fields itself is performed and thus normal.
>
> Then the *ModelValidationPhaseListener *kicks in (in the after update
> model phase). The custom registered interceptor receives now for each *ModelValidationEntry
> *a before event, with the UIComponent as a parameter but with the model
> object as converted object.
> After the first before event, the actual validation by the JSR303 provider
> is performed, and later on blocked by keeping the validated object in a Map
> (together with the Group for which the validation took place.).
> The after event of the interceptor is finally called with no parameters
> (except the facesContext) at all.
>
> So my point is:
>
> In case of a modelValidation, the use of a validator interceptor is not
> very functional and confusing.
> - The before method is called twice for each component, once with the
> actual converted object from the screen and once with the model object.  But
> there is no indication of what kind of ModelValidation will be performed and
> thus difficult to determine if the validation should continue.
> - The after method is called but no info about was is done is available.
>
> Since PropertyValidationInterceptor is marked API, we can't change it to
> have more parameters that can be used in case of a model validation.
> So I think we need a *ModelValidationIntercepter *with parameters that can
> be used to make some decision of what to do (before method to block the
> validation and after to do some additional things.)
> One of the things the after method should receive is the list of
> ModelValidationResult objects, so the interceptor can change these.
>
> Too late for x.x.3 , I guess ??
>
> PS I came to this issue when I tried to create a beanValidation version of
> the transactional model validation light addon.  Need to test it more but
> commit to sandboxos890 will follow.
>
>
> regards,
> Rudy
>