RE: server-side, java-based validation rules for struts..
Cook, Levi writes: IMHO, expressing rules using first class Java objects *can* be just as flexible as defining rules in an XML file. The analog to changing a value in an XML file is using a property editor to change values stored in a JavaBean (thus avoiding recompiling). The upside of this approach is simpler integration with visual editors (simply implement a property editor for your form-bean). Ultimately, I feel this is where your less technical people can begin to contribute more effectivly. The other route requires hand-rolling a visual editor for your XML scheme and/or having your users learn quite a bit about the intricacies of your schema. Thanks Levi for pointing out that a property editor could be used. Could one also add new rules and attributes dynamically with a property editor ? Maybe the trickiest part for the users would be to learn the syntax for rule expressions. In particular how to refer to object attributes within a rule. -- Nick
RE: server-side, java-based validation rules for struts..
When you are doing regular expressions you can
basically just cut and paste them from an example and
escape out the few XML sensitive characters, but you
have to escape out the escape characters in a java
properties file which I think makes something that is
already hard to read even more unreadable. This is
just a simple regular expression.
XML Version (phone number with double quotes around
it)
quot;^\(?(\d{3})\)?[-| ]?(\d{3})[-| ]?(\d{4})$quot;
Properties file version
\^\\(?(\\d{3})\\)?[-| ]?(\\d{3})[-| ]?(\\d{4})$\
In a regular expression a '(' means something and
regular expressions also use '\' to escape out
characters except they don't match java's escape
characters. So '\\(' is escaping out a '\' which is
then escaping a '('.
I did a project keeping all of my regular expressions
in a properties file and I find keeping them in xml
much more convenient. Of course if you were using a
Java IDE then you wouldn't have to worry about
escaping out the java escape characters yourself, but
not everyone uses a full blown IDE.
When I mentioned less technical people I meant
art/design people that use something like Dreamweaver.
Dreamweaver already has basic support for JSP and one
day it will probably support or have a plugin for
editing XML files. I don't think less technical
people are going to find a java IDE easier to use than
an HTML editor if you use properties files. There are
lots of generic XML editing packages so you don't have
to hand roll your own xml editor. And there's always
vi or notepad.
David
http://home.earthlink.net/~dwinterfeldt
--- Nick Afshartous [EMAIL PROTECTED]
wrote:
Cook, Levi writes:
IMHO, expressing rules using first class Java
objects *can* be just as
flexible as defining rules in an XML file.
The analog to changing a value in an XML file is
using a property editor to
change values stored in a JavaBean (thus avoiding
recompiling). The upside
of this approach is simpler integration with
visual editors (simply
implement a property editor for your form-bean).
Ultimately, I feel this is
where your less technical people can begin to
contribute more effectivly.
The other route requires hand-rolling a visual
editor for your XML scheme
and/or having your users learn quite a bit about
the intricacies of your
schema.
Thanks Levi for pointing out that a property editor
could be used.
Could one also add new rules and attributes
dynamically with a
property editor ?
Maybe the trickiest part for the users would be to
learn the
syntax for rule expressions. In particular how to
refer
to object attributes within a rule.
--
Nick
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
RE: server-side, java-based validation rules for struts..
Regular expressions should be:
^quot;\(?(\d{3})\)?[-| ]?(\d{3})[-| ]?(\d{4})$quot;
Properties file version
^\\\(?(\\d{3})\\)?[-| ]?(\\d{3})[-| ]?(\\d{4})\$
David
--- David Winterfeldt [EMAIL PROTECTED] wrote:
When you are doing regular expressions you can
basically just cut and paste them from an example
and
escape out the few XML sensitive characters, but you
have to escape out the escape characters in a java
properties file which I think makes something that
is
already hard to read even more unreadable. This is
just a simple regular expression.
XML Version (phone number with double quotes around
it)
quot;^\(?(\d{3})\)?[-| ]?(\d{3})[-|
]?(\d{4})$quot;
Properties file version
\^\\(?(\\d{3})\\)?[-| ]?(\\d{3})[-| ]?(\\d{4})$\
In a regular expression a '(' means something and
regular expressions also use '\' to escape out
characters except they don't match java's escape
characters. So '\\(' is escaping out a '\' which is
then escaping a '('.
I did a project keeping all of my regular
expressions
in a properties file and I find keeping them in xml
much more convenient. Of course if you were using a
Java IDE then you wouldn't have to worry about
escaping out the java escape characters yourself,
but
not everyone uses a full blown IDE.
When I mentioned less technical people I meant
art/design people that use something like
Dreamweaver.
Dreamweaver already has basic support for JSP and
one
day it will probably support or have a plugin for
editing XML files. I don't think less technical
people are going to find a java IDE easier to use
than
an HTML editor if you use properties files. There
are
lots of generic XML editing packages so you don't
have
to hand roll your own xml editor. And there's
always
vi or notepad.
David
http://home.earthlink.net/~dwinterfeldt
--- Nick Afshartous [EMAIL PROTECTED]
wrote:
Cook, Levi writes:
IMHO, expressing rules using first class Java
objects *can* be just as
flexible as defining rules in an XML file.
The analog to changing a value in an XML file
is
using a property editor to
change values stored in a JavaBean (thus
avoiding
recompiling). The upside
of this approach is simpler integration with
visual editors (simply
implement a property editor for your
form-bean).
Ultimately, I feel this is
where your less technical people can begin to
contribute more effectivly.
The other route requires hand-rolling a visual
editor for your XML scheme
and/or having your users learn quite a bit
about
the intricacies of your
schema.
Thanks Levi for pointing out that a property
editor
could be used.
Could one also add new rules and attributes
dynamically with a
property editor ?
Maybe the trickiest part for the users would be to
learn the
syntax for rule expressions. In particular how to
refer
to object attributes within a rule.
--
Nick
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
RE: server-side, java-based validation rules for struts..
My intent was to mention that property editor's are an option, quite possibly an option I would employ. Another option I see as being quite reasonable is storing configuration info. in an DBMS, so that I can edit through a web browser. This might very well take the form of a date validating regex or MAX_VAL_INCLUSIVE, MIN_VAL_EXCLUSIVE boundaries for a numeric field on my form. Main point being, a validation **framework**, ultimately shouln't care where or how I choose to specify configution values. Its only concern should be invoking the interfaces it defines and I implement and register. -- Levi -Original Message- From: Jonathan [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 9:18 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: server-side, java-based validation rules for struts.. I thought that the point was to NOT have to use a property editor, but rather an xml file
Re: server-side, java-based validation rules for struts..
Good point Martin, I'm not that familiar with it yet, but do you know if the jakarta-commons pool project would be of any help here?? Thanks in advance, Levi Cook - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 23, 2001 9:51 PM Subject: Re: server-side, java-based validation rules for struts.. Slightly more exact mechanics for registering the listeners are: 1. Instantiate the form-bean 2. Instantiate zero to many listeners 3. Register each listener [...] This sounds like it could be an expensive process to be going through on each request. I think you'd want to arrange for the listeners to be cacheable (by Struts) so that step 2 can be performed either at startup time or on first hit for a given listener. -- Martin Cooper - Original Message - From: Cook, Levi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 8:20 AM Subject: RE: server-side, java-based validation rules for struts.. Yes, the end result is ActionForms with Listeners registered prior to the ActionServlet populating our form with the users request values. Slightly more exact mechanics for registering the listeners are: 1. Instantiate the form-bean 2. Instantiate zero to many listeners 3. Register each listener using one of following bean method naming conventions: addPropertyNameVetoableChangeListener(VetoableChangeListener listener) addVetoableChangeListener(String propertyName, VetoableChangeListener listener) addVetoableChangeListener(VetoableChangeListener listener) A key abstraction here, is that neither object ever has an explicit reference to the other. Said another way this provides loose coupling between our action forms and their listeners. This supports the struts as a framework concept by allowing the following: 1. The number (zero to many) of listeners may be unknown at compile-time, and can vary throughout run-time. 2. Listener and form objects neet to be loosely coupled becuase we have no way of predicting all the Listeners (eg. Validations) users could be interested in. Abstraction sure seems difficult to explain sometimes, thanks again for helping me refine my explanation. Levi -Original Message- From: Jonathan [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 9:10 AM To: [EMAIL PROTECTED] Subject: Re: server-side, java-based validation rules for struts.. So you are saying that when an ActionForm is instantiated its associated listener(s) get shoved in (read registered) via a set method on the ActionForm, and the Listener actually does the registering of itself in its constructor or something. So what you have is a bunch of ActionsForms with their listeners already registered. Did I get it? - Original Message - From: Levi Cook [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 11:44 AM Subject: Re: server-side, java-based validation rules for struts.. I guess that's the critical part, eh-- sorry for the hand-waving :) At this point, I see the Struts controller coordinating these rules, based on the contents of struts-config.xml: 1. Instantiation of our form-bean as needed (no real change here). 2. Instantiation of optional change-listeners* associated with our form. (peek at the xml fragment below) 3. Now, it can register the change-listener (aka VetoableChangeListener), with our new form-bean. note: addPropertyNameVetoableChangeListener removePropertyNameVetoableChangeListener adhere to a naming pattern established by the JavaBeans spec. for more on this, see the last section on this page: http://java.sun.com/docs/books/tutorial/javabeans/properties/constrained.htm l Assuming that this is all happened smoothly, which I think is pretty safe, that leaves the following main question: -- What happens when Struts begins to populate our action form? A. Nothing, our users suddendly started getting everything right, so our Validators never complain about their input anymore. B. Our, the more probable route... our Validators start throwing PropertyVetoExceptions because our user's aren't any better at answering these questions than we are :) This point introduces the next responsibily I planned on handing the struts-controller: handling PropertyVetoExceptions. In short, I'd like it to basically turn these exceptions into ActionErrors for us. Hope this sounds a little clearer, thanks for the feedback-- I think it greatly influences the ideas quality. Regards, Levi Cook struts-config !-- etc.. -- form-bean name=myCCForm type=MyCCForm change-listener
RE: server-side, java-based validation rules for struts..
I'm not so much of an XML expert, but isn't the CCDATA character section
offering a nice solution in order to preserve the real look of a reg. exp.
in an XML file?
Fr.
-Original Message-
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: 25 June 2001 18:11
To: [EMAIL PROTECTED]
Subject: RE: server-side, java-based validation rules for struts..
Regular expressions should be:
^quot;\(?(\d{3})\)?[-| ]?(\d{3})[-| ]?(\d{4})$quot;
Properties file version
^\\\(?(\\d{3})\\)?[-| ]?(\\d{3})[-| ]?(\\d{4})\$
David
--- David Winterfeldt [EMAIL PROTECTED] wrote:
When you are doing regular expressions you can
basically just cut and paste them from an example
and
escape out the few XML sensitive characters, but you
have to escape out the escape characters in a java
properties file which I think makes something that
is
already hard to read even more unreadable. This is
just a simple regular expression.
XML Version (phone number with double quotes around
it)
quot;^\(?(\d{3})\)?[-| ]?(\d{3})[-|
]?(\d{4})$quot;
Properties file version
\^\\(?(\\d{3})\\)?[-| ]?(\\d{3})[-| ]?(\\d{4})$\
In a regular expression a '(' means something and
regular expressions also use '\' to escape out
characters except they don't match java's escape
characters. So '\\(' is escaping out a '\' which is
then escaping a '('.
I did a project keeping all of my regular
expressions
in a properties file and I find keeping them in xml
much more convenient. Of course if you were using a
Java IDE then you wouldn't have to worry about
escaping out the java escape characters yourself,
but
not everyone uses a full blown IDE.
When I mentioned less technical people I meant
art/design people that use something like
Dreamweaver.
Dreamweaver already has basic support for JSP and
one
day it will probably support or have a plugin for
editing XML files. I don't think less technical
people are going to find a java IDE easier to use
than
an HTML editor if you use properties files. There
are
lots of generic XML editing packages so you don't
have
to hand roll your own xml editor. And there's
always
vi or notepad.
David
http://home.earthlink.net/~dwinterfeldt
--- Nick Afshartous [EMAIL PROTECTED]
wrote:
Cook, Levi writes:
IMHO, expressing rules using first class Java
objects *can* be just as
flexible as defining rules in an XML file.
The analog to changing a value in an XML file
is
using a property editor to
change values stored in a JavaBean (thus
avoiding
recompiling). The upside
of this approach is simpler integration with
visual editors (simply
implement a property editor for your
form-bean).
Ultimately, I feel this is
where your less technical people can begin to
contribute more effectivly.
The other route requires hand-rolling a visual
editor for your XML scheme
and/or having your users learn quite a bit
about
the intricacies of your
schema.
Thanks Levi for pointing out that a property
editor
could be used.
Could one also add new rules and attributes
dynamically with a
property editor ?
Maybe the trickiest part for the users would be to
learn the
syntax for rule expressions. In particular how to
refer
to object attributes within a rule.
--
Nick
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***
RE: server-side, java-based validation rules for struts..
You're right. It would be good to make the var
element use the body for the value.
Then you could do this.
var name=mask![CDATA[^[].*$]]/var
I'll add it to the list.
David
--- Rey Francois [EMAIL PROTECTED] wrote:
I'm not so much of an XML expert, but isn't the
CCDATA character section
offering a nice solution in order to preserve the
real look of a reg. exp.
in an XML file?
Fr.
-Original Message-
From: David Winterfeldt
[mailto:[EMAIL PROTECTED]]
Sent: 25 June 2001 18:11
To: [EMAIL PROTECTED]
Subject: RE: server-side, java-based validation
rules for struts..
Regular expressions should be:
^quot;\(?(\d{3})\)?[-| ]?(\d{3})[-|
]?(\d{4})$quot;
Properties file version
^\\\(?(\\d{3})\\)?[-| ]?(\\d{3})[-| ]?(\\d{4})\$
David
--- David Winterfeldt [EMAIL PROTECTED]
wrote:
When you are doing regular expressions you can
basically just cut and paste them from an example
and
escape out the few XML sensitive characters, but
you
have to escape out the escape characters in a java
properties file which I think makes something that
is
already hard to read even more unreadable. This
is
just a simple regular expression.
XML Version (phone number with double quotes
around
it)
quot;^\(?(\d{3})\)?[-| ]?(\d{3})[-|
]?(\d{4})$quot;
Properties file version
\^\\(?(\\d{3})\\)?[-| ]?(\\d{3})[-| ]?(\\d{4})$\
In a regular expression a '(' means something and
regular expressions also use '\' to escape out
characters except they don't match java's escape
characters. So '\\(' is escaping out a '\' which
is
then escaping a '('.
I did a project keeping all of my regular
expressions
in a properties file and I find keeping them in
xml
much more convenient. Of course if you were using
a
Java IDE then you wouldn't have to worry about
escaping out the java escape characters yourself,
but
not everyone uses a full blown IDE.
When I mentioned less technical people I meant
art/design people that use something like
Dreamweaver.
Dreamweaver already has basic support for JSP and
one
day it will probably support or have a plugin for
editing XML files. I don't think less technical
people are going to find a java IDE easier to use
than
an HTML editor if you use properties files. There
are
lots of generic XML editing packages so you don't
have
to hand roll your own xml editor. And there's
always
vi or notepad.
David
http://home.earthlink.net/~dwinterfeldt
--- Nick Afshartous
[EMAIL PROTECTED]
wrote:
Cook, Levi writes:
IMHO, expressing rules using first class Java
objects *can* be just as
flexible as defining rules in an XML file.
The analog to changing a value in an XML file
is
using a property editor to
change values stored in a JavaBean (thus
avoiding
recompiling). The upside
of this approach is simpler integration with
visual editors (simply
implement a property editor for your
form-bean).
Ultimately, I feel this is
where your less technical people can begin to
contribute more effectivly.
The other route requires hand-rolling a
visual
editor for your XML scheme
and/or having your users learn quite a bit
about
the intricacies of your
schema.
Thanks Levi for pointing out that a property
editor
could be used.
Could one also add new rules and attributes
dynamically with a
property editor ?
Maybe the trickiest part for the users would be
to
learn the
syntax for rule expressions. In particular how
to
refer
to object attributes within a rule.
--
Nick
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
The information in this email is confidential and is
intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised.
If you are not
an intended recipient, you must not read, use or
disseminate the
information contained in the email.
Any views expressed in this message are those of the
individual
sender, except where the sender specifically states
them to be
the views of Capco.
http://www.capco.com
***
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: server-side, java-based validation rules for struts..
Slightly more exact mechanics for registering the listeners are: 1. Instantiate the form-bean 2. Instantiate zero to many listeners 3. Register each listener [...] This sounds like it could be an expensive process to be going through on each request. I think you'd want to arrange for the listeners to be cacheable (by Struts) so that step 2 can be performed either at startup time or on first hit for a given listener. -- Martin Cooper - Original Message - From: Cook, Levi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 8:20 AM Subject: RE: server-side, java-based validation rules for struts.. Yes, the end result is ActionForms with Listeners registered prior to the ActionServlet populating our form with the users request values. Slightly more exact mechanics for registering the listeners are: 1. Instantiate the form-bean 2. Instantiate zero to many listeners 3. Register each listener using one of following bean method naming conventions: addPropertyNameVetoableChangeListener(VetoableChangeListener listener) addVetoableChangeListener(String propertyName, VetoableChangeListener listener) addVetoableChangeListener(VetoableChangeListener listener) A key abstraction here, is that neither object ever has an explicit reference to the other. Said another way this provides loose coupling between our action forms and their listeners. This supports the struts as a framework concept by allowing the following: 1. The number (zero to many) of listeners may be unknown at compile-time, and can vary throughout run-time. 2. Listener and form objects neet to be loosely coupled becuase we have no way of predicting all the Listeners (eg. Validations) users could be interested in. Abstraction sure seems difficult to explain sometimes, thanks again for helping me refine my explanation. Levi -Original Message- From: Jonathan [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 9:10 AM To: [EMAIL PROTECTED] Subject: Re: server-side, java-based validation rules for struts.. So you are saying that when an ActionForm is instantiated its associated listener(s) get shoved in (read registered) via a set method on the ActionForm, and the Listener actually does the registering of itself in its constructor or something. So what you have is a bunch of ActionsForms with their listeners already registered. Did I get it? - Original Message - From: Levi Cook [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 11:44 AM Subject: Re: server-side, java-based validation rules for struts.. I guess that's the critical part, eh-- sorry for the hand-waving :) At this point, I see the Struts controller coordinating these rules, based on the contents of struts-config.xml: 1. Instantiation of our form-bean as needed (no real change here). 2. Instantiation of optional change-listeners* associated with our form. (peek at the xml fragment below) 3. Now, it can register the change-listener (aka VetoableChangeListener), with our new form-bean. note: addPropertyNameVetoableChangeListener removePropertyNameVetoableChangeListener adhere to a naming pattern established by the JavaBeans spec. for more on this, see the last section on this page: http://java.sun.com/docs/books/tutorial/javabeans/properties/constrained.htm l Assuming that this is all happened smoothly, which I think is pretty safe, that leaves the following main question: -- What happens when Struts begins to populate our action form? A. Nothing, our users suddendly started getting everything right, so our Validators never complain about their input anymore. B. Our, the more probable route... our Validators start throwing PropertyVetoExceptions because our user's aren't any better at answering these questions than we are :) This point introduces the next responsibily I planned on handing the struts-controller: handling PropertyVetoExceptions. In short, I'd like it to basically turn these exceptions into ActionErrors for us. Hope this sounds a little clearer, thanks for the feedback-- I think it greatly influences the ideas quality. Regards, Levi Cook struts-config !-- etc.. -- form-bean name=myCCForm type=MyCCForm change-listener property=creditCard type=CreditCardValidator / /form-bean !-- etc.. -- /struts-config - Original Message - From: Jonathan Asbell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 4:42 AM Subject: Re: server-side, java-based validation rules for struts.. Levi, you lost me somewhere in your explanation from .now have to account for interacting with Struts-- That's where I see
RE: server-side, java-based validation rules for struts..
David Winterfeldt writes: I don't think there would be anything wrong with your idea, but I think it is a little more flexible keeping the validation separate from the ActionForm. I started working on a validation framework, but I put the info in an xml file. I would rather change a value in an xml file than having to recompile my code. * It makes the validation rules more accessible to less technical people. One day the XML might tie into a JSP editing tool to provide easy access and editing of the validation rules. I've been thinking of doing something similar for the logic rules associated with business objects. For example, consider an Employee class where the logic to calculate the bonus is based on some of the other attributes of the object (i.e. jobcode, location). It would be useful to define these rules in XML to facilitate maintenance as you point out for validation rules. -- Nick
RE: server-side, java-based validation rules for struts..
Anyone know of utilitiy that helps in editing the application resources. We currently keep the validation regular expression and masks in the applcation resources. This is convenient since some of these may be locale dependent. It would be nice to have a utility that help in adding to, select from the AplicationResource file. Forte for Jave has in-built tool for this, but it is only available when editing java source .java and not .jsp. Any clue on this Akin -Original Message- From: Nick Afshartous [mailto:[EMAIL PROTECTED]] Sent: Friday, June 22, 2001 1:44 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: server-side, java-based validation rules for struts.. David Winterfeldt writes: I don't think there would be anything wrong with your idea, but I think it is a little more flexible keeping the validation separate from the ActionForm. I started working on a validation framework, but I put the info in an xml file. I would rather change a value in an xml file than having to recompile my code. * It makes the validation rules more accessible to less technical people. One day the XML might tie into a JSP editing tool to provide easy access and editing of the validation rules. I've been thinking of doing something similar for the logic rules associated with business objects. For example, consider an Employee class where the logic to calculate the bonus is based on some of the other attributes of the object (i.e. jobcode, location). It would be useful to define these rules in XML to facilitate maintenance as you point out for validation rules. -- Nick
Re: server-side, java-based validation rules for struts..
I guess that's the critical part, eh-- sorry for the hand-waving :)
At this point, I see the Struts controller coordinating these rules, based
on the contents of struts-config.xml:
1. Instantiation of our form-bean as needed (no real change here).
2. Instantiation of optional change-listeners* associated with our form.
(peek at the xml fragment below)
3. Now, it can register the change-listener (aka
VetoableChangeListener), with our new form-bean.
note: addPropertyNameVetoableChangeListener
removePropertyNameVetoableChangeListener
adhere to a naming pattern established by the JavaBeans spec.
for more on this, see the last section on this page:
http://java.sun.com/docs/books/tutorial/javabeans/properties/constrained.htm
l
Assuming that this is all happened smoothly, which I think is pretty safe,
that leaves the following main question:
-- What happens when Struts begins to populate our action form?
A. Nothing, our users suddendly started getting everything right, so our
Validators never complain about their input anymore.
B. Our, the more probable route... our Validators start throwing
PropertyVetoExceptions because our user's aren't any better at answering
these questions than we are :)
This point introduces the next responsibily I planned on handing the
struts-controller: handling PropertyVetoExceptions. In short, I'd like it to
basically turn these exceptions into ActionErrors for us.
Hope this sounds a little clearer, thanks for the feedback-- I think it
greatly influences the ideas quality.
Regards,
Levi Cook
struts-config
!-- etc.. --
form-bean name=myCCForm type=MyCCForm
change-listener
property=creditCard
type=CreditCardValidator
/
/form-bean
!-- etc.. --
/struts-config
- Original Message -
From: Jonathan Asbell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 21, 2001 4:42 AM
Subject: Re: server-side, java-based validation rules for struts..
Levi, you lost me somewhere in your explanation from .now have to
account for interacting with Struts-- That's where I see
java.bean.VetoableChangeListener.
What are you passing to whom, and where are you instantiating and
registering things?
public MyCCForm extends ActionForm {
public setCreditCard(String newCreditCard) throws
PropertyVetoException
{
vcs.fireVetoableChange(CC_PROP_NAME, creditCard, newCreditCard);
creditCard= newCreditCard;
}
public void addCreditCardVetoableChangeListener(VetoableChangeListener
lsnr) {
vcs.addVetoableChangeListener(CC_PROP_NAME, lsnr);
}
private String creditCard;
private static final String CC_PROP_NAME= creditCard;
private VetoableChangeSupport vcs= new VetoableChangeSupport(this);
}
public class CreditCardValidator implements VetoableChangeListener {
public void vetoableChange(PropertyChangeEvent evt)
throws PropertyVetoException
{
String creditCard= null;
try {
creditCard= (String) evt.getNewValue();
}
finally {
if(StringValidator.isCreditCard(creditCard) == false)
throw new PropertyVetoException(some.msg.key, evt);
}
}
}
Re: server-side, java-based validation rules for struts..
So you are saying that when an ActionForm is instantiated its associated
listener(s) get shoved in (read registered) via a set method on the
ActionForm, and the Listener actually does the registering of itself in its
constructor or something.
So what you have is a bunch of ActionsForms with their listeners already
registered. Did I get it?
- Original Message -
From: Levi Cook [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 21, 2001 11:44 AM
Subject: Re: server-side, java-based validation rules for struts..
I guess that's the critical part, eh-- sorry for the hand-waving :)
At this point, I see the Struts controller coordinating these rules,
based
on the contents of struts-config.xml:
1. Instantiation of our form-bean as needed (no real change here).
2. Instantiation of optional change-listeners* associated with our
form.
(peek at the xml fragment below)
3. Now, it can register the change-listener (aka
VetoableChangeListener), with our new form-bean.
note: addPropertyNameVetoableChangeListener
removePropertyNameVetoableChangeListener
adhere to a naming pattern established by the JavaBeans spec.
for more on this, see the last section on this page:
http://java.sun.com/docs/books/tutorial/javabeans/properties/constrained.htm
l
Assuming that this is all happened smoothly, which I think is pretty safe,
that leaves the following main question:
-- What happens when Struts begins to populate our action form?
A. Nothing, our users suddendly started getting everything right, so our
Validators never complain about their input anymore.
B. Our, the more probable route... our Validators start throwing
PropertyVetoExceptions because our user's aren't any better at answering
these questions than we are :)
This point introduces the next responsibily I planned on handing the
struts-controller: handling PropertyVetoExceptions. In short, I'd like it
to
basically turn these exceptions into ActionErrors for us.
Hope this sounds a little clearer, thanks for the feedback-- I think it
greatly influences the ideas quality.
Regards,
Levi Cook
struts-config
!-- etc.. --
form-bean name=myCCForm type=MyCCForm
change-listener
property=creditCard
type=CreditCardValidator
/
/form-bean
!-- etc.. --
/struts-config
- Original Message -
From: Jonathan Asbell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 21, 2001 4:42 AM
Subject: Re: server-side, java-based validation rules for struts..
Levi, you lost me somewhere in your explanation from .now have to
account for interacting with Struts-- That's where I see
java.bean.VetoableChangeListener.
What are you passing to whom, and where are you instantiating and
registering things?
public MyCCForm extends ActionForm {
public setCreditCard(String newCreditCard) throws
PropertyVetoException
{
vcs.fireVetoableChange(CC_PROP_NAME, creditCard, newCreditCard);
creditCard= newCreditCard;
}
public void
addCreditCardVetoableChangeListener(VetoableChangeListener
lsnr) {
vcs.addVetoableChangeListener(CC_PROP_NAME, lsnr);
}
private String creditCard;
private static final String CC_PROP_NAME= creditCard;
private VetoableChangeSupport vcs= new VetoableChangeSupport(this);
}
public class CreditCardValidator implements VetoableChangeListener {
public void vetoableChange(PropertyChangeEvent evt)
throws PropertyVetoException
{
String creditCard= null;
try {
creditCard= (String) evt.getNewValue();
}
finally {
if(StringValidator.isCreditCard(creditCard) == false)
throw new PropertyVetoException(some.msg.key, evt);
}
}
}
Re: server-side, java-based validation rules for struts..
So at some point you will gat a handle to the ActionForm (read bean) and say: actionForm.addVetoableChangeListener(String propertyName,VetoableChangeListener listener) or actionForm.addVetoableChangeListener(VetoableChangeListener listener) or the third one which I dont totally understand. (please explain ;^ ) Also, please explain what the propertyName represents The best thing about this is that the associations between beans and their listeners is don all in one place (the xml file in our case). If you want to add listeners to a bean just add them to the file. One thing I may suggest is that maybe you dont need to be explicit with the type of listeners, and just register listeners. I 'm not sure, however, because I have not thought about the consequences of that yet. - Original Message - From: Cook, Levi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 11:20 AM Subject: RE: server-side, java-based validation rules for struts.. Yes, the end result is ActionForms with Listeners registered prior to the ActionServlet populating our form with the users request values. Slightly more exact mechanics for registering the listeners are: 1. Instantiate the form-bean 2. Instantiate zero to many listeners 3. Register each listener using one of following bean method naming conventions: addPropertyNameVetoableChangeListener(VetoableChangeListener listener) addVetoableChangeListener(String propertyName, VetoableChangeListener listener) addVetoableChangeListener(VetoableChangeListener listener) A key abstraction here, is that neither object ever has an explicit reference to the other. Said another way this provides loose coupling between our action forms and their listeners. This supports the struts as a framework concept by allowing the following: 1. The number (zero to many) of listeners may be unknown at compile-time, and can vary throughout run-time. 2. Listener and form objects neet to be loosely coupled becuase we have no way of predicting all the Listeners (eg. Validations) users could be interested in. Abstraction sure seems difficult to explain sometimes, thanks again for helping me refine my explanation. Levi -Original Message- From: Jonathan [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 9:10 AM To: [EMAIL PROTECTED] Subject: Re: server-side, java-based validation rules for struts.. So you are saying that when an ActionForm is instantiated its associated listener(s) get shoved in (read registered) via a set method on the ActionForm, and the Listener actually does the registering of itself in its constructor or something. So what you have is a bunch of ActionsForms with their listeners already registered. Did I get it? - Original Message - From: Levi Cook [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 11:44 AM Subject: Re: server-side, java-based validation rules for struts.. I guess that's the critical part, eh-- sorry for the hand-waving :) At this point, I see the Struts controller coordinating these rules, based on the contents of struts-config.xml: 1. Instantiation of our form-bean as needed (no real change here). 2. Instantiation of optional change-listeners* associated with our form. (peek at the xml fragment below) 3. Now, it can register the change-listener (aka VetoableChangeListener), with our new form-bean. note: addPropertyNameVetoableChangeListener removePropertyNameVetoableChangeListener adhere to a naming pattern established by the JavaBeans spec. for more on this, see the last section on this page: http://java.sun.com/docs/books/tutorial/javabeans/properties/constrained.htm l Assuming that this is all happened smoothly, which I think is pretty safe, that leaves the following main question: -- What happens when Struts begins to populate our action form? A. Nothing, our users suddendly started getting everything right, so our Validators never complain about their input anymore. B. Our, the more probable route... our Validators start throwing PropertyVetoExceptions because our user's aren't any better at answering these questions than we are :) This point introduces the next responsibily I planned on handing the struts-controller: handling PropertyVetoExceptions. In short, I'd like it to basically turn these exceptions into ActionErrors for us. Hope this sounds a little clearer, thanks for the feedback-- I think it greatly influences the ideas quality. Regards, Levi Cook struts-config !-- etc.. -- form-bean name=myCCForm type=MyCCForm change-listener property=creditCard type=CreditCardValidator / /form-bean !-- etc.. -- /struts-config
RE: server-side, java-based validation rules for struts..
comments below... -Original Message- From: Jonathan [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 10:38 AM To: [EMAIL PROTECTED] Subject: Re: server-side, java-based validation rules for struts.. So at some point you will gat a handle to the ActionForm (read bean) and say: Yes-- you in this case would actually be the Struts controller invoking the digester, which in turn would instantiate our listener and then register it with one of the methods below. actionForm.addVetoableChangeListener(String propertyName,VetoableChangeListener listener) or actionForm.addVetoableChangeListener(VetoableChangeListener listener) or the third one which I dont totally understand. (please explain ;^ ) The third form allows a listener to be notified of any and all VetoableChange events. Eg. Its not tied to any particular property on our ActionForm, but it can issue Vetos. A proposed syntax for struts-config could then be: form-beans form-bean name=MyForm type=com.myco.MyForm change-listeners change-listener type=com.myco.MyFormValidator/ change-listener property=somePropertyName type=com.myco.SomePropertyValidator/ /change-listeners /form-bean /form-beans Also, please explain what the propertyName represents propertyName is simply shorthand for reffering to the name of a bean property. eg propertyName = field name = member variable name = etc. The best thing about this is that the associations between beans and their listeners is don all in one place (the xml file in our case). If you want to add listeners to a bean just add them to the file. Correct-- For the really adventurous, you could take this a step further and explore using IBM's Bean Markup Language for defining your ActionForms. @see http://www.alphaworks.ibm.com/tech/bml One thing I may suggest is that maybe you dont need to be explicit with the type of listeners, and just register listeners. I 'm not sure, however, because I have not thought about the consequences of that yet. I guess I didn't quite follow this last point. -- Levi
Re: server-side, java-based validation rules for struts..
I haven't had time yet to reorganize the code to
separate out validations into pure boolean validation
methods. The interface that is there now wasn't the
original one and has evolved over time. When I have
free time, I've normally focused on adding
functionality over reorganizing the source code.
David
--- Levi Cook [EMAIL PROTECTED] wrote:
comments below...
- Original Message -
From: Jonathan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 20, 2001 12:55 PM
Subject: Re: server-side, java-based validation
rules for struts..
Hello Levi.
I read your comment yesterday and went and read
about constrained
properties
and bound properties in section 7.4 of the java
beans spec link you sent.
I
think people didnt answer because you didnt speak
enough about what you
are
suggesting in the context of what has already been
developed. I think the
veto idea is interesting, but it doesnt replace
what is being developed,
but rather only adds to it.
I agree, this proposal is not a replacement for the
things being developed
to date.
The main point is that the JavaBeans approach
provides an established,
proven
framework for pluggable validation rules.
That said, its certainly feasible that adopting this
approach could ripple
into existing work. In general, I think it will
promote looser coupling
between struts objects and validation rules.
For instance, let's consider Dave W's
Validator.validateCreditCard method.
Its signature goes something like this:
0: public void validateCreditCard(
1: java.lang.Object bean,
2: ValidatorAction va,
3: Field field,
4: org.apache.struts.action.ActionErrors
errors,
5: javax.servlet.http.HttpServletRequest
request,
6: javax.servlet.ServletContext application
7:)
Now, I like Dave's work quite a bit, and I don't
want to sound like a
critic.
Nonetheless, there are several opportunities to
reduce coupling in this
method.
I would refactor validateCreditCard into a simple
utility method.
eg. public static boolean isCreditCard(String
ccNumber) {..}
Once that's in place (and tested :), I now have to
account for interacting
with
Struts-- That's where I see
java.bean.VetoableChangeListener helping out.
Basically I'd suggest doing the following (in
whatever order you prefer):
1. Create my actionform
2. Create my VetoableChangeListener
3. Add my form its change-listener/validator to
struts-config
From there, I would expect Struts to handle the
rest.. Where the rest is:
1. Call addCreditCardVetoableChangeListener()
passing in a new
instance of CreditCardValidator.
2. Catch any PropertyVetoExceptions throw by
setCreditCard
and turn them into ActionErrors.
3. Return the control to the user w/ there actual
input values
and a sensible message indicating how to correct
the err.
public MyCCForm extends ActionForm {
public setCreditCard(String newCreditCard) throws
PropertyVetoException {
vcs.fireVetoableChange(CC_PROP_NAME, creditCard,
newCreditCard);
creditCard= newCreditCard;
}
public void
addCreditCardVetoableChangeListener(VetoableChangeListener
lsnr) {
vcs.addVetoableChangeListener(CC_PROP_NAME,
lsnr);
}
private String creditCard;
private static final String CC_PROP_NAME=
creditCard;
private VetoableChangeSupport vcs= new
VetoableChangeSupport(this);
}
public class CreditCardValidator implements
VetoableChangeListener {
public void vetoableChange(PropertyChangeEvent
evt)
throws PropertyVetoException
{
String creditCard= null;
try {
creditCard= (String) evt.getNewValue();
}
finally {
if(StringValidator.isCreditCard(creditCard) ==
false)
throw new
PropertyVetoException(some.msg.key, evt);
}
}
}
struts-config
!-- etc.. --
form-bean name=myCCForm type=MyCCForm
change-listener
property=creditCard
type=CreditCardValidator
/
/form-bean
!-- etc.. --
/struts-config
It could be added of course. But the validations
that have been
developed
and discussed thus far go much farther than what
the beans offer.
The fact that they do go farther is one of the
reasons I felt it was
necessary
find a slightly more abstract approach. Said another
way, concrete
validations
are great (especially the commonly required
validation like is s an email
address)
however, we will never be able to supply all
At this stage, I'm not claiming its an adequate, or
appropriate abstaction,
but I definitly feel its a candidate.
We have been trying to actually build (and some
have like Dave
Winderfeldt)
a bunch of validations for common problems like
credit cards, emails, money etc. In fact the java
beans spec doesnt
address
what is involved in validating an e-mail ,phone
number etc., but rather a
general concept in implementing something you have
validated
RE: server-side, java-based validation rules for struts..
Hi David, I would like to emphasize that I truly do not intend to criticize or belittle your work. I really do appreciate and respect your efforts to give Struts a boost. My only agenda is simply trying to expand the flexibility of our tools and enhance there ability to be learned and reused. Maybe I'm not doing that yet, but its where I'm trying to go :) Respectfully, Levi Cook -Original Message- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 11:17 AM To: [EMAIL PROTECTED] Subject: Re: server-side, java-based validation rules for struts.. I haven't had time yet to reorganize the code to separate out validations into pure boolean validation methods. The interface that is there now wasn't the original one and has evolved over time. When I have free time, I've normally focused on adding functionality over reorganizing the source code. David
RE: server-side, java-based validation rules for struts..
I didn't take offense at what you said. I just wanted to acknowledge it was something I wanted to do and eventually things would be more reusable, but I haven't had time to address this issue as the code has changed. I would like to have things separated more with layers and interfaces so other people can use the pieces they want or put in a different interface for the validators so it could be used on other platforms besides Struts. David --- Cook, Levi [EMAIL PROTECTED] wrote: Hi David, I would like to emphasize that I truly do not intend to criticize or belittle your work. I really do appreciate and respect your efforts to give Struts a boost. My only agenda is simply trying to expand the flexibility of our tools and enhance there ability to be learned and reused. Maybe I'm not doing that yet, but its where I'm trying to go :) Respectfully, Levi Cook -Original Message- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 11:17 AM To: [EMAIL PROTECTED] Subject: Re: server-side, java-based validation rules for struts.. I haven't had time yet to reorganize the code to separate out validations into pure boolean validation methods. The interface that is there now wasn't the original one and has evolved over time. When I have free time, I've normally focused on adding functionality over reorganizing the source code. David __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
RE: server-side, java-based validation rules for struts..
I'm guessing my aforementioned ideas on validation fall into one of the following categories: 1. its was a really bad idea, not worth commenting or elaborating on 2. i didn't provide a clearly articulated idea to review 3. they're fine and everyone's really busy, and i'm impatient I'll assume its items mostly 3, and will apologize in advance for seeming impatient. However, does anyone care to comment on its viability?? Should I proceed with making a more formal proposal?? Does this miss the mark totally for framework based validation?? If I failed on item 2, what's missing?? (scope, applicability, etc..) Sorry to be a bug, I truly appreciate everyone's time and effort with Struts. -- Levi -Original Message- From: Levi Cook [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 11:58 AM To: [EMAIL PROTECTED] Subject: server-side, java-based validation rules for struts.. I believe its well established that Struts would benefit from a good validation framework (duh, right?). While there are a number of really good ideas floating around, some seem to be introducing unnecessary complexity (IMHO, of course) Getting to the point, I think constrained properties from the JavaBeans spec. provides a built in, flexible foundation for struts invoked validation. (http://java.sun.com/products/javabeans/docs/spec.html) key advantages: * support is provided by the standard java.beans package * it doesn't require learning anything proprietary (even though other solutions are very cool :) * its conceptually simple; ie. before accepting a new value, the bean/ActionForm's setter method(s) ensures its accepted by all registered listeners before commiting the value (java.bean.VetoableChangeListenter). * and finally, its wide open for extension (key since we can't predict all validation scenario's, right?) I also believe that integration with Struts could be pretty straight forward. In a nutshell, we could make 2 modifications ActionServlet: 1. Make it responsible for registering change-listeners 2. Make it handle PropertyVetoException(s) thrown by setter methods (primarily by turning them into ActionErrors) Prior to making a formal proposal for this, I thought it might be useful to consider the attached code fragments: Then again, maybe I'm way off and should be ignored- If I am, let me know.. Regards, Levi Cook
Re: server-side, java-based validation rules for struts..
Hello Levi. I read you rcomment yesterday and went and read about constrained properties and bound properties in section 7.4 of the java beans spec link you sent. I think people didnt answer because you didnt speak enough about what you are suggesting in the context of what has already been developed. I think the veto idea is interesting, but it doesnt replace what is being developed, but rather only adds to it. It could be added of course. But the validations that have been developed and discussed thus far go much farther than what the beans offer. We have been trying to actually build (and some have like Dave Winderfeldt) a bunch of validations for common problems like credit cards, emails, money etc. In fact the java beans spec doesnt address what is involved in validating an e-mail ,phone number etc., but rather a general concept in implementing something you have validated via some algorithm etc.etc. Check out some of the various posts about validation and you will see what I mean. ;^ - Original Message - From: Cook, Levi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 3:48 PM Subject: RE: server-side, java-based validation rules for struts.. I'm guessing my aforementioned ideas on validation fall into one of the following categories: 1. its was a really bad idea, not worth commenting or elaborating on 2. i didn't provide a clearly articulated idea to review 3. they're fine and everyone's really busy, and i'm impatient I'll assume its items mostly 3, and will apologize in advance for seeming impatient. However, does anyone care to comment on its viability?? Should I proceed with making a more formal proposal?? Does this miss the mark totally for framework based validation?? If I failed on item 2, what's missing?? (scope, applicability, etc..) Sorry to be a bug, I truly appreciate everyone's time and effort with Struts. -- Levi -Original Message- From: Levi Cook [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 11:58 AM To: [EMAIL PROTECTED] Subject: server-side, java-based validation rules for struts.. I believe its well established that Struts would benefit from a good validation framework (duh, right?). While there are a number of really good ideas floating around, some seem to be introducing unnecessary complexity (IMHO, of course) Getting to the point, I think constrained properties from the JavaBeans spec. provides a built in, flexible foundation for struts invoked validation. (http://java.sun.com/products/javabeans/docs/spec.html) key advantages: * support is provided by the standard java.beans package * it doesn't require learning anything proprietary (even though other solutions are very cool :) * its conceptually simple; ie. before accepting a new value, the bean/ActionForm's setter method(s) ensures its accepted by all registered listeners before commiting the value (java.bean.VetoableChangeListenter). * and finally, its wide open for extension (key since we can't predict all validation scenario's, right?) I also believe that integration with Struts could be pretty straight forward. In a nutshell, we could make 2 modifications ActionServlet: 1. Make it responsible for registering change-listeners 2. Make it handle PropertyVetoException(s) thrown by setter methods (primarily by turning them into ActionErrors) Prior to making a formal proposal for this, I thought it might be useful to consider the attached code fragments: Then again, maybe I'm way off and should be ignored- If I am, let me know.. Regards, Levi Cook
RE: server-side, java-based validation rules for struts..
I don't think there would be anything wrong with your idea, but I think it is a little more flexible keeping the validation separate from the ActionForm. I started working on a validation framework, but I put the info in an xml file. I would rather change a value in an xml file than having to recompile my code. * It makes the validation rules more accessible to less technical people. One day the XML might tie into a JSP editing tool to provide easy access and editing of the validation rules. * I think it makes it easier to generate JavaScript that has the same information you pass into the java validation method. * It let's you decouple the actual code that performs a validation from the validation. You can just say a field is required and if you redefine what class/method performs the required validation you won't need to change anything else. (not that you couldn't do this with an interface you've created too) * When the exception/validation happens in the setter, you can't do things that depend on other fields. Like this field is required only if another field is filled in. These are a couple of thoughts off the top of my head. Here is a link to what I've done so far. http://home.earthlink.net/~dwinterfeldt David --- Cook, Levi [EMAIL PROTECTED] wrote: I'm guessing my aforementioned ideas on validation fall into one of the following categories: 1. its was a really bad idea, not worth commenting or elaborating on 2. i didn't provide a clearly articulated idea to review 3. they're fine and everyone's really busy, and i'm impatient I'll assume its items mostly 3, and will apologize in advance for seeming impatient. However, does anyone care to comment on its viability?? Should I proceed with making a more formal proposal?? Does this miss the mark totally for framework based validation?? If I failed on item 2, what's missing?? (scope, applicability, etc..) Sorry to be a bug, I truly appreciate everyone's time and effort with Struts. -- Levi -Original Message- From: Levi Cook [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 11:58 AM To: [EMAIL PROTECTED] Subject: server-side, java-based validation rules for struts.. I believe its well established that Struts would benefit from a good validation framework (duh, right?). While there are a number of really good ideas floating around, some seem to be introducing unnecessary complexity (IMHO, of course) Getting to the point, I think constrained properties from the JavaBeans spec. provides a built in, flexible foundation for struts invoked validation. (http://java.sun.com/products/javabeans/docs/spec.html) key advantages: * support is provided by the standard java.beans package * it doesn't require learning anything proprietary (even though other solutions are very cool :) * its conceptually simple; ie. before accepting a new value, the bean/ActionForm's setter method(s) ensures its accepted by all registered listeners before commiting the value (java.bean.VetoableChangeListenter). * and finally, its wide open for extension (key since we can't predict all validation scenario's, right?) I also believe that integration with Struts could be pretty straight forward. In a nutshell, we could make 2 modifications ActionServlet: 1. Make it responsible for registering change-listeners 2. Make it handle PropertyVetoException(s) thrown by setter methods (primarily by turning them into ActionErrors) Prior to making a formal proposal for this, I thought it might be useful to consider the attached code fragments: Then again, maybe I'm way off and should be ignored- If I am, let me know.. Regards, Levi Cook __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
RE: server-side, java-based validation rules for struts..
Hi All, Thanks for the replies, I now feel less lost in the ether :) You each brought up excellent points which I believe are address-able. Ultimately, I guess a working example sounds best for exploring these ideas.. I'll try to post something back over the weekend on this. Until then, I'll try to respond inline with your messages. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 20, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: Re: server-side, java-based validation rules for struts.. +1 David Winterfeldt wrote: I don't think there would be anything wrong with your idea, but I think it is a little more flexible keeping the validation separate from the ActionForm. I started working on a validation framework, but I put the info in an xml file. I would rather change a value in an xml file than having to recompile my code. My thinking is the JavaBeans approach keeps coupling between validation and ActionForms very low. In fact, the collaboration between an ActionForm and its Validators should remain completely declaritave. For instance, if you have an optional date on your form, and you wanted to ues a Jakarta provided date validator you could say something like this: struts-config form-bean name=myForm type=MyForm change-listener property=myDate type=org.apache.struts...OptionalDateValidator / /form-bean /struts-config As for recompiling, don't do it, just keep on creating lowly coupled validation rules. eg. RequiredDateValidator RequiredEmailAddressValidator OptionalNumericValidator etc. I think the java.bean.VetoableChangeListenter would be a good thing in an helper bean that was populated by an ActionForm bean, but would violate the API contract for an ActionForm bean. The ActionFormBean is suppose to accept whatever the actor throws at it, and then perform validation. This way we can return exactly what they entered for correction. The point you make on Contract is a good one. It might mean modifing our response processing a little, however, I don't think we lose support for it. Bascially, the user submitted value is accessible via: PropertyVetoException -- getPropertyChangeEvent() -- getOldValue() -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ -- Levi
Re: server-side, java-based validation rules for struts..
comments below...
- Original Message -
From: Jonathan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 20, 2001 12:55 PM
Subject: Re: server-side, java-based validation rules for struts..
Hello Levi.
I read your comment yesterday and went and read about constrained
properties
and bound properties in section 7.4 of the java beans spec link you sent.
I
think people didnt answer because you didnt speak enough about what you
are
suggesting in the context of what has already been developed. I think the
veto idea is interesting, but it doesnt replace what is being developed,
but rather only adds to it.
I agree, this proposal is not a replacement for the things being developed
to date.
The main point is that the JavaBeans approach provides an established,
proven
framework for pluggable validation rules.
That said, its certainly feasible that adopting this approach could ripple
into existing work. In general, I think it will promote looser coupling
between struts objects and validation rules.
For instance, let's consider Dave W's Validator.validateCreditCard method.
Its signature goes something like this:
0: public void validateCreditCard(
1: java.lang.Object bean,
2: ValidatorAction va,
3: Field field,
4: org.apache.struts.action.ActionErrors errors,
5: javax.servlet.http.HttpServletRequest request,
6: javax.servlet.ServletContext application
7:)
Now, I like Dave's work quite a bit, and I don't want to sound like a
critic.
Nonetheless, there are several opportunities to reduce coupling in this
method.
I would refactor validateCreditCard into a simple utility method.
eg. public static boolean isCreditCard(String ccNumber) {..}
Once that's in place (and tested :), I now have to account for interacting
with
Struts-- That's where I see java.bean.VetoableChangeListener helping out.
Basically I'd suggest doing the following (in whatever order you prefer):
1. Create my actionform
2. Create my VetoableChangeListener
3. Add my form its change-listener/validator to struts-config
From there, I would expect Struts to handle the rest.. Where the rest is:
1. Call addCreditCardVetoableChangeListener() passing in a new
instance of CreditCardValidator.
2. Catch any PropertyVetoExceptions throw by setCreditCard
and turn them into ActionErrors.
3. Return the control to the user w/ there actual input values
and a sensible message indicating how to correct the err.
public MyCCForm extends ActionForm {
public setCreditCard(String newCreditCard) throws PropertyVetoException {
vcs.fireVetoableChange(CC_PROP_NAME, creditCard, newCreditCard);
creditCard= newCreditCard;
}
public void addCreditCardVetoableChangeListener(VetoableChangeListener
lsnr) {
vcs.addVetoableChangeListener(CC_PROP_NAME, lsnr);
}
private String creditCard;
private static final String CC_PROP_NAME= creditCard;
private VetoableChangeSupport vcs= new VetoableChangeSupport(this);
}
public class CreditCardValidator implements VetoableChangeListener {
public void vetoableChange(PropertyChangeEvent evt)
throws PropertyVetoException
{
String creditCard= null;
try {
creditCard= (String) evt.getNewValue();
}
finally {
if(StringValidator.isCreditCard(creditCard) == false)
throw new PropertyVetoException(some.msg.key, evt);
}
}
}
struts-config
!-- etc.. --
form-bean name=myCCForm type=MyCCForm
change-listener
property=creditCard
type=CreditCardValidator
/
/form-bean
!-- etc.. --
/struts-config
It could be added of course. But the validations that have been
developed
and discussed thus far go much farther than what the beans offer.
The fact that they do go farther is one of the reasons I felt it was
necessary
find a slightly more abstract approach. Said another way, concrete
validations
are great (especially the commonly required validation like is s an email
address)
however, we will never be able to supply all
At this stage, I'm not claiming its an adequate, or appropriate abstaction,
but I definitly feel its a candidate.
We have been trying to actually build (and some have like Dave
Winderfeldt)
a bunch of validations for common problems like
credit cards, emails, money etc. In fact the java beans spec doesnt
address
what is involved in validating an e-mail ,phone number etc., but rather a
general concept in implementing something you have validated via some
algorithm etc.etc. Check out some of the various posts about validation
and
you will see what I mean.
;^
