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 <[email protected]> > 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 >
