Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <459C1221.2020600@rhe.co.nz>
Date: Thu, 04 Jan 2007 09:29:21 +1300
From: Simon Kitching <simon.kitching@rhe.co.nz>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: MyFaces Discussion <users@myfaces.apache.org>
Subject: Re: Inline validation method
References: <8088224.post@talk.nabble.com> <459AC93F.3040201@rhe.co.nz>
 <75c123340701030544h2414b3bcgb2b745866f8c1e30@mail.gmail.com>
In-Reply-To: <75c123340701030544h2414b3bcgb2b745866f8c1e30@mail.gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Thanks David.

Is this "validator" attribute something added in JSF 1.2? I'm sure it 
doesn't exist in JSF 1.1 (which is what MyFaces 1.1.x supports).

The article doesn't specify what JSF version each of the demonstrated 
features is available in..

Cheers, Simon

David Chandler wrote:
> FYI, here's the link to the original article:
> 
> http://www-128.ibm.com/developerworks/library/j-jsf3/
> 
> It simply illustrates inline validation in JSF 1.1, and Simon is
> correct that the bean validator method gets passed a component
> reference (along with faces context, and an Object value to validate).
> 
> In practice, the easiest way to code the correct signature for a bean
> validator method is to use your IDE to auto-create the validate()
> method by having your managed bean implement the
> javax.faces.validator.Validator interface. The bean doesn't actually
> have to implement the interface, nor does the method have to be named
> validate, but it's a convenient way to create the code.
> 
> /dmc
> 
> On 1/2/07, Simon Kitching <simon.kitching@rhe.co.nz> wrote:
>> lightbulb432 wrote:
>> > The text below is a modified excerpt from the IBM article about JSF
>> > validation...I'm wondering what exactly they're trying to say. What 
>> do they
>> > mean by the "value [has] to be generically evaluated with a component
>> > association in lieu of directly inspecting the local bean
>> > properties"...what's the issue here?
>>
>> It would be nice if you gave a URL to the quoted article. I guess this
>> is some IBM proposal to add a feature to JSF (presumably for the JSF 1.3
>> or 2.0 releases).
>>
>> At the point that validation runs, the "update model" phase has not
>> executed. So if you were to try to access the managed-bean property
>> specified in the "value" attribute, it wouldn't yet have the new value.
>> This is really the *point* of validation - checking before updating 
>> model.
>>
>> So to get the value to be validated, you must ignore whatever the
>> "value" attribute points to, and instead get the data directly out of
>> the JSF component.
>>
>> I presume their proposed "validator" method gets passed the relevant
>> UIComponent object (an HtmlInputText in this case).
>>
>> >
>> >
>> >
>> > The method would then be used in the JSF tag via the validator 
>> attribute as
>> > shown here:
>> >
>> >   <h:inputText id="email"
>> >                value="#{UserRegistration.user.email}"
>> >                validator="#{UserRegistration.validateEmail}"
>> >                required="true">
>> >   </h:inputText>
>> >
>> > The validateEmail method is used by JSF to perform custom validation 
>> on an
>> > inputText component value bound to a user.email model property. If the
>> > e-mail format is invalid, then a message is added to the faces 
>> context for
>> > the associated component. Now, considering that this validation 
>> method is
>> > actually part of the backing bean, why does the value have to be 
>> generically
>> > evaluated with a component association in lieu of directly 
>> inspecting the
>> > local bean properties? For a hint, look at the prior lifecycle figures.
>> > Don't worry if you can't quite figure it out right now; we'll 
>> explain it all
>> > at the end of the article.
>> >
>> > Why, if a validation method is actually part of a backing bean, must 
>> its
>> > value be generically evaluated with a component association?
>> >
>> > The trick here is that, although the validateEmail inline validation 
>> method
>> > is part of the actual backing bean, the method must reference the 
>> value via
>> > component association rather than accessing the local properties 
>> directly.
>> > Because validation occurs before the component values are bound to 
>> the model
>> > (in the update model values phase), the model is in an unknown state.
>> > Therefore, you must write the inline custom validation logic as if 
>> it were
>> > dealing with validation in a custom Validator object. This is also 
>> explains
>> > the requirement of maintaining the same method signature.
>>
>>
> 
>