Menu
▾
▴
springframework-developer
|
From: Oliver H. <Ol...@ou...> - 2005-09-12 04:32:39
|
=20 > > Hi Paul, > >=20 > > Have you looked at Valang already? > >=20 > >=20 > http://opensource2.atlassian.com/confluence/spring/display/MODULES/Usi > > ng+Valang+validator > >=20 > > It's a declarative validation language that has some powerful=20 > > constructs and its feature set is growing. It's build on top of=20 > > Spring's validation package. It currently isn't released=20 > yet but the=20 > > code is stable and a lot of people use it in production. >=20 > I can second this recommendation. For one, Valang is much=20 > easier to read than the commons-validator XML file. I'm also using Valang in production and love it. The only reason I can see why you'd want to use commons-validator is for the automatic JavaScript validation support but within the week I hope to make the code for my Valang to JavaScript translator available which will allow you to have your server side Valang rules automatically translated into client side JavaScript. Ollie |
|
From: Oliver H. <Ol...@ou...> - 2005-09-12 22:47:26
|
=20
> Basically we could do something like this:
>=20
>=20
> public @interface Validate {
> String constraint();
> String code();
> String message();
> String[] arguments();
> }
I personally think it would be nicer to implement the annotation in a
way that is consistent with the rule definitions used by
ValangValidatorFactoryBean:
public @interface Validate {
String valang();
}
public class MyClass {
@Validate("? not blank : 'First name should not be blank' :
'firstName_blank'")
public String getFirstName() { return this.firstName; }
Also how would you deal with validating nested objects? For instance,
when editing contact details, our website will present the user with a
list of states and also with the option of entering in an alternative
state not in the list using a text field. Usually we bind directly onto
our domain object but because we have introduced an additional field I
create a form object that provides an accessor for the domain object and
for the additional field and then bind what I can directly to the domain
object and the additional fields onto the form object:
class ContactForm {
Contact contact;
String otherState;
// where possible bind directly to this domain object
getContact() { return contact;}=20
@Validate("? is not blank && contact.state is not blank :
'Please select or enter a state but not both')
String getOtherState() { return otherState; }
void setOtherState(String otherState) {this.otherState =3D
otherState; }=09
}
How would you tell the annotation driven validator that it must also
validate the Contact object? Would we need an additional annotation?
public @interface ValidateNested {
}
class ContactForm {
Contact contact;
String otherState;
@ValidateNested
getContact() { return contact;}=20
...
Ollie
|
|
From: Thomas V. de V. <tho...@ac...> - 2005-09-13 06:48:07
|
I wasn't familiar with Valang. It make sense to keep this in line with thei=
r=20
rule definitions. Are they checking the validity of the rules at run-time,=
=20
when the application context loads?=20
On 9/13/05, Oliver Hutchison <Ol...@ou...> wrote:
>=20
>=20
>=20
> > Basically we could do something like this:
> >
> >
> > public @interface Validate {
> > String constraint();
> > String code();
> > String message();
> > String[] arguments();
> > }
>=20
> I personally think it would be nicer to implement the annotation in a
> way that is consistent with the rule definitions used by
> ValangValidatorFactoryBean:
>=20
> public @interface Validate {
> String valang();
> }
>=20
> public class MyClass {
>=20
> @Validate("? not blank : 'First name should not be blank' :
> 'firstName_blank'")
> public String getFirstName() { return this.firstName; }
>=20
> Also how would you deal with validating nested objects? For instance,
> when editing contact details, our website will present the user with a
> list of states and also with the option of entering in an alternative
> state not in the list using a text field. Usually we bind directly onto
> our domain object but because we have introduced an additional field I
> create a form object that provides an accessor for the domain object and
> for the additional field and then bind what I can directly to the domain
> object and the additional fields onto the form object:
>=20
> class ContactForm {
> Contact contact;
> String otherState;
>=20
> // where possible bind directly to this domain object
> getContact() { return contact;}
>=20
> @Validate("? is not blank && contact.state is not blank :
> 'Please select or enter a state but not both')
> String getOtherState() { return otherState; }
> void setOtherState(String otherState) {this.otherState =3D
> otherState; }
> }
>=20
> How would you tell the annotation driven validator that it must also
> validate the Contact object? Would we need an additional annotation?
>=20
> public @interface ValidateNested {
> }
>=20
> class ContactForm {
> Contact contact;
> String otherState;
>=20
> @ValidateNested
> getContact() { return contact;}
> ...
>=20
>=20
> Ollie
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: Oliver H. <Ol...@ou...> - 2005-09-15 23:02:02
|
The Valang to JavaScript translation support has now been commited to the Spring Modules sandbox. So if you're using Valang, you can now have JavaScript validation automatically generated from your server-side validation rules. Documentation is here: http://opensource2.atlassian.com/confluence/spring/display/MODULES/Using +your+Valang+rules+to+generate+client+side+JavaScript.=20 Cheers, Oliver > -----Original Message----- > From: spr...@li...=20 > [mailto:spr...@li...] > On Behalf Of Oliver Hutchison > Sent: Monday, 12 September 2005 2:32 PM > To: spr...@li... > Subject: RE: [Springframework-developer] Spring MVC and validation >=20 > I'm also using Valang in production and love it. The only=20 > reason I can see why you'd want to use commons-validator is=20 > for the automatic JavaScript validation support but within=20 > the week I hope to make the code for my Valang to JavaScript=20 > translator available which will allow you to have your=20 > server side Valang rules automatically translated into client=20 > side JavaScript. |
|
From: Paul S. <tk...@tk...> - 2005-09-12 08:06:03
|
I'll definitely investigate Valang in depth. Thanks. Just the existence of some documentation puts it ahead of the commons validator integration support in Spring modules. :) Valang looks pretty powerful, although it's still missing some basic functionality like email, credit card validation. Perhaps that sort of stuff probably belongs more in the ValidatorUtils since Valang seems to be a general purpose tool. Regular expressions were alluded to (customizing date parser), but I didn't see them specifically listed. At some point I hope a validation framework gets integrated into Spring MVC. Thanks again. I'll go into lurker mode now. :) Paul Sundling On Mon, 2005-09-12 at 14:32 +1000, Oliver Hutchison wrote: > > > Hi Paul, > > > > > > Have you looked at Valang already? > > > > > > > > http://opensource2.atlassian.com/confluence/spring/display/MODULES/Usi > > > ng+Valang+validator > > > > > > It's a declarative validation language that has some powerful > > > constructs and its feature set is growing. It's build on top of > > > Spring's validation package. It currently isn't released > > yet but the > > > code is stable and a lot of people use it in production. > > > > I can second this recommendation. For one, Valang is much > > easier to read than the commons-validator XML file. > > I'm also using Valang in production and love it. The only reason I can > see why you'd want to use commons-validator is for the automatic > JavaScript validation support but within the week I hope to make the > code for my Valang to JavaScript translator available which will allow > you to have your server side Valang rules automatically translated into > client side JavaScript. > > Ollie > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Thomas V. de V. <tho...@ac...> - 2005-09-12 12:34:30
|
I am wondering if it'd make sense to have the validation rules defined as= =20 annotations.=20 e.g. @RequiredField @EmailAddress I've worked with forms that contains 2 000 + fields and maintaining externa= l=20 XML files is really cumbersome in such a case? Any thoughts, pros/cons? Cheers, Thomas On 9/12/05, Paul Sundling <tk...@tk...> wrote: >=20 > I'll definitely investigate Valang in depth. Thanks. Just the > existence of some documentation puts it ahead of the commons validator > integration support in Spring modules. :) >=20 > Valang looks pretty powerful, although it's still missing some basic > functionality like email, credit card validation. Perhaps that sort of > stuff probably belongs more in the ValidatorUtils since Valang seems to > be a general purpose tool. Regular expressions were alluded to > (customizing date parser), but I didn't see them specifically listed. >=20 > At some point I hope a validation framework gets integrated into Spring > MVC. >=20 > Thanks again. I'll go into lurker mode now. :) >=20 > Paul Sundling >=20 >=20 > On Mon, 2005-09-12 at 14:32 +1000, Oliver Hutchison wrote: > > > > Hi Paul, > > > > > > > > Have you looked at Valang already? > > > > > > > > > > > http://opensource2.atlassian.com/confluence/spring/display/MODULES/Us= i > > > > ng+Valang+validator > > > > > > > > It's a declarative validation language that has some powerful > > > > constructs and its feature set is growing. It's build on top of > > > > Spring's validation package. It currently isn't released > > > yet but the > > > > code is stable and a lot of people use it in production. > > > > > > I can second this recommendation. For one, Valang is much > > > easier to read than the commons-validator XML file. > > > > I'm also using Valang in production and love it. The only reason I can > > see why you'd want to use commons-validator is for the automatic > > JavaScript validation support but within the week I hope to make the > > code for my Valang to JavaScript translator available which will allow > > you to have your server side Valang rules automatically translated into > > client side JavaScript. > > > > Ollie > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20 > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &= =20 > QA > > Security * Process Improvement & Measurement *=20 > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20 > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Sean M. <se...@se...> - 2005-09-12 12:51:29
|
This looks like a really neat option for single-field validations; is there an obvious way of handling multi-field validations as annotations, like collision : (firstName is not blank or lastName is not blank) and userid is not blank : 'Fill in either name or id' Cheers, Sean Miller. Thomas Van de Velde wrote: > I am wondering if it'd make sense to have the validation rules defined > as annotations. > > e.g. > > @RequiredField > @EmailAddress > > I've worked with forms that contains 2 000 + fields and maintaining > external XML files is really cumbersome in such a case? Any thoughts, > pros/cons? |
|
From: Steven D. <ste...@in...> - 2005-09-12 13:33:08
|
I've had a couple of requests now to include support for annotations.
Basically we could do something like this:
public @interface Validate {
String constraint();
String code();
String message();
String[] arguments();
}
So you could do:
package test;
public class MyClass {
private String firstName = null;
@Validate(
constraint = "? not blank",
code = "firstName_blank"
)
public String getFirstName() { return this.firstName; }
public void setFirstName(String firstName) { this.firstName =
firstName; }
private String lastName = null;
@Validate("? not blank") // would use code:
test.MyClass_lastName_invalid
public String getLastName() { return this.lastName; }
public void setLastName(String lastName) { this.lastName =
lastName; }
}
Any thoughts on this?
Steven Devijver
Senior consultant
@ Interface21
ste...@in...
On 12 Sep 2005, at 14:51, Sean Miller wrote:
> This looks like a really neat option for single-field validations;
> is there an obvious way of handling multi-field validations as
> annotations, like
>
> collision : (firstName is not blank or lastName is not blank) and
> userid is not blank : 'Fill in either name or id'
>
> Cheers,
> Sean Miller.
>
> Thomas Van de Velde wrote:
>
>
>
>
>
>> I am wondering if it'd make sense to have the validation rules
>> defined as annotations.
>> e.g.
>>
>> @RequiredField
>> @EmailAddress
>>
>> I've worked with forms that contains 2 000 + fields and
>> maintaining external XML files is really cumbersome in such a
>> case? Any thoughts, pros/cons?
>>
>>
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>
|
|
From: Thomas V. de V. <tho...@ac...> - 2005-09-12 20:07:04
|
That would be excellent stuff Steven!
I have used this on a very large scale and combined it with a JSP tag that=
=20
reads the annotation and writes appropriate JavaScript. On the server side,=
=20
the annotation can be read to execute server-side validation logic.
With your solution I'd be worried about typos in the validation rules.=20
Wouldn't it be better to have something more explicit licate=20
@ValidateRequired, @ValidateEmail, and @ValidateDate, ....
To respond to Sean's question, you could have a @ValidateRequiredIfBlank("
mybean.afield") but there are limits to this of course.=20
I guess you'd also have to pass another parameter that points to the key of=
=20
a message that you want to show for validation messages.
Thomas
On 9/12/05, Steven Devijver <ste...@in...> wrote:
>=20
> I've had a couple of requests now to include support for annotations.
> Basically we could do something like this:
>=20
>=20
> public @interface Validate {
> String constraint();
> String code();
> String message();
> String[] arguments();
> }
>=20
> So you could do:
>=20
> package test;
>=20
> public class MyClass {
>=20
> private String firstName =3D null;
> @Validate(
> constraint =3D "? not blank",
> code =3D "firstName_blank"
> )
> public String getFirstName() { return this.firstName; }
> public void setFirstName(String firstName) { this.firstName =3D
> firstName; }
>=20
> private String lastName =3D null;
> @Validate("? not blank") // would use code:
> test.MyClass_lastName_invalid
> public String getLastName() { return this.lastName; }
> public void setLastName(String lastName) { this.lastName =3D
> lastName; }
> }
>=20
> Any thoughts on this?
>=20
> Steven Devijver
> Senior consultant
> @ Interface21
> ste...@in...
>=20
>=20
>=20
> On 12 Sep 2005, at 14:51, Sean Miller wrote:
>=20
>=20
>=20
>=20
> > This looks like a really neat option for single-field validations;
> > is there an obvious way of handling multi-field validations as
> > annotations, like
> >
> > collision : (firstName is not blank or lastName is not blank) and
> > userid is not blank : 'Fill in either name or id'
> >
> > Cheers,
> > Sean Miller.
> >
> > Thomas Van de Velde wrote:
> >
> >
> >
> >
> >
> >> I am wondering if it'd make sense to have the validation rules
> >> defined as annotations.
> >> e.g.
> >>
> >> @RequiredField
> >> @EmailAddress
> >>
> >> I've worked with forms that contains 2 000 + fields and
> >> maintaining external XML files is really cumbersome in such a
> >> case? Any thoughts, pros/cons?
> >>
> >>
> >>
> >>
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/
> > bsce5sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> >
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: Steven D. <ste...@in...> - 2005-09-12 20:56:52
|
On 12 Sep 2005, at 22:06, Thomas Van de Velde wrote:
> That would be excellent stuff Steven!
>
> I have used this on a very large scale and combined it with a JSP
> tag that reads the annotation and writes appropriate JavaScript.
> On the server side, the annotation can be read to execute server-
> side validation logic.
>
> With your solution I'd be worried about typos in the validation
> rules. Wouldn't it be better to have something more explicit
> licate @ValidateRequired, @ValidateEmail, and @ValidateDate, ....
>
We could obviously create these annotation classes as shorthand
notations but writing your own constraints is much more powerful, in
the end that's what Valang is about.
I'm not sure if there is a common set of validation annotation
classes but to me it makes sense to not couple these annotations to
Spring or Valang. With annotations all you would need to do is have a
Spring Validator implementation that reads the annotations of a class
and validates the objects that come in. These annotated classes could
then be used with Struts or WebWork or any other framework that wants
to support them.
> To respond to Sean's question, you could have a
> @ValidateRequiredIfBlank("mybean.afield") but there are limits to
> this of course.
>
> I guess you'd also have to pass another parameter that points to
> the key of a message that you want to show for validation messages.
>
> Thomas
>
> On 9/12/05, Steven Devijver <ste...@in...> wrote:
> I've had a couple of requests now to include support for annotations.
> Basically we could do something like this:
>
>
> public @interface Validate {
> String constraint();
> String code();
> String message();
> String[] arguments();
> }
>
> So you could do:
>
> package test;
>
> public class MyClass {
>
> private String firstName = null;
> @Validate(
> constraint = "? not blank",
> code = "firstName_blank"
> )
> public String getFirstName() { return this.firstName; }
> public void setFirstName(String firstName) { this.firstName =
> firstName; }
>
> private String lastName = null;
> @Validate("? not blank") // would use code:
> test.MyClass_lastName_invalid
> public String getLastName() { return this.lastName; }
> public void setLastName(String lastName) { this.lastName =
> lastName; }
> }
>
> Any thoughts on this?
>
> Steven Devijver
> Senior consultant
> @ Interface21
> ste...@in...
>
>
>
> On 12 Sep 2005, at 14:51, Sean Miller wrote:
>
>
>
>
> > This looks like a really neat option for single-field validations;
> > is there an obvious way of handling multi-field validations as
> > annotations, like
> >
> > collision : (firstName is not blank or lastName is not blank) and
> > userid is not blank : 'Fill in either name or id'
> >
> > Cheers,
> > Sean Miller.
> >
> > Thomas Van de Velde wrote:
> >
> >
> >
> >
> >
> >> I am wondering if it'd make sense to have the validation rules
> >> defined as annotations.
> >> e.g.
> >>
> >> @RequiredField
> >> @EmailAddress
> >>
> >> I've worked with forms that contains 2 000 + fields and
> >> maintaining external XML files is really cumbersome in such a
> >> case? Any thoughts, pros/cons?
> >>
> >>
> >>
> >>
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams *
> > Testing & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/
> > bsce5sf
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-
> developer
> >
> >
> >
> >
> >
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/
> bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
