Mike Kienenberger wrote:
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.
I guess you're right about the FacesMessages. The only thing I'm not
sure about is how to differentiate the messages I would want to
consolidate from messages that I want to display as is.
Another thing that I find a little annoying is that you either have
messages tied to a component or global to the page. You can't have
messages tied to a form.
And, of course, one of the biggest pains is customizing messages on a
per component basis. What I want is to be able to set the message to be
displayed for a specific instance rather than for all types of that
component across the application.
I don't know, maybe the solution to my problem is to just have the
validation done in my backing bean. The thing is that that seems to be
the solution to a lot of my validation use cases. In fact, I don't
think I've run into a single real world use case where the standard JSF
validation works.
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.
But how do you differentiate the messages to be consolidated from those
that shouldn't be?
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'm not sure of exactly what I'd do. At the moment I'm thinking that
the three things that I'd really like to see are more customizable
messages, required being a child element rather than a component
attribute, and for messages tied to forms in addition to global and
component messages. I was probably being a little extreme when I said
"completely replace". I was just on a bit of a rant cause I've spent to
much time banging my head against the wall trying to figure out the best
way of doing things with 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.
The subform components definitely look like a good step. It's
definitely one thing that I should have included in my list of wants for
the JSF validation system.
Rich
