> Mike Kienenberger wrote: > > It is possible to simulate a custom required validator > > (see http://wiki.apache.org/myfaces/OptionalValidationFramework), but > > it isn't going to help you in any way
On 4/4/06, Richard Wallace <[EMAIL PROTECTED]> wrote: > How so? No matter what you do, you're still going to have to write java code that consolidates messages to display them. It's just as easy to consolidate FacesMessages as it is to consolidate some custom data type that you'd conceivably generate in a custom required validator. And the required validator controller component is slow due to the fact that it has to walk the entire component tree a couple times in order to fire the validation and then adjust the component validation state. > > Instead, you want to generate standard required validation messages, > > then create a custom renderer for the messages component that > > consolidates each of these messages into something else, probably by a > > specific id pattern. I also think you'd be better off extending the > > existing messages renderer than creating it yourself. > Sounds like a hack to get around a poor validation system. In this case, it's not the validation system that's the problem. It's the displaying of validation errors. The system logged them as FacesMessages, so you simply need to change how they're displayed. The messages component renderer is the place to change that. > Is there any > way to completely replace the JSF validation process with something more > flexible? I mean, honestly, this is a pretty simple use case that is > extremely difficult to implement. Sure. JSF is completely pluggable, so you could create your own lifecycle factory and create a lifecycle that skips or replaces the process validation phase. However, coming up with something "more flexible" is going to be a task. You're also going to probably break components that expect a processValidation phase to occur. It'd be interesting to hear what you have in mind. I've yet to see any decent validation implementations. Before you get too far into it, take a look at subforms (talked about more below) as they solve some of the weaknesses of JSF validation. > I have to wonder why the required > attribute is treated as a special case as well. I think having the required attribute as a special case was an example of an implementation detail influencing the spec. I'm sure the idea is that if there's no value, then there's no point in validating it. But unfortunately, it's an ugly special-case that you have to constantly work around since it's not treated as a "real" validator but is instead implemented separately as part of every component. > Validation in JSF seems > to be just a mess. I really like JSF overall, but anytime I start > thinking about doing any validation I have to take a couple of shots of > whiskey and bite down on something hard to try and forget about the pain. I agree :) It's why I tried to write the OptionalValidationFramework :) However, I think using the MyFaces sandbox subform component or the ADFFaces subform component is probably a better solution than OVF. For one thing, OVF doesn't work well with vanilla JSF 1.1 (requires facelets + 1.1 or requires 1.2). I don't think subform components will help with this specific situation, but they'll be helpful in other partial validation situations.
