FAQ
I've got 2 forms that I'm trying to do validation on. One form is an
assessment form, where the user needs to answer each question. For the
validation if a user doesn't enter a response, we want error messages at
the top of the page that say:

Questions 1, 3, and 7 have not been answered.

So, I've been thinking about what the best way to do that is. The best
thing that I can think of is to not use the required attribute and
instead use a custom required validator to put some error object in a
form specific list of validation errors. Then have a JSF component that
is similar to the messages component - it shouldn't extend it because I
want form specific validation not page specific - that checks if there
are any errors in the validation error list and creates appropriate
message(s).

A default implementation of the new messages component could act just
like the existing JSF validation and just pump out messages from
resource properties for the type of control being used. Someone that
wanted more control over the error messages could create a custom
subclass of the messages component that creates one or more messages in
the format they want. So, for my case, instead of having something like:

Question 1 has not been answered.
Question 3 has not been answered.
Question 7 has not been answered.

I can condense it into something more user friendly like at the
beginning of this message.

The second form I'm trying to work with is a user registration form. On
this form the user either enters a certificate number that will allow
them to sign up or they enter their credit card information. Basically,
if the certificate is there then the credit card information doesn't
matter. But, if the certificate isn't present then the credit card
information is required. How should I handle this scenario? Just add
the extra validation code in my backing bean so that when the form is
submitted it does all the checking? What do you all think?

Thanks for the input,
Rich

Search Discussions

  • Mike Kienenberger at Apr 4, 2006 at 9:53 pm

    On 4/4/06, Richard Wallace wrote:
    For the
    validation if a user doesn't enter a response, we want error messages at
    the top of the page that say:

    Questions 1, 3, and 7 have not been answered.

    So, I've been thinking about what the best way to do that is. The best
    thing that I can think of is to not use the required attribute and
    instead use a custom required validator to put some error object in a
    form specific list of validation errors. Then have a JSF component that
    is similar to the messages component - it shouldn't extend it because I
    want form specific validation not page specific - that checks if there
    are any errors in the validation error list and creates appropriate
    message(s).
    You do want to use the required attribute. Validators are not
    triggered if the value is null, so you can't make a standard required
    validator. 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 and it doesn't fit in well with
    JSF.

    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.
    The second form I'm trying to work with is a user registration form. On
    this form the user either enters a certificate number that will allow
    them to sign up or they enter their credit card information. Basically,
    if the certificate is there then the credit card information doesn't
    matter. But, if the certificate isn't present then the credit card
    information is required. How should I handle this scenario? Just add
    the extra validation code in my backing bean so that when the form is
    submitted it does all the checking? What do you all think?
    Yes, I think the best bet is to make neither component required, but
    do certificate/credit card validation on each component as normal.

    Then in your submit action, check that one-and-only-one of the
    components have a non-null value.
  • Richard Wallace at Apr 4, 2006 at 11:35 pm

    Mike Kienenberger wrote:
    On 4/4/06, Richard Wallace wrote:

    For the
    validation if a user doesn't enter a response, we want error messages at
    the top of the page that say:

    Questions 1, 3, and 7 have not been answered.

    So, I've been thinking about what the best way to do that is. The best
    thing that I can think of is to not use the required attribute and
    instead use a custom required validator to put some error object in a
    form specific list of validation errors. Then have a JSF component that
    is similar to the messages component - it shouldn't extend it because I
    want form specific validation not page specific - that checks if there
    are any errors in the validation error list and creates appropriate
    message(s).
    You do want to use the required attribute. Validators are not
    triggered if the value is null, so you can't make a standard required
    validator. 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 How so?
    and it doesn't fit in well with JSF.
    I'm not sure I really care too much about "fitting in" with JSF in
    regards to validation. I just want something that 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. 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. I have to wonder why the required
    attribute is treated as a special case as well. 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.
    The second form I'm trying to work with is a user registration form. On
    this form the user either enters a certificate number that will allow
    them to sign up or they enter their credit card information. Basically,
    if the certificate is there then the credit card information doesn't
    matter. But, if the certificate isn't present then the credit card
    information is required. How should I handle this scenario? Just add
    the extra validation code in my backing bean so that when the form is
    submitted it does all the checking? What do you all think?
    Yes, I think the best bet is to make neither component required, but
    do certificate/credit card validation on each component as normal.

    Then in your submit action, check that one-and-only-one of the
    components have a non-null value.
  • Mike Kienenberger at Apr 5, 2006 at 12:19 am

    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 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.
  • Richard Wallace at Apr 5, 2006 at 1:58 am

    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 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
  • Craig McClanahan at Apr 5, 2006 at 2:11 am

    On 4/4/06, Richard Wallace wrote:
    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 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.

    Note that your use cases for "consolidation" are probably on the 20% side of
    the 80/20 rule :-).

    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.

    Don't feel limited to using the standard message and messages components.
    If the messages themselves are tied to individual input components, writing
    a version of the <h:messages> renderer that picks out only the messages for
    components nested inside a particular form is pretty easy.

    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.

    That (validation in the backing bean) seems like the right answer for
    *application* defined vaidations that cross multiple components, which
    includes the use case you are describing. JSF's validation framework is
    focused on single component sorts of validations.
    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?

    Here's a strategy for dealing with "all the errors related to components in
    a particular form":

    * Build a variant of the standard <h:messages> component that takes some
    sort of reference to the containing form component.

    * At rendering time for this component, start doing a recursive tree search
    of
    the form component's children.

    * For each component that might have been a source of validation errors
    (simplest
    test is "instanceof EditableValueHolder" but you might have special cases
    too),
    call FacesContext.getMessages(String clientId) to grab any messages
    assigned
    to that client.

    * Consolidate all the messages accumulated during this tree search in any
    manner
    that you desire.


    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.


    As an example of the flexibility JSF does provide (but doesn't deal directly
    with your particular issue), consider the fact that Shale lets you use
    Commons Validator to implement client side (as well as server side)
    validation on standard JSF components.

    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.

    This was done primarily for usability reasons. The fundamental philosophy
    was "there is no point in firing validators when there is no data to
    validate" because a typical validator author would assume something would be
    there, and inadvertently trigger NPEs. We originally had the required
    validation as a standard Validator implementation, but dealing with this
    issue would have required some additional hack on the API that lets a
    validator say "not only is there an error here, but don't bother doing any
    more validations on it." Much cleaner to have a boolean flag that says
    whether this component is required or not.

    Also, for any component that extends UIInput, you don't actually have to do
    anything to implement this check in your custom component -- it's all done
    for you in the base class.

    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
    Craig
  • Richard Wallace at Apr 5, 2006 at 3:29 am

    Craig McClanahan wrote:

    On 4/4/06, *Richard Wallace* wrote:

    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 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.


    Note that your use cases for "consolidation" are probably on the 20%
    side of the 80/20 rule :-).

    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.


    Don't feel limited to using the standard message and messages
    components. If the messages themselves are tied to individual input
    components, writing a version of the <h:messages> renderer that picks
    out only the messages for components nested inside a particular form
    is pretty easy.
    Well sure, for someone as familiar with it all as you are it's probably
    no big deal at all. Now that I've got the general approach from the
    description you give down below even I could probably handle it.
    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.


    That (validation in the backing bean) seems like the right answer for
    *application* defined vaidations that cross multiple components, which
    includes the use case you are describing. JSF's validation framework
    is focused on single component sorts of validations.
    Alright, that makes sense then. I was thinking that the validation
    framework in JSF was meant to be a general purpose, handle everything
    validation related framework.
    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?


    Here's a strategy for dealing with "all the errors related to
    components in a particular form":

    * Build a variant of the standard <h:messages> component that takes some
    sort of reference to the containing form component.

    * At rendering time for this component, start doing a recursive tree
    search of
    the form component's children.

    * For each component that might have been a source of validation
    errors (simplest
    test is "instanceof EditableValueHolder" but you might have special
    cases too),
    call FacesContext.getMessages(String clientId) to grab any messages
    assigned
    to that client.

    * Consolidate all the messages accumulated during this tree search in
    any manner
    that you desire.
    That's a great run down. I'll give this a try sometime soon I think.
    The only thing I'm not sure about with that is how could you do global
    messages, form specific messages, and component specific messages.
    That's probably not a very likely scenario so it's no big deal if I
    can't have my cake and eat it too.
    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.



    As an example of the flexibility JSF does provide (but doesn't deal
    directly with your particular issue), consider the fact that Shale
    lets you use Commons Validator to implement client side (as well as
    server side) validation on standard JSF components.
    One of the big things that does really bother me is defining custom
    messages on a per component basis. With everything that I've learned
    from this thread I think I understand how to deal with the issues I've
    had up until now. But not being able to define per component validation
    messages just seems like a fundamental shortcoming. I'm glad it's being
    addressed in the tomahawk validators by adding a message attribute:
    http://issues.apache.org/jira/browse/TOMAHAWK-169?rc=1

    Is the next step with that just extending the standard JSF validators to
    allow them to have the message attribute? I'm also wondering, can you
    set custom required messages if you use the tomahawk extensions?
    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.

    This was done primarily for usability reasons. The fundamental
    philosophy was "there is no point in firing validators when there is
    no data to validate" because a typical validator author would assume
    something would be there, and inadvertently trigger NPEs. We
    originally had the required validation as a standard Validator
    implementation, but dealing with this issue would have required some
    additional hack on the API that lets a validator say "not only is
    there an error here, but don't bother doing any more validations on
    it." Much cleaner to have a boolean flag that says whether this
    component is required or not.

    Also, for any component that extends UIInput, you don't actually have
    to do anything to implement this check in your custom component --
    it's all done for you in the base class.

    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


    Craig
  • Craig McClanahan at Apr 5, 2006 at 3:38 am

    On 4/4/06, Richard Wallace wrote:

    That's a great run down. I'll give this a try sometime soon I think.
    The only thing I'm not sure about with that is how could you do global
    messages, form specific messages, and component specific messages.
    That's probably not a very likely scenario so it's no big deal if I
    can't have my cake and eat it too.

    Much as we (the JSF 1.0 expert group) would have liked to address all the
    possible application framework sorts of issues like this, there just wasn't
    time to do all that and still get the 1.0 version out in any reasonable time
    frame. So, we chose to focus on the view tier only capabilities (for
    validation, that means primarily things like checking formats, not semantic
    meaning), but tried to provide enough pluggable extension points so that
    application frameworks could fill in the gaps.

    Your use case is the sort of thing that makes sense to look at in a
    JSF 2.0time frame ... although one could also argue that application
    level
    validation frameworks are not specific to JSF, and it might make more sense
    to focus a specific JSR on just those sorts of issues.

    Craig
  • Mike Kienenberger at Apr 5, 2006 at 4:15 pm

    On 4/4/06, Richard Wallace wrote:
    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
    See below.
    required being a child element rather than a component attribute
    If you really want to do this, the OptionalValidatorFramework provides it.
    Stick a SubmittedValueCollectorWalker at the top of the form, stick a
    RequiredValidatorChecker at the bottom of the form, remove all
    required attributes, and add RequiredValidator validators as
    appropriate.
    and for messages tied to forms in addition to global and
    component messages.
    That sounds useful, although best practice for JSF is one form per page.
    How about designing it as Craig outlined, and submitting it to MyFaces tomahawk?

    One of the big things that does really bother me is defining custom
    messages on a per component basis. With everything that I've learned
    from this thread I think I understand how to deal with the issues I've
    had up until now. But not being able to define per component validation
    messages just seems like a fundamental shortcoming. I'm glad it's being
    addressed in the tomahawk validators by adding a message attribute:
    http://issues.apache.org/jira/browse/TOMAHAWK-169?rc=1

    Is the next step with that just extending the standard JSF validators to
    allow them to have the message attribute? I'm also wondering, can you
    set custom required messages if you use the tomahawk extensions?
    Both of these things would be nice to have, but I don't personally
    plan on implementing them myself at this time. It should be easy
    enough to copy the code from the standard validators and make them
    extend ValidatorBase, creating "t:" versions of each validator. I
    think this would be a good idea, and I'd be happy to commit patches to
    do it.

    I haven't looked at what it would take to have a custom required
    message with the tomahawk extensions. It'd be worth pursuing.
    Another thing to keep in mind is that JSF 1.2 does address these needs
    partially. So far, it implements a "requiredMessage" UIInput
    attribute, with validator/converter attributes to follow.

    https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=81

    You might also read

    https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=103

    This is tracked in our system as a JSF 1.2 issue --
    http://issues.apache.org/jira/browse/MYFACES-1237

    Personally, I think per-validator messages are more useful than one
    global validator message. I've been putting off adding my comments
    on this to issue 81 -- done.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmyfaces
postedApr 4, '06 at 9:34p
activeApr 5, '06 at 4:15p
posts9
users3
websitemyfaces.apache.org

People

Translate

site design / logo © 2019 Grokbase