I should also add that you cannot use external XML entities in validator XML 
files for any released version of Struts. However, Struts 1.3, as of 
tonight, will include code, dependent on Validator 1.2, which will allow 
their use.

Don

On 8/29/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> 
> Fyi, Struts 1.3 is moving to a Validator 1.2 dependency. This version
> includes support for the form "extends" attribute which provides just
> what you were asking for.
> 
> Hubert
> 
> On 8/26/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
> > Quinn Stone wrote:
> > > Is there any way to define the validation for a common form field once 
> in
> > > validation.xml and re-use the validation in other <form> blocks?
> > >
> > > This would allow validation.xml to be updated in one place rather than 
> many
> > > places, if validation requirements change for a field that is used on 
> many
> > > forms. It would also help ensure that I (or others) won't accidentally
> > > incorrectly code different validations for the same field on different 
> forms.
> > > The benefits will compound if I start writing custom validation 
> routines.
> > >
> > > I am new to Struts, and this is my first project using it, so I hope 
> I'm not
> > > missing something obvious.
> >
> > I guess what you're looking for is the ability to specify a list/set of
> > validations (e.g. 'depends="required,mask"') and associated parameters,
> > messages, etc. once for a field and have that same configuration applied 
> on
> > different forms using that field, right? Unfortunately, as far as I 
> know,
> > validator doesn't provide any facility to accomplish that directly.
> > However, I can think of one or two ways you could achieve it.
> >
> > The first would be using XML entities to setup and reference your 
> re-used
> > validations, something like:
> >
> > <DOCTYPE ... [
> > <!ENTITY field1 "<field name="loginid" depends="required"...>
> > ]>
> > ...
> > <form ...>
> > &field1;
> > ...
> > </form>
> >
> > (it may take some fiddling with syntax in the entity definition, and 
> using
> > external entities might be easier).
> >
> > The second would be to define custom validation rules that encapsulate 
> the
> > required composition and parameterization under a single name so that
> > everywhere the field is used you'd specify 
> 'depends="my-composite-validation"'.
> >
> > If there are any better ways to do this, I'd be interested to hear about
> > them too :-)
> >
> > L.
> > --
> > Laurie Harper
> > Open Source advocate, Java geek: http://www.holoweb.net/laurie
> > Founder, Zotech Software: http://www.zotechsoftware.com/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Reply via email to