Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of craigmcc@gmail.com designates
 64.233.170.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=LIRv/nIhNK9FUYtXOJlJ6bJByxMKenRS598Kp0pFAseycWsn3rtHkU30vsh7RBwBKVIANPrwVgfy1l/UaTb1X/OHqiBbiK/tTx9YCCXrbOFGYkvXitv+b5FlfxbALTrHCk0EqhGgCZhcMEr2Bdko7LBcqfmELPr04t3odjKjLko=
Message-ID: <f8b39ace050808160973d0a8cb@mail.gmail.com>
Date: Mon, 8 Aug 2005 16:09:35 -0700
From: Craig McClanahan <craigmcc@gmail.com>
Reply-To: craigmcc@apache.org
To: Sean Schofield <sean.schofield@gmail.com>
Subject: Re: [shale] Possible Shale Enhancement
Cc: Struts Developers List <dev@struts.apache.org>
In-Reply-To: <2387fbc5050808155466b224b2@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <2387fbc5050802094858edf357@mail.gmail.com>
	 <f8b39ace05080210344c6b8973@mail.gmail.com>
	 <2387fbc5050802114876977def@mail.gmail.com>
	 <2387fbc505080811596b6be0cd@mail.gmail.com>
	 <f8b39ace05080813112abe3587@mail.gmail.com>
	 <2387fbc5050808140931bc95@mail.gmail.com>
	 <2387fbc5050808155466b224b2@mail.gmail.com>

On 8/8/05, Sean Schofield <sean.schofield@gmail.com> wrote:
> I have another possible solution for this validation problem.  It
> involves going back to your original answer where you suggested the
> Process Validations phase as the logical place for this type of
> activity to occur.
>=20
> My main problem was access to other components so I could see their
> submitted value.  As I mentioned I am not thrilled with relying on the
> structure of the component tree in my validation logic, yet I really
> need access to these components.  I started thinking about the binding
> attribute but that limits you to binding a single pair of components
> only.

Although access to the other components by navigating the component
tree is guaranteed to work, I take your point that it makes the logic
of this "check" type validator more fragile.  Here's a technique to
consider that might alleviate the issue somewhat:

* Use the "binding" attribute to bind all your input components to
  corresponding properties in the backing bean (Creator will do this
  for you automatically :-).

* Instead of implementing validators as separate classes, implement
  them as a method binding to a method in the same backing bean:

  <h:inputText binding=3D"#{mybean.username}"
validator=3D"#{mybean.checkBizRules}"/>

  which would bind to a method like this:

  public void checkBizRules(FacesContext context, UIComponent
component, Object value)
    throws ValidatorException;

Discerning viewers will note that this is exactly the same method
signature as the Validator.validate() method, except for the method
name.

Within checkBizRules(), you'll have access to the actual components by
name (that is, by the property names you bound them to) without having
to navigate the structure of the component tree.  You're guaranteed,
by virtue of the lifecycle, that all the submitted values have been
set first ... although you're not guaranteed that all the other
validators have fired yet.

>=20
> My idea is to create a custom component that would extend UIInput but
> not generate any HTML when rendered.  This component could hold
> references to a Map of components that would bind to it using the
> binding attribute.  That way you could write validators for this
> "binding component" and have access to all of the components you need.
>  I haven't figured out the details (such as how the components would
> be keyed) but its a different approach that might yield something
> interesting.
>=20
> What do you think?
>=20

Hmm ... sort of along the lines of what <x:saveState> does for state
saving?  I think it might be simpler to use the explicit bindings
approach outined above.

> sean
>=20

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org