Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of ted.husted@gmail.com designates
 64.233.166.182 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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OtCN7ijD5BRDS/Jc0p4vOWIB535SHwomOMFo/KlOPbzRrx+s4Yce69QOoW28PaXxS7cCwDc/fCZpY47Z7rdaROyAVxyKgzJ/ZhCphB1LxTNS2l0c3wvJEpGN4Gh7taKtcuESwzZhiU/rRgq9NuSYB61Y1LV9uHLqZzoxG5pKj18=
Message-ID: <8b3ce3790603280337xd44c540m9efdb58ead6a437b@mail.gmail.com>
Date: Tue, 28 Mar 2006 06:37:09 -0500
From: "Ted Husted" <ted.husted@gmail.com>
Reply-To: husted@apache.org
To: "Struts Users Mailing List" <user@struts.apache.org>
Subject: Re: the ValidateExtends extension
In-Reply-To: <694007130603240905k7860a0e7kb335c810501b1edc@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <694007130603240905k7860a0e7kb335c810501b1edc@mail.gmail.com>

On 3/24/06, Vinny <xaymaca@gmail.com> wrote:
> I've been using the ValidateExtends extension to validate nested dynaform=
 to
> great effect. Currently , it provides no method of using the client
> side (javascript) stuff.
> Any plans for that to be included?
> http://www.niallp.pwp.blueyonder.co.uk/strutsvalidatorextends.html

The trick is to patch the extension so that it does what you need to
do, and then contribute the patch back to the project. That's where
many of our niftiest features came from, including the Validator
itself.


> Will this become a non-issue in the new Action framework?

I'm working on a Cookbook for Action 2, and I just put these use cases
on the list of things to include.

The Action 2 validation framework is similar to the Commons Validator,
but uses a "code behind" approach with the configuration files. Each
Action can have it's own "Action-validation.xml" file. When validation
is needed, the validation for every class in the inheritance path is
applied. Here's an example from the Action2-Mailreader (which is
nearly complete).

This is "SubscripionSave-validation.xml" . It's kept alongside the Java cla=
ss.

<validators>

    <field name=3D"host">
        <field-validator type=3D"requiredstring">
            <message key=3D"error.host.required"/>
        </field-validator>
    </field>

    <field name=3D"subscription.username">
        <field-validator type=3D"requiredstring">
            <message key=3D"error.username.required"/>
        </field-validator>
    </field>

    <field name=3D"subscription.password">
        <field-validator type=3D"requiredstring">
            <message key=3D"error.password.required"/>
        </field-validator>
    </field>

    <field name=3D"subscription.type">
        <field-validator type=3D"requiredstring">
            <message key=3D"error.type.invalid"/>
        </field-validator>
    </field>

</validators>

This is the Subscription-validation.xml. SubscriptionSave is a
subclass of Subscription.

<validators>

    <field name=3D"host">
        <field-validator type=3D"requiredstring">
            <message key=3D"error.host.required"/>
        </field-validator>
    </field>

</validators>

The Subscription action is used to edit or delete records, so the only
validation we need is the "host" property, which is used as a key. The
SubscriptionSave action is used to Insert or Update records. When
SubscriptionSave is validated, the "host" is validated too, because
SubscriptionSave is a subsclass of Subscription.

The Message Resource properties work the same way, but you can also
have a global resource that applies to all classes.

For more about WebWork-style validation see

* http://wiki.opensymphony.com/display/WW/Validation

There's probably some ideas here that we can back-port to Action 1.

-- HTH, Ted.

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