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
>