MW> It seems blatantly obvious to me that all conversion should happen MW> before any validation occurs. I think the current situation is MW> ridiculous and it's the root of why multi-field validation is so MW> screwed up to begin with. MW> See my previous comment=E2=80=A6 The question is: when this will MW> change. JSF 2.0 would be the right version. But I guess it's MW> already too late for such a fundamental change in the lifecycle MW> & separating conversation and validation. DA> It won't be JSF 2.0. Hopefully JSF 2.1 or sooner. NT> My vote goes to change this in JSF 2.1 by changing the way this is NT> handled by separating convertion and validation into two separate steps NT> (thus effectivly adding an additional step into the jsf lifecyle). DA> 1) Validation is happening in two places, once before model update DA> and once after, which confuses the user (they have to submit the DA> form twice to get all the validation errors) DA> 2) Inter-component validation is very complex and in some cases, not DA> possible without a lot of code stealing from the implementation DA> There are two root causes that have been identified: DA> 1) The assumption that validation should happen before model update, DA> thus making it possible to only partially use Bean Validator (and DA> the like) DA> 2) The coupling of conversion and validation in the life cycle (each DA> component is converted then validated in turn) DA> The second root cause is easier to solve than the first. Norbert and DA> I (perhaps others as well) believe everything would get a whole lot DA> simpler to start with if conversion was completed before validation DA> began so that when inter-component validation is attempted, all DA> values are in their converted state. PM> However this does introduce another "layer" - if conversion fails then PM> the no validators get run. Yes, that is true. I'm ok with this, but let's enumerate some backwards compatibility concerns. Currently the responsibility to initiate conversion is assigned to the UIInput.validate() method. Within that method, getConvertedValue() is called and the result is kept as a local variable which is passed to validateValue(). If we were to break this process into two separate lifecycle phases, we'd need some place to store the return from getConvertedValue() so that it can be accessed in validate() and passed to validateValue(). For this reason, I suggest we introduce a new protected "convertedValue" property and rigidly define the lifetime of this property. Note that it is ValueHolder that has the owning reference to the Converter. Therefore, I think we would need to have a processConversions() method on UIComponent, which we'd override on UIOutput to call a new convertValue() method. We'd move getConvertedValue() up from UIInput to UIOutput, and make convertValue() call it. PM> I believe to address both (1) and (2) we have to address this problem PM> anyway, as I would be very unhappy to end up with the worst case PM> scenario of: conversion failures -> return to user -> property PM> validation failures -> return to user -> cross component validation -> PM> return to user -> business logic error -> return to user -> render PM> next page. Pete, I don't see any way around having to go back to the user. I think first class client side validation can make this painless. Of course, we would still do the same validation on the server side. I think this could possibly be accomodated with a JSF specific JSR-303 annotation that is somehow indicated at the point of the constraint declaration. Something like public class UserBean { @Email @AlsoRunOnClient string email; public String getEmail() {...} public void setEmail() {...} } We'd have another bunch of stuff in the jsf.js file, but that's why we have staked it out, so we can add stuff to it. PM> I think we should also check that everyone agrees that cross-component PM> validation should provide first class support for BOTH (a) custom JSF PM> validators AND (b) model based. My vote would be to require (b) and PM> make a best effort at (a), but I suspect other disagree ;-) I think we should go for (b) and forget (a). AS> solve. For example, I think we should take a look back at use cases AS> like this: AS> http://www.jroller.com/robwilliams/entry/jsf_multi_field_validation_not AS> And try to figure out which solution (or solutions) would have helped AS> the obviously frustrated user solve the problem in the least painful And there's also this http://insights2jsf.wordpress.com/2009/08/06/multivalidator-component-all... I like this approach for its practicality. Ed -- | ed.burns(a)sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/