formproc-developer — Developer interests

RE: [FormProc-developer] Integradata and FormProc working together

[Anthony E. <me...@an...>]

Right now there is a single error message for each field because there is a
single validator.  I can see the value in allowing error messages for each
validator though.

As far as multiple validators I have checked in a class to CVS called
FormValidatorGroup.  I have not yet added the configuration routines, but it
is essentially a collection of FormValidators which must all be valid for a
successful validation.  The FormValidatorGroup extends from
AbstractFormValidator so it can be used in the same place as any other
FormValidator.

I will add the configuration logic tomorrow.

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of Nick
> Bauman
> Sent: Monday, November 19, 2001 3:32 PM
> To: for...@li...
> Subject: Re: [FormProc-developer] Integradata and FormProc working
> together
>
>
> > This is a suggestion for future development.  I think it would be a
> > 'nice-to-have' feature.
> >
> > I was looking at Nick Bauman's API and noticed that his RuleResult
> > class holds the error message while FormProc's getMessage method is in
> > the FormElement.
>
> Correct, and I know this is a problem with Integradata. However,
> my thinking
> is this:
>
> I like that Anthony has I18N error messages "built right in", which
> Integradata doesn't have (right now). He does this by putting the error
> message in the XML. But since the Rule knows why, how and when
> it's field is
> invalid, the Rule should return a specific result code, which
> then is mapped
> to subsequent I18N responses, either in a properties file in the distro or
> in the XML. The point is, you shouldn't be forced to put the error message
> in there if you don't want to.
>
> Also, Integradata will soon optionally autogenerate Javascript validation
> functions for validation _on the front end_ too, which I hope
> Anthony's lib
> will be able to adopt as well!
>
> This is where Integradata is going. If we can go there together, we can
> leverage the strengths of choice, cohesiveness of each other's parts and
> scale the maintainability appropriately: a win-win for both FormProc and
> Integradata.
>
> > It looks to me like this design prevents FormProc from being able to
> > implement multiple rules.
>
> If this is true, this is definitely a problem. Integradata does not have
> this limitation. Your illustration of a valid case for having
> multiple rules
> per field is right on the money.
>
> > For example, I think it would be useful to be able to configure a field
> > like this:
> >
> > <element name="postalcode">
> >
> >   <!-- Rule for making the field required -->
> >   <validator type="rule">
> >     <rule>org.formproc.example.RequiredRule</rule>
> >     <error lang="en">This field is required</error>
> >   </validator>
> >
> >   <!-- Rule for validating a Canadian Postal Code -->
> >   <validator type="rule">
> >     <rule>org.formproc.example.CanPostalCodeRule</rule>
> >     <error lang="en">This is not a valid Canadian Postal Code</error>
> >   </validator>
> >
> >   <message lang="en">Please enter a valid postal code</message>
> >
> > </element>
> >
> >
> > The first rule would be evaluated, and if the field is blank then the
> > user would be given the "This field is required" message.  If the field
> > is entered, but the postal code is invalid, then the second rule is
> > evaluated and he/she would be presented with the invalid postal code
> > message.
> >
> > It also seems logical to me that the error message would be a property
> > of the validator for a particular field.
> >
> > This change might make porting/merging Nick's rules easier as well.
>
> Yup, agreed.
>
> >
> > Regards,
> > -Kerry
> >
> > --
> > Kerry Todyruik <ke...@to...>
> >
> > _______________________________________________
> > FormProc-developer mailing list
> > For...@li...
> > https://lists.sourceforge.net/lists/listinfo/formproc-developer
>
>
> --
> Nick Bauman
> Cortexity Development
> Intellectual Process is more important than
> Intellectual Property -- you'll see.
> http://www.cortexity.com/
>
>
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>
>

RE: [FormProc-developer] Getting an iteration of the form element names

[Anthony E. <me...@an...>]

There is no method at this time to enumerate through the element names.
Would you expect the list to be in the same order as defined in the
configuration or in some other order?  Or does it not matter what order they
are in?  I suppose that the list should also be passed through the
Collections.unmodifiableList() method first.

I wonder: should it be possible to configure forms programtically?  Should
you be able to add new FormElement objects to FormConfiguration?  What other
areas should be programitically accessible which are not?

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of
> Kerry Todyruik
> Sent: Monday, November 19, 2001 7:35 PM
> To: for...@li...
> Subject: [FormProc-developer] Getting an iteration of the form element
> names
>
>
> I am using the Apache Velocity template engine.  To reduce the code in
> my template, I would like to retrieve a list of the names of the form
> elements.  It doesn't look like there is a method to retrieve this yet.
> How should I go about this?
>
> It looks like I could get a FormConfiguration object for the form from
> the FormManager.  Then if there was an accessor method in the
> FormConfiguration that would make the private formElements Map
> available, I could use that.
>
> Alternatively, I could write a getFieldNames method that processes the
> formElements Map, putting the names in a list and returning that list or
> iterator.
>
> If I could get some feedback on what would be an acceptible addition, I
> will code the method and then post it to the mailing list.
>
> Regards,
> -Kerry
>
> --
> Kerry Todyruik <ke...@to...>
>
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>
>

RE: [FormProc-developer] FormElement.java Bug

[Anthony E. <me...@an...>]

Fixed in CVS.

-Anthony

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of
> Kerry Todyruik
> Sent: Monday, November 19, 2001 6:42 PM
> To: for...@li...
> Subject: [FormProc-developer] FormElement.java Bug
> 
> 
> All of the error messages have been returning null.  I found this bug in
> FormElement.java
> 
> Line 194:
> 
> Iterator errorMessageElements = element.getChildren("error",
> NS).iterator();
> while(messageElements.hasNext()){
>    Element errorMessageElement = (Element)errorMessageElements.next();
>    String lang = errorMessageElement.getAttributeValue("lang");
>    errorMessages.put(lang, errorMessageElement.getTextTrim());
> }
> 
> Should be:
> 
> Iterator errorMessageElements = element.getChildren("error",
> NS).iterator();
> while(errorMessageElements.hasNext()){
>    Element errorMessageElement = (Element)errorMessageElements.next();
>    String lang = errorMessageElement.getAttributeValue("lang");
>    errorMessages.put(lang, errorMessageElement.getTextTrim());
> }
> 
> -- 
> Kerry Todyruik <ke...@to...>
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> 
> 

RE: [FormProc-developer] build.sh

[Anthony E. <me...@an...>]

Thanks, Kerry.  I have commited it to CVS and have added you as a
contributor.  Are you interested in becoming a full-fledge developer with
CVS write access?

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of
> Kerry Todyruik
> Sent: Monday, November 19, 2001 3:00 PM
> To: for...@li...
> Subject: [FormProc-developer] build.sh
>
>
> Hi.  Appologies for forgetting the subject line in my last post... :-)
>
> Could somebody add build.sh for the Linux/Unix people to the FormProc
> source tree?  Here is one I used yesterday to compile FormProc.  Use
> this if you like:
>
>
>
> #! /bin/sh
>
> if [ -z "$JAVA_HOME" ] ; then
>   JAVA=`which java`
>   if [ -z "$JAVA" ] ; then
>     echo "Cannot find JAVA. Please set your PATH."
>     exit 1
>   fi
>   JAVA_BIN=`dirname $JAVA`
>   JAVA_HOME=$JAVA_BIN/..
> fi
>
> JAVA=$JAVA_HOME/bin/java
>
> CLASSPATH=`echo lib/*.jar | tr ' ' ':'`
> CLASSPATH=build-lib/ant.jar:build/classes/:$CLASSPATH:$JAVA_HOME/l
> ib/tools.jar
>
> $JAVA -classpath $CLASSPATH -Dant.home=lib org.apache.tools.ant.Main
> "$@" -buildfile build.xml
>
>
>
> --
> Kerry Todyruik <ke...@to...>
>
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>
>

RE: [FormProc-developer] XML Configuration file format

[Anthony E. <me...@an...>]

> Other projects that employ XML configuration files (Castor, Tomcat,
> Poolman, etc.) use concise, simple tag names.  Wouldn't it be more
> straightforward to read and maintain if 'formproc:'  was removed from
> the tags in the formproc.xml and example-form.xml files?

I agree and thus have removed all name spaces from the XML configuration
files.  I probably should have made them optional, but since FormProc is in
alpha state I suppose now is a good time to make these kinds of changes.

Sincerely,
Anthony Eden

RE: [FormProc-developer] New rules written

[Anthony E. <me...@an...>]

> Anthony,
>
> I've written a bunch of rules, but they are for my own framework.
> My desire
> is to see if we can write some kind of bridge that will allow my
> rules to be
> plugged into your framework without me having to develop in the FormProc
> tree. Can we agree this is a worthy goal? If not, you could always cut and
> paste, and I would be fine with that, but that means we miss out on long
> term cohesiveness and maintainability.

As long as your rules implement the org.formproc.validation.Rule interface
then you should be able to use them in FormProc.  You could also create a
wrapper Rule which just executes your rules through some interface you
design.  Two things make this possible: 1.) Rule implementations are
specified in the XML file and 2.) you can pass any XML configuration data to
you rule through the configure(Element element) method of the Rule
interface.

If this is not sufficient then tell me what you have in mind.

Sincerely,
Anthony Eden

RE: [FormProc-developer] Some Comments

[Anthony E. <me...@an...>]

> Hello.
>
> I've been trying out FormProc the last couple of days.  Overall, I think
> it is an excellent tool.  Very nice work!  I would like to share some of
> my impressions being a first time user.  I also have a few questions.

Thanks.  I always look forward to comments and questions from others.

>
> My first question is how do you set up a field with no validator?  When
> I configure a field like:
>
> <formproc:element name="address" />
>
> or even
>
> <formproc:element name="address">
>     <formproc:write-method>setAddress</formproc:write-method>
> </formproc:element>
>
> It throws a ResourceException.  Correct me if I'm wrong, but this field
> configuration seems valid.  if not, an exception with some description
> of the problem would be helpful.  Like "ResourceException: Missing
> required --- tag" for example.

I have modified the source in the CVS to allow both forms of the element
method as described above.

>
> Secondly, I received this error that seems due to the fact that I had
> fields in my form that were not included in the configuration file:
>
> [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - Starting
> FileMonitor
> [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - FileMonitor
> running.
> [DEBUG]:org.formproc.FormManager - Formproc configuration loaded
> [DEBUG]:org.formproc.servlet.HttpForm - Processing servlet request.
> [DEBUG]:org.formproc.Form - Validating field action
> [DEBUG]:org.formproc.Form - getName: action
> [DEBUG]:org.formproc.Form - Found form element.
> java.lang.NullPointerException
> 	at org.formproc.Form.validate(Form.java:300)
> 	at org.formproc.Form.process(Form.java:266)
> 	at org.formproc.servlet.HttpForm.process(HttpForm.java:38)
> 	at EntryForm.handle(EntryForm.java:49)
>
> Wouldn't it be better to gracefully ignore fields in the form that are
> not included in the xml configuration file?  Or at least throw a
> meaningfull exception with some description of the problem with the
> config file?

I have modified the source code in the CVS so that fields which are not in
the XML configuration are ignored.  I have created a new class
PassFormValidator which implements this functionality.

I have not tested these modifications yet, but I have modified the example
app to simulate this new behavior - I just need to run it.

Sincerely,
Anthony Eden

[FormProc-developer] Getting an iteration of the form element names

[Kerry T. <ke...@to...>]

I am using the Apache Velocity template engine.  To reduce the code in
my template, I would like to retrieve a list of the names of the form
elements.  It doesn't look like there is a method to retrieve this yet. 
How should I go about this?

It looks like I could get a FormConfiguration object for the form from
the FormManager.  Then if there was an accessor method in the
FormConfiguration that would make the private formElements Map
available, I could use that.

Alternatively, I could write a getFieldNames method that processes the
formElements Map, putting the names in a list and returning that list or
iterator.

If I could get some feedback on what would be an acceptible addition, I
will code the method and then post it to the mailing list.

Regards,
-Kerry

-- 
Kerry Todyruik <ke...@to...>

[FormProc-developer] FormElement.java Bug

[Kerry T. <ke...@to...>]

All of the error messages have been returning null.  I found this bug in
FormElement.java

Line 194:

Iterator errorMessageElements = element.getChildren("error",
NS).iterator();
while(messageElements.hasNext()){
   Element errorMessageElement = (Element)errorMessageElements.next();
   String lang = errorMessageElement.getAttributeValue("lang");
   errorMessages.put(lang, errorMessageElement.getTextTrim());
}

Should be:

Iterator errorMessageElements = element.getChildren("error",
NS).iterator();
while(errorMessageElements.hasNext()){
   Element errorMessageElement = (Element)errorMessageElements.next();
   String lang = errorMessageElement.getAttributeValue("lang");
   errorMessages.put(lang, errorMessageElement.getTextTrim());
}

-- 
Kerry Todyruik <ke...@to...>

Re: [FormProc-developer] Integradata and FormProc working together

[Nick B. <ni...@co...>]

> This is a suggestion for future development.  I think it would be a
> 'nice-to-have' feature.
> 
> I was looking at Nick Bauman's API and noticed that his RuleResult
> class holds the error message while FormProc's getMessage method is in
> the FormElement.

Correct, and I know this is a problem with Integradata. However, my thinking
is this:

I like that Anthony has I18N error messages "built right in", which
Integradata doesn't have (right now). He does this by putting the error
message in the XML. But since the Rule knows why, how and when it's field is
invalid, the Rule should return a specific result code, which then is mapped
to subsequent I18N responses, either in a properties file in the distro or
in the XML. The point is, you shouldn't be forced to put the error message
in there if you don't want to. 

Also, Integradata will soon optionally autogenerate Javascript validation
functions for validation _on the front end_ too, which I hope Anthony's lib
will be able to adopt as well!

This is where Integradata is going. If we can go there together, we can
leverage the strengths of choice, cohesiveness of each other's parts and
scale the maintainability appropriately: a win-win for both FormProc and
Integradata.

> It looks to me like this design prevents FormProc from being able to
> implement multiple rules.

If this is true, this is definitely a problem. Integradata does not have
this limitation. Your illustration of a valid case for having multiple rules
per field is right on the money.

> For example, I think it would be useful to be able to configure a field
> like this:
> 
> <element name="postalcode">
> 
>   <!-- Rule for making the field required -->
>   <validator type="rule">
>     <rule>org.formproc.example.RequiredRule</rule>
>     <error lang="en">This field is required</error>
>   </validator>
> 
>   <!-- Rule for validating a Canadian Postal Code -->
>   <validator type="rule">
>     <rule>org.formproc.example.CanPostalCodeRule</rule>
>     <error lang="en">This is not a valid Canadian Postal Code</error>
>   </validator>
> 
>   <message lang="en">Please enter a valid postal code</message>
> 
> </element>
> 
> 
> The first rule would be evaluated, and if the field is blank then the
> user would be given the "This field is required" message.  If the field
> is entered, but the postal code is invalid, then the second rule is
> evaluated and he/she would be presented with the invalid postal code
> message.
> 
> It also seems logical to me that the error message would be a property
> of the validator for a particular field.
> 
> This change might make porting/merging Nick's rules easier as well.

Yup, agreed.

> 
> Regards,
> -Kerry
> 
> -- 
> Kerry Todyruik <ke...@to...>
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer


-- 
Nick Bauman 
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/

[FormProc-developer] build.sh

[Kerry T. <ke...@to...>]

Hi.  Appologies for forgetting the subject line in my last post... :-)

Could somebody add build.sh for the Linux/Unix people to the FormProc
source tree?  Here is one I used yesterday to compile FormProc.  Use
this if you like:



#! /bin/sh

if [ -z "$JAVA_HOME" ] ; then
  JAVA=`which java`
  if [ -z "$JAVA" ] ; then
    echo "Cannot find JAVA. Please set your PATH."
    exit 1
  fi
  JAVA_BIN=`dirname $JAVA`
  JAVA_HOME=$JAVA_BIN/..
fi

JAVA=$JAVA_HOME/bin/java

CLASSPATH=`echo lib/*.jar | tr ' ' ':'`
CLASSPATH=build-lib/ant.jar:build/classes/:$CLASSPATH:$JAVA_HOME/lib/tools.jar

$JAVA -classpath $CLASSPATH -Dant.home=lib org.apache.tools.ant.Main
"$@" -buildfile build.xml



-- 
Kerry Todyruik <ke...@to...>

[FormProc-developer] (no subject)

[Kerry T. <ke...@to...>]

This is a suggestion for future development.  I think it would be a
'nice-to-have' feature.

I was looking at Nick Bauman's API and noticed that his RuleResult class
holds the error message while FormProc's getMessage method is in the
FormElement.

It looks to me like this design prevents FormProc from being able to
implement multiple rules.

For example, I think it would be useful to be able to configure a field
like this:

<element name="postalcode">

  <!-- Rule for making the field required -->
  <validator type="rule">
    <rule>org.formproc.example.RequiredRule</rule>
    <error lang="en">This field is required</error>
  </validator>

  <!-- Rule for validating a Canadian Postal Code -->
  <validator type="rule">
    <rule>org.formproc.example.CanPostalCodeRule</rule>
    <error lang="en">This is not a valid Canadian Postal Code</error>
  </validator>

  <message lang="en">Please enter a valid postal code</message>

</element>


The first rule would be evaluated, and if the field is blank then the
user would be given the "This field is required" message.  If the field
is entered, but the postal code is invalid, then the second rule is
evaluated and he/she would be presented with the invalid postal code
message.

It also seems logical to me that the error message would be a property
of the validator for a particular field.

This change might make porting/merging Nick's rules easier as well.


Regards,
-Kerry

-- 
Kerry Todyruik <ke...@to...>

[FormProc-developer] XML Configuration file format

[Kerry T. <ke...@to...>]

Other projects that employ XML configuration files (Castor, Tomcat,
Poolman, etc.) use concise, simple tag names.  Wouldn't it be more
straightforward to read and maintain if 'formproc:'  was removed from
the tags in the formproc.xml and example-form.xml files?

For example:

----------

<?xml version="1.0"?>

<formproc xmlns:formproc="http://www.formproc.org/">

   <validator-map type="script"
classname="org.formproc.validation.ScriptFormValidator">
      <property name="script-root"
value="g:\osscvs\formproc\formproc\example"/>
   </validator-map>
   <validator-map type="expression"
classname="org.formproc.validation.REFormValidator"/>
   <validator-map type="rule"
classname="org.formproc.validation.RuleFormValidator"/>

   <form name="exampleform"
loader="com.anthonyeden.lib.resource.FileResourceLoader"
path="example-form.xml" monitor="true"/>

</formproc>

----------

<?xml version="1.0"?>

<form xmlns:formproc="http://www.formproc.org/">

   <name>example</name>

   <element name="name">
      <validator type="expression">
         <pattern>\w{1,}</pattern>
      </validator>
      <write-method>setName</write-method>
      <message lang="en">Required</message>
      <error lang="en">The name cannot be empty.</error>
   </element>
   
   <element name="username">
      <validator type="class"
classname="org.formproc.example.UsernameValidator"/>
      <message lang="en">5 characters or more.</message>
   </element>
   
   <element name="age">
      <validator type="rule">
         <rule>org.formproc.example.IsIntRule</rule>
      </validator>
      <message lang="en">Valid age required.</message>
   </element>
   
   <element name="password">
      <validator type="script">
         <script>PasswordValidator.py</script>
      </validator>
      <message lang="en">Minimum 8 characters.</message>
      <error lang="en">Passwords must be at least 8 characters.</error>
   </element>

</form>


-- 
Kerry Todyruik <ke...@to...>

[FormProc-developer] New rules written

[Nick B. <ni...@co...>]

Anthony,

I've written a bunch of rules, but they are for my own framework. My desire
is to see if we can write some kind of bridge that will allow my rules to be
plugged into your framework without me having to develop in the FormProc
tree. Can we agree this is a worthy goal? If not, you could always cut and
paste, and I would be fine with that, but that means we miss out on long
term cohesiveness and maintainability.

Let me know what you think, meanwhile, take a look at the rules:

http://www.cortexity.com/cgi-py/viewcvs.cgi/integradata/src/com/cortexity/integradata/rules/

javadoc:

http://www.cortexity.com/nightly/integradata-javadoc/

-- 
Nick Bauman 
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/

[FormProc-developer] Some Comments

[Kerry T. <ke...@to...>]

Hello.

I've been trying out FormProc the last couple of days.  Overall, I think
it is an excellent tool.  Very nice work!  I would like to share some of
my impressions being a first time user.  I also have a few questions.

My first question is how do you set up a field with no validator?  When
I configure a field like:

<formproc:element name="address" />

or even 

<formproc:element name="address">
    <formproc:write-method>setAddress</formproc:write-method>
</formproc:element>

It throws a ResourceException.  Correct me if I'm wrong, but this field
configuration seems valid.  if not, an exception with some description
of the problem would be helpful.  Like "ResourceException: Missing
required --- tag" for example.

Secondly, I received this error that seems due to the fact that I had
fields in my form that were not included in the configuration file:

[DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - Starting
FileMonitor
[DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - FileMonitor
running.
[DEBUG]:org.formproc.FormManager - Formproc configuration loaded
[DEBUG]:org.formproc.servlet.HttpForm - Processing servlet request.
[DEBUG]:org.formproc.Form - Validating field action
[DEBUG]:org.formproc.Form - getName: action
[DEBUG]:org.formproc.Form - Found form element.
java.lang.NullPointerException
	at org.formproc.Form.validate(Form.java:300)
	at org.formproc.Form.process(Form.java:266)
	at org.formproc.servlet.HttpForm.process(HttpForm.java:38)
	at EntryForm.handle(EntryForm.java:49)

Wouldn't it be better to gracefully ignore fields in the form that are
not included in the xml configuration file?  Or at least throw a
meaningfull exception with some description of the problem with the
config file?

Regards,
Kerry

-- 
Kerry Todyruik <ke...@to...>

[FormProc-developer] several records in one input- text

[BUDI W. <bu...@li...>]

I have one input text field. 

The input contain several records with ";" delimited input data.

With structure:
hiredate;sal;ename;empno

Data:
1996-09-01;1250.00;jackson;7123
1980-01-01;2500.50;walsh;7124
1985-01-01;12345.67;gates;7125

I have to validate the input records
with several rules:
- hiredate as date format (YYYY-MM-DD), can't Null
- sal as number, can't Null
- ename as character, can't Null
- empno as number, can't Null

Can we use FormProc as mass data import interface ?

Regards.

RE: [FormProc-developer] What's Next

[Nick B. <ni...@co...>]

> 
>> Okay, here's what I want to give FormProc:
>>
>> IsEmailRule (that doesn't require Java Mail)
>> StringLengthRule (whether a String is in a range of size)
>> StringMatchesRule (whether a String contains a POSIX regex)
>> IntegerRangeRule (whether a String represents an Integer between x and
>> y) DoubleRangeRule (obvious)
>> OrRule (whether a String is one of a set domain of values)
>> NegateRule (will accept any Rule and return true if false, false if
>> true) AndRule (will accept a collection of Rules and process each one
>> to pass) IsCreditCardNumRule (will do mod-10 checksum and credit card
>> logic to see if
>> the field looks like a valid credit card)
>>
>> Sound good for starters?
> 
> Sounds very good.  JPublish already has the Jakarta ORO package
> included so feel free to use that for your regular expressions.  I am
> looking forward to receiving your code.

I saw that. Can you give me a 25-word how-to on how to _configure_ a rule? 
I'll be reading the source, but I'm not sure what to expect. IE I'd like to 
have IntegerRange rule accept attributes describing the range requested 
from the config xml file. How should that look?

Don't worry about details, just the very high level. I can get the rest 
from the source.
 
> Have you tried the SourceForge CVS yet?  I have added your SourceForge
> account to the developer list and I am curious if you have write access
> to the repository.
> 
> -Anthony
> 

I would prefer for the time being have you review, approve and commit my 
changes until we have a more solid working relationship, ie: so that you 
know what to expect and I know what to expect. Maybe in a few more rounds 
of contributions from me and then it makes sense for me to have full commit 
status. Sound good?

-Nick