>From the jsr-314-comments mailbox comes this discussion between myself and Mathias Werliz about inter-component validation. Unfortunately the discussion progressed outside of the mailinglist, so the post below is the aggregate of the individual messages. If there is confusion we can summarize the discussion up to this point and continue the discussion on each individual point.

---------- Forwarded message ---------- From: Dan Allen <dan.j.allen(a)gmail.com&gt; Date: Thu, Jul 9, 2009 at 2:09 PM Subject: Re: inter-component and form-level validation To: "Werlitz, Mathias" <werlitz(a)adesso.de&gt; Cc: jsr-314-comments(a)jcp.org On Thu, Jul 9, 2009 at 11:36 AM, Werlitz, Mathias <werlitz(a)adesso.de&gt; wrote: Sorry for the late response. I’m very busy on a customer project at the moment, analysing JSF 1.2 (view state) and Facelets memory consumption on IBM Portal 6.1. I agree that there are two basic approaches to solve multiple-field / form-validation: 1. model based validation after the update model phase and 2. validating the converted values of multiple components In both cases there should be an easy way to assign the proper validation message to the originating input component or group of input components. With complex forms including inputs within naming containers like <h:dataTable> this may become quite complicated. Flattening the properties of the object graph for JSR-303 model validation does not seem to be a good idea in this case. I realize that JSR-303 isn't going cover every case. I must admit to still being the fence on how to best handle the situation you are citing...meaning can I do it comfortably with JSR-303 or not? I think a solid use case would help us test the limits. Well I simplified a test case – I’m unsure that this is easily done with JSR-303. Image a form with a master date and several additional dates. The number of the additional dates is dynamic – will be configured by the user (added and removed) or determined by the server. For simplicity there is only one multi-field validation rule: all additional dates must be after the master date. The view would look something like this (note: the list of additional dates is a list of a custom bean that stores the date and maybe additional data for every entry): <h:input id=”masterDate” value=”mybean.masterDate” /> <h:datatable value=”mybean.myAdditionalDates” var=”item” > <h:input id=”addtionalDate” value=”item.additionalDate” /> </h:datatable> This could be done with JSR-303. You can have a validation annotation on the array (or List) property holding the "after" dates and say that they must come after the master date property. But again, the limitation is that it has to happen after update model values. Earlier when I said you have to flatted your model, I didn't mean you couldn't use collections. You just can't easily validate a property on one class against a property on another. But pointing that aside, you could still accomplish w/ a regular JSF validator if all conversions happened before the validation phase. Then you just do something like: <h:input id="additionalDate" value="#{item.additionalDate}"> <x:validateAfter id="masterDate"/> </h:input> One downside of the model based validation is that the whole validation process is split up into two phases. That means the user may get the error messages in two bunches: first the errors of the validation phase and later the model errors. This can be quite confusing. The reality is, there are two validation phases in input-based applications. You simply cannot test some business validations if you don't have correct data to start with. I think the real point is to make sure that all input validation is handled together...and that business validation is really business validation. Having one date before another I agree is likely an input validation, not a business validation. Yes, that’s the point. At the moment JSF does make it very hard to do the input validation altogether. There will likely always be two steps. The question is, can we get those two steps right? To emphasize why there must be two validation phases, consider this case. You walk into an ice cream store and the employee asks you which flavor of ice cream you want. You say you want pizza. They say, "Sir, we don't have pizza, you have to pick and ice cream." Then you say that you want Heath ice cream. The employee says, sorry, we don't have that in stock. So the first is an input validation, the second is business. The employee couldn't have told you they don't have Heath ice cream in stock because the employee doesn't know what you want. It's not really that confusing. I agree with you, but in fact there are three steps where messages could be associated with an input field (convert, validation, business rules) and every step depends on the previous one. Well, one common requirement of our customers is: Display error messages as early as possible. Separating the validation into two phases makes this hard. Using good old Struts this example is no problem at all. That's because Struts effectively updated the model and then validated, moving all validation to the later phase. In JSF there is an understanding that values won't get assigned to the model unless they are valid syntax or type. You could throw that out the window and do all your validations after the update model values phase and get the same result. So we are questioning the fundamental guarantee of JSF (which, by the way, may need to be questioned). Well I think you got me wrong. The point is that in Struts you are able to store all the form data (as strings) in a form bean. You are responsible to make your own conversation. But because of that you are able to validate all input data including multi-field validation. On success you proceed to assign the values on your own to the real model. That’s not perfect. The only problem with JSF is that you don’t have this intermediate view on the form data where all converted values of the form is available altogether before deciding to move on to the update model phase. I think we are saying the same thing. JSF applies the values directly to the model by attempting to convert each value. Now, you could copy all properties to a model with string properties and essentially coerce JSF into skipping validation so that you can handle it yourself, but that really defeats a large goal of JSF. I like your idea of dividing converting and validation. I think JSR-303 model based validation is not sufficient. In the discussion with my college we had a similar idea as a workaround for JSF 1.2: We thought about a special custom validator added to all relevant input components that collects all converted input data from the components and the corresponding client ids/component instances. This also works fine with <h:dataTable>. The data could be collected with a Map or special validation-model bean. At the end of the validation phase another special form/multi-field validator (possible phase listener) is called with the collected data and invokes the validation logic. This way you get all converted data, components/client ids, the real model data is not touched at all and the whole validation is processed in one phase. It seems blatantly obvious to me that all conversion should happen before any validation occurs. I think the current situation is ridiculous and it's the root of why multi-field validation is so screwed up to begin with. See my previous comment… The question is: when this will change. JSF 2.0 would be the right version. But I guess it’s already too late for such a fundamental change in the lifecycle – separating conversation and validation. It won't be JSF 2.0. Hopefully JSF 2.1 or sooner. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan

I think we should also check that everyone agrees that cross-component validation should provide first class support for BOTH (a) custom JSF validators AND (b) model based. My vote would be to require (b) and make a best effort at (a), but I suspect other disagree ;-)

After a while, I got my early idea into a working prototype. The idea is coming from ValueObject pattern. In spate of that approach seems obsoleted for an application design, framework could implement that transparently to developer ( with some limitations, of course ). The scenario for for safe object validation is: 1) Object validator creates clone of model at the 'PROCESS_DECODES' phase. Custom resolver substitutes that cloned object for all references. Prototype implementation limits that substitution to components inside 'graphValidator' tag. That substitution is also active during 'process validators' phase. 2) per-components validators detect previvious case and should update cloned object with converted values passed to their 'validate' method. 3) at the and of 'processValidators' method 'graphValidator' component performs validation procedure on the cloned object. In the case of error validator should send error messages to the FacesContext and tell JSF to go to render response phase, as usual for any other validation errors. Cloned object will be discarded in any case, hence subsequent phases work with real model. In that scenario validation procedure can be performed on whole objects tree without affecting a real model. Open questions and limitations: 1) Clone procedure. In the prototype implementation, model beans should implements 'Cloneable' interface and application developer have to write 'clone()' method that properly clones all bean attributes, disconnect them from EntityManager ( or clean them from other frameworks, if necessary ). To omit that procedure from developers, validation framework ( or JSF library itself ? ) could perform that procedure. Anyway, that would work for plain JavaBeans only, where setter/getter methods do not perform actions that could affect other parts of application.

2) Detect cloned object in validators. It is simple in the case of direct references, but indirect referenced objects ( 'var' variables created by the dataTable, for example ) has no glue to distinguish original and cloned objects. Frameworks like Hibernate, Seam and JSR-299 wraps object by proxy, therefore they could properly clone beans with some marker interface. The small example is deployed onto our demo site http://localhost:8080/beanValidatorSample/pages/graphValidation.jsf . That simple example validates model that has per-property restrictions and limits total sum of property values.

On 07/28/2009 11:16 AM, Dan Allen wrote: > Okay, so to restate and reignite this discussion, let me seed the > topic. > > Several members of the EG and many other community members have > voiced > their concern that the validation mechanism in JSF is insufficient, > particularly in regard to inter-component validation, and needs to be > rethought/redesigned in a future release. I am deciphering two > concerns. > > 1) Validation is happening in two places, once before model update > and > once after, which confuses the user (they have to submit the form > twice > to get all the validation errors) > 2) Inter-component validation is very complex and in some cases, not > possible without a lot of code stealing from the implementation > > There are two root causes that have been identified: > > 1) The assumption that validation should happen before model update, > thus making it possible to only partially use Bean Validator (and > the like) > 2) The coupling of conversion and validation in the life cycle (each > component is converted then validated in turn) > > The second root cause is easier to solve than the first. Norbert > and I > (perhaps others as well) believe everything would get a whole lot > simpler to start with if conversion was completed before validation > began so that when inter-component validation is attempted, all > values > are in their converted state. > > The first root cause is much more challenging because if a value > cannot > be converted, and you continue into validation, you run the risk of > undefined behavior. I suppose you could say that a value which > could not > be converted results in a null value being assigned with a > FacesMessage > registered. But are two attempts to submit the form that result in > different validation messages really a bad thing. If you enter a > bogus > number in a number field, the form will yell at you that it cannot > proceed without a number. When you enter a number, it may then turn > out > to be out of range, and that to me is a logical progression. > > So the floor is open to discuss a general model for handling > validation. > Please cite use cases and case studies if necessary. We simply cannot > let another JSF revision go by without there being a general > agreement > that validation is sufficient for the development of web > applications. > > -Dan > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan

Hi guys, If you want my 2c as well: 1) unifying validation into one step is gonna be hard to do for JSF 2.1. 2 reasons for this: a) Alex's suggestion might work, but not for all types of model objects, and it adds a big overhead to applications - not sure we want to do this. b) Additionally, there is often a reason for not having validation in one place at all, exactly for the reasons that you, Pete, outlined as reasons for having them in one location: a lot of the validation can be done client-side, so the user has minimal waiting time for the validation results, some more can be executed on the server without back-end interaction, which again reduces waiting-time, and for the rest there is no chance - you will have to call some back-end service before you know what the results are, and have maximum waiting time and performance overhead. If you want to have minimal waiting time for users and try to keep them as concentrated as possible, you can never expect to have all validation in one location, instead you should choose carefully where to execute your validation. 2) I do think you guys are right: either adding a cross-component validator or separating out conversion and validation in two steps is the way to go. My +1 for either of these approaches. regards, Martin On 8/3/09, Pete Muir <pmuir(a)redhat.com&gt; wrote: > Hi Alex, > > Interesting idea :-) > > On 29 Jul 2009, at 23:24, Alexander Smirnov wrote: > >> After a while, I got my early idea into a working prototype. The >> idea is coming from ValueObject pattern. In spate of that approach >> seems obsoleted for an application design, framework could implement >> that transparently to developer ( with some limitations, of >> course ). >> The scenario for for safe object validation is: >> 1) Object validator creates clone of model at the 'PROCESS_DECODES' >> phase. Custom resolver substitutes that cloned object for all >> references. Prototype implementation limits that substitution to >> components inside 'graphValidator' tag. That substitution is also >> active during 'process validators' phase. >> 2) per-components validators detect previvious case and should >> update cloned object with converted values passed to their >> 'validate' method. >> 3) at the and of 'processValidators' method 'graphValidator' >> component performs validation procedure on the cloned object. In the >> case of error validator should send error messages to the >> FacesContext and tell JSF to go to render response phase, as usual >> for any other validation errors. Cloned object will be discarded in >> any case, hence subsequent phases work with real model. >> >> In that scenario validation procedure can be performed on whole >> objects tree without affecting a real model. >> >> Open questions and limitations: >> 1) Clone procedure. In the prototype implementation, model beans >> should implements 'Cloneable' interface and application developer >> have to write 'clone()' method that properly clones all bean >> attributes, disconnect them from EntityManager ( or clean them from >> other frameworks, if necessary ). To omit that procedure from >> developers, validation framework ( or JSF library itself ? ) could >> perform that procedure. Anyway, that would work for plain JavaBeans >> only, where setter/getter methods do not perform actions that could >> affect other parts of application. > > Yes, this is a clear limitation BUT would work well for entities, > which IMO is the 80% case of what people are doing. > > Other challenges I see include performance (especially around all > that > cloning of a big object graph). > >> 2) Detect cloned object in validators. It is simple in the case of >> direct references, but indirect referenced objects ( 'var' variables >> created by the dataTable, for example ) has no glue to distinguish >> original and cloned objects. Frameworks like Hibernate, Seam and >> JSR-299 wraps object by proxy, therefore they could properly clone >> beans with some marker interface. >> >> The small example is deployed onto our demo site >> http://localhost:8080/beanValidatorSample/pages/graphValidation.jsf >> . That simple example validates model that has per-property >> restrictions and limits total sum of property values. > > Once Seam 3 is going, we should start to promote this a bit and get > some feedback... > > I will say again that I think that whatever we do with graph > validation should be extensively developed and prototyped in the > community before considering specifying it - we have nothing much > that > does this today. > >> >> On 07/28/2009 11:16 AM, Dan Allen wrote: >>> Okay, so to restate and reignite this discussion, let me seed the >>> topic. >>> >>> Several members of the EG and many other community members have >>> voiced >>> their concern that the validation mechanism in JSF is insufficient, >>> particularly in regard to inter-component validation, and needs >>> to be >>> rethought/redesigned in a future release. I am deciphering two >>> concerns. >>> >>> 1) Validation is happening in two places, once before model update >>> and >>> once after, which confuses the user (they have to submit the form >>> twice >>> to get all the validation errors) >>> 2) Inter-component validation is very complex and in some cases, >>> not >>> possible without a lot of code stealing from the implementation >>> >>> There are two root causes that have been identified: >>> >>> 1) The assumption that validation should happen before model >>> update, >>> thus making it possible to only partially use Bean Validator (and >>> the like) >>> 2) The coupling of conversion and validation in the life cycle >>> (each >>> component is converted then validated in turn) >>> >>> The second root cause is easier to solve than the first. Norbert >>> and I >>> (perhaps others as well) believe everything would get a whole lot >>> simpler to start with if conversion was completed before validation >>> began so that when inter-component validation is attempted, all >>> values >>> are in their converted state. >>> >>> The first root cause is much more challenging because if a value >>> cannot >>> be converted, and you continue into validation, you run the risk of >>> undefined behavior. I suppose you could say that a value which >>> could not >>> be converted results in a null value being assigned with a >>> FacesMessage >>> registered. But are two attempts to submit the form that result in >>> different validation messages really a bad thing. If you enter a >>> bogus >>> number in a number field, the form will yell at you that it cannot >>> proceed without a number. When you enter a number, it may then turn >>> out >>> to be out of range, and that to me is a logical progression. >>> >>> So the floor is open to discuss a general model for handling >>> validation. >>> Please cite use cases and case studies if necessary. We simply >>> cannot >>> let another JSF revision go by without there being a general >>> agreement >>> that validation is sufficient for the development of web >>> applications. >>> >>> -Dan >>> >>> -- >>> Dan Allen >>> Senior Software Engineer, Red Hat | Author of Seam in Action >>> Registered Linux User #231597 >>> >>> http://mojavelinux.com >>> http://mojavelinux.com/seaminaction >>> http://in.relation.to/Bloggers/Dan > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces