formproc-developer — Developer interests

[FormProc-developer] Update on Upcoming Release

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

Greetings all,

Since no one responded back with a negative regarding the change of
FormValidator to an abstract base class I have made the change in the CVS.
Doing this allows FormProc to have validator-specific locale-sensitive error
messages, like this:

<element name="name">
	<validator type="expression">
		<pattern>\w{1,}</pattern>
		<error lang="en">Field required.</error>
	</validator>
	<message lang="en">Required</message>
</element>


I have also added the concept of shared validators.  Shared validators are
defined in the formproc.xml configuration and are then available to all
forms.  Thus you could define a validation rule for phone numbers in one
place and have home phone, business phone, and cell phone fields all use the
same validator.  Thus, the form configuration would look like this:

<element name="homePhone">
	<validator type="shared" name="phone"/>
	<message lang="en">Required</message>
</element>
<element name="businessPhone">
	<validator type="shared" name="phone"/>
	<message lang="en">Required</message>
</element>
<element name="cellPhone">
	<validator type="shared" name="phone"/>
	<message lang="en">Required</message>
</element>

The addition of this feature should not break any existing configuration
files, but it will allow you to centralize your validation configurations
and improve reuse.

Feedback is, as always, welcome.  If you would like to check out via CVS and
build I would be interested in hearing about any problems you may find.

-Anthony

RE: [FormProc-developer] Object Population and Validation (was: Validation by type)

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

Comments inline.

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Nick Bauman
> Sent: Wednesday, January 23, 2002 11:37 AM
> To: for...@li...
> Subject: [FormProc-developer] Object Population and 
> Validation (was: Validation by type)
> 
> 
> I understand. That's great, I think it's a good idea. I was making an 
> assumption that these are 2 different goals that s/b 
> decoupled. It is, 
> however, not wrong to couple them.

Good, glad we agree. :-)

> 
> Thinking aloud: 
> 
> For myself, and maybe I need some religion on this one, but I 
> personally 
> don't like frameworks that make me change my objects to fit 
> them better, 
> or have to make discriptors of my objects that are external 
> to them which 
> make it possible for a framework to use them. 

The good news is that you don't have to change your objects to work with
FormProc.  The data population is not required.  You do not have to
specify write methods and if a setXXX() method is not found then that
field will be skipped (validation will still occur though).

> For me to 
> accept this, I'm 
> going to take a long hard look before leaping. This is why I 
> like the idea 
> of decoupling the data validation from the object population. 
> Maybe I want 
> to plug in my own object population strategy? 

Being able to plug in an object population strategy is not a bad idea.
If you ever find that you do need to do this then let me know and I will
work on making the population part of FormProc pluggable.  One thing to
note is that FormProc attempts to follow the JavaBeans standards when
populating objects since it is the accepted standard for working with
unknown components at runtime.

> For this a peer 
> interface is 
> all that's needed. (If you've guessed that I dislike CORBA 
> for this reason 
> you're partially right, but only in particular when everyone 
> is speaking 
> Java, but that's another argument) 
> 
> Also, Anthony, the object population portion has taken root in your 
> design. Is that a good thing? Maybe it is, but it makes me think. 

I wouldn't say that it has taken root, rather it is the most common way
that people think about forms (AFAICT).  Even if FormProc was not
designed to populate objects I would still maintain the one-to-one
relationship between form widgets and FormElements in FormProc.

-Anthony

[FormProc-developer] Object Population and Validation (was: Validation by type)

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

I understand. That's great, I think it's a good idea. I was making an 
assumption that these are 2 different goals that s/b decoupled. It is, 
however, not wrong to couple them.

Thinking aloud: 

For myself, and maybe I need some religion on this one, but I personally 
don't like frameworks that make me change my objects to fit them better, 
or have to make discriptors of my objects that are external to them which 
make it possible for a framework to use them. For me to accept this, I'm 
going to take a long hard look before leaping. This is why I like the idea 
of decoupling the data validation from the object population. Maybe I want 
to plug in my own object population strategy? For this a peer interface is 
all that's needed. (If you've guessed that I dislike CORBA for this reason 
you're partially right, but only in particular when everyone is speaking 
Java, but that's another argument) 

Also, Anthony, the object population portion has taken root in your 
design. Is that a good thing? Maybe it is, but it makes me think. 

> What gave you the idea that FormProc is a lightweight validation
> framework? FormProc is in fact it is a form processing framework.  Part
> of form processing, in my opinion, is to make it easier to store the
> form data in an object, hence the auto population facilities provided
> by FormProc.  I consider it part of the core functionality of FormProc.
> 
> Does anyone else have an opinion on this?  Do you like or dislike the
> way FormProc auto populates objects?  Not that I am going to change it
> or anything.  :-)
> 
> -Anthony
> 
>> -----Original Message-----
>> From: Nick Bauman [mailto:ni...@co...]
>> Sent: Wednesday, January 23, 2002 10:37 AM
>> To: me...@an...
>> Subject: RE: [FormProc-developer] RE: Validation by type
>>
>>
>> Anthony,
>>
>> > widget and the FormElement class.  My reason for this is that the
>> > FormElement does more than just validation - it also maps the form
>> > field to a write method on a target object.  Thus having a single
>>
>> Howcome your framework has object population in addition to data
>> validation? I mean isn't the population out of the context of a
>> lightweight validation framework? It's like having a water pipe that
>> does a loop-de-loop. It's pretty neat lookin', but it's having a
>> strange effect
>> on design, don't you think?
>>
>> I mean correct me: I'm not you and I'd be convinced if you could make
>> a case for the coupling. Think of me as being too dumb to understand
>> and I need to be enlightened. :)

-- 
Nick Bauman 
Java Programmer. 
Available Cheap. 
Minneapolis area.
Will commute interstate.
Resume: http://www.cortexity.com/resume.html

RE: [FormProc-developer] RE: Validation by type

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

What gave you the idea that FormProc is a lightweight validation framework?
FormProc is in fact it is a form processing framework.  Part of form
processing, in my opinion, is to make it easier to store the form data in an
object, hence the auto population facilities provided by FormProc.  I
consider it part of the core functionality of FormProc.

Does anyone else have an opinion on this?  Do you like or dislike the way
FormProc auto populates objects?  Not that I am going to change it or
anything.  :-)

-Anthony

> -----Original Message-----
> From: Nick Bauman [mailto:ni...@co...]
> Sent: Wednesday, January 23, 2002 10:37 AM
> To: me...@an...
> Subject: RE: [FormProc-developer] RE: Validation by type
>
>
> Anthony,
>
> > widget and the FormElement class.  My reason for this is that the
> > FormElement does more than just validation - it also maps the form
> > field to a write method on a target object.  Thus having a single
>
> Howcome your framework has object population in addition to data
> validation? I mean isn't the population out of the context of a
> lightweight validation framework? It's like having a water pipe that does
> a loop-de-loop. It's pretty neat lookin', but it's having a
> strange effect
> on design, don't you think?
>
> I mean correct me: I'm not you and I'd be convinced if you could make a
> case for the coupling. Think of me as being too dumb to understand and I
> need to be enlightened. :)
>
> --
> Nick Bauman
> Java Programmer.
> Available Cheap.
> Minneapolis area.
> Will commute interstate.
> Resume: http://www.cortexity.com/resume.html
>

[FormProc-developer] Changing FormValidator to a base class

[Anthony E. <ae...@si...>]

Does anyone have any objections to changing the FormValidator interface to a
base class.  Is there ever a real case where a FormValidator implementation
is more than just a FormValidator?

Sincerely,
Anthony Eden

RE: [FormProc-developer] RE: Validation by type

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

Eric,

I have been thinking a bit more about your request.  I have a different
approach that I am considering and I wanted to run it by you  to see what
you think.

I would rather keep the one-to-one relationship between an HTML form widget
and the FormElement class.  My reason for this is that the FormElement does
more than just validation - it also maps the form field to a write method on
a target object.  Thus having a single FormElement for multiple form widgets
would be problematic for auto-populating the target object.

As an alternative solution I propose that you should be able to create
validator configurations which can be defined once (say in your formproc.xml
configuration file) and then the form configuration file can have something
like this:

<form>
	<element name="homePhone">
		<validator type="shared" name="phone"/>
	</element>
	<element name="workPhone">
		<validator type="shared" name="phone"/>
	</element>
</form>

Doing it this way would allow the current API to remain untouched yet would
provide the ability to reuse complex validators.  What do you think?

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of Eric
> Beaumier
> Sent: Tuesday, January 22, 2002 12:02 PM
> To: for...@li...
> Subject: [FormProc-developer] RE: Validation by type
>
>
>
> Hi Anthony,
>
> The goal of this demand, it's just to give the option to the user,
> to use FormProc as "validation by name" or "validation by type".  It's
> not necessarily for a DBForms compatibility.
>
>
> If I re-use the same example, here I have 4 textfields using the same
> type of validation ("phoneCanada") and it can be re-use again in
> several other JSP pages.
>
> <db:textField fieldName="phoneWork" fieldValidator="phoneCanada"/>
> <db:textField fieldName="phoneHome" fieldValidator="phoneCanada"/>
> <db:textField fieldName="phoneCell" fieldValidator="phoneCanada"/>
> <db:textField fieldName="fax"       fieldValidator="phoneCanada"/>
>
> Actually, if I want to do validation, I need to create 4 elements
> ("phoneWork", "phoneHome", "phoneCell", "fax") in "example-form.xml"
> and if fieldname haven't the same name in other JSP pages, we
> must to create
> as much of elements in "example-form.xml" as we have differents
> fieldnames ...
>
> Like this we will do a lot of duplication of element/validator and in
> reel, it's the same validation.
>
>
>
> To continue, maybe we can re-use FormProc for parameter validator
> in EJB, Web apps, Web Service, ... on the same server.  This give you
> the opportunity to declare "Enterprise Validation Type" (EVT).
> You declare each type of validator in your xml file and it can be
> re-use by any kind of applications on this server ...   or remotly
> using EJB.
>
> Because enterprise web server contains a lot of differents web
> apps on the
> same server and frequently use the same validation type, like this
> we can re-use it ...
>
> By adding the "context" (getter/setter) to the "FormData" class,
> when we call the process method, we will be enable to pass a context
> of this validation.
>
> ArrayList formDataList = new ArrayList();
> formDataList.add(new FormData("phoneCanada",
>                               request("phoneWork"),"phoneWork"));
> formDataList.add(new FormData("phoneCanada",
>                               request("phoneHome"),"phoneHome"));
> ...
>
> But if a user want to work in "name" mode, it can continue to use
> the FormData("elementName", "value") constructor.
>
>
> Naturally, we need to be enable to retrieve the context in validation
> result.
>
> I think it's a good way to manage re-usable validation of data.  Without
> modifying the core of FormProc.
>
>
> Thanks.
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp.
>
>
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>

RE: [FormProc-developer] RE: Validation by type

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

Ah ha...I think I understand it now.  So you want to be able to say
"validate a field of this type (i.e. type phoneCanada), and the fields name
is phoneWork".  Now that I get it I see the benefit for reuse as it would
allow you define a validator for a data type and then reuse that validator
for many different named fields.  I will look into it today or tomorrow.

-Anthony

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of Eric
> Beaumier
> Sent: Tuesday, January 22, 2002 12:02 PM
> To: for...@li...
> Subject: [FormProc-developer] RE: Validation by type
>
>
>
> Hi Anthony,
>
> The goal of this demand, it's just to give the option to the user,
> to use FormProc as "validation by name" or "validation by type".  It's
> not necessarily for a DBForms compatibility.
>
>
> If I re-use the same example, here I have 4 textfields using the same
> type of validation ("phoneCanada") and it can be re-use again in
> several other JSP pages.
>
> <db:textField fieldName="phoneWork" fieldValidator="phoneCanada"/>
> <db:textField fieldName="phoneHome" fieldValidator="phoneCanada"/>
> <db:textField fieldName="phoneCell" fieldValidator="phoneCanada"/>
> <db:textField fieldName="fax"       fieldValidator="phoneCanada"/>
>
> Actually, if I want to do validation, I need to create 4 elements
> ("phoneWork", "phoneHome", "phoneCell", "fax") in "example-form.xml"
> and if fieldname haven't the same name in other JSP pages, we
> must to create
> as much of elements in "example-form.xml" as we have differents
> fieldnames ...
>
> Like this we will do a lot of duplication of element/validator and in
> reel, it's the same validation.
>
>
>
> To continue, maybe we can re-use FormProc for parameter validator
> in EJB, Web apps, Web Service, ... on the same server.  This give you
> the opportunity to declare "Enterprise Validation Type" (EVT).
> You declare each type of validator in your xml file and it can be
> re-use by any kind of applications on this server ...   or remotly
> using EJB.
>
> Because enterprise web server contains a lot of differents web
> apps on the
> same server and frequently use the same validation type, like this
> we can re-use it ...
>
> By adding the "context" (getter/setter) to the "FormData" class,
> when we call the process method, we will be enable to pass a context
> of this validation.
>
> ArrayList formDataList = new ArrayList();
> formDataList.add(new FormData("phoneCanada",
>                               request("phoneWork"),"phoneWork"));
> formDataList.add(new FormData("phoneCanada",
>                               request("phoneHome"),"phoneHome"));
> ...
>
> But if a user want to work in "name" mode, it can continue to use
> the FormData("elementName", "value") constructor.
>
>
> Naturally, we need to be enable to retrieve the context in validation
> result.
>
> I think it's a good way to manage re-usable validation of data.  Without
> modifying the core of FormProc.
>
>
> Thanks.
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp.


_______________________________________________
FormProc-developer mailing list
For...@li...
https://lists.sourceforge.net/lists/listinfo/formproc-developer

[FormProc-developer] RE: Validation by type

[Eric B. <eri...@ho...>]

Hi Anthony,

The goal of this demand, it's just to give the option to the user,
to use FormProc as "validation by name" or "validation by type".  It's
not necessarily for a DBForms compatibility.


If I re-use the same example, here I have 4 textfields using the same
type of validation ("phoneCanada") and it can be re-use again in
several other JSP pages.

<db:textField fieldName="phoneWork" fieldValidator="phoneCanada"/>
<db:textField fieldName="phoneHome" fieldValidator="phoneCanada"/>
<db:textField fieldName="phoneCell" fieldValidator="phoneCanada"/>
<db:textField fieldName="fax"       fieldValidator="phoneCanada"/>

Actually, if I want to do validation, I need to create 4 elements
("phoneWork", "phoneHome", "phoneCell", "fax") in "example-form.xml"
and if fieldname haven't the same name in other JSP pages, we must to create 
as much of elements in "example-form.xml" as we have differents
fieldnames ...

Like this we will do a lot of duplication of element/validator and in
reel, it's the same validation.



To continue, maybe we can re-use FormProc for parameter validator
in EJB, Web apps, Web Service, ... on the same server.  This give you
the opportunity to declare "Enterprise Validation Type" (EVT).
You declare each type of validator in your xml file and it can be
re-use by any kind of applications on this server ...   or remotly
using EJB.

Because enterprise web server contains a lot of differents web apps on the 
same server and frequently use the same validation type, like this
we can re-use it ...

By adding the "context" (getter/setter) to the "FormData" class,
when we call the process method, we will be enable to pass a context
of this validation.

ArrayList formDataList = new ArrayList();
formDataList.add(new FormData("phoneCanada",
                              request("phoneWork"),"phoneWork"));
formDataList.add(new FormData("phoneCanada",
                              request("phoneHome"),"phoneHome"));
...

But if a user want to work in "name" mode, it can continue to use
the FormData("elementName", "value") constructor.


Naturally, we need to be enable to retrieve the context in validation
result.

I think it's a good way to manage re-usable validation of data.  Without
modifying the core of FormProc.


Thanks.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

RE: [FormProc-developer] Validation by type

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

Eric,

I am not sure how I want to proceed with this as your situation seems
somewhat unique.  Do you think other users will use FormProc in a similar
manner and thus require some sort of second name which is separate from the
actual form field name.  I suppose I need to look at DBForms to understand
what it is doing exactly (I can't get to the dbforms.org site right now
though).

Regarding error messages for a particular language: this is currently part
of the FormElement class (i.e. error messages are for a complete form
element, not on a per-validator basis) but not part of the ValidatorResult.
I will look into this as soon as possible as it seems reasonable to want to
know which validator caused the error.

-Anthony

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of Eric
> Beaumier
> Sent: Thursday, January 17, 2002 10:54 AM
> To: for...@li...
> Subject: [FormProc-developer] Validation by type
>
>
>
> Hi Anthony,
>
> Actually FormProc works by mapping distinct name to the XML file.
> To avoid to create as much of entries in this XML file as we have in
> a web form, we use the "element" as a kind of validation TYPE and
> we do the mapping for the validation.
>
> Used in DBForms it can looks like :
>
> <db:textField fieldName="phoneWork" fieldValidator="phoneCanada"/>
> <db:textField fieldName="phoneHome" fieldValidator="phoneCanada"/>
> <db:textField fieldName="phoneCell" fieldValidator="phoneCanada"/>
> <db:textField fieldName="fax" fieldValidator="phoneCanada"/>
> ...
> and because DBForms generate a fuzzy name for each textfield in the form
> (looks like NAME="f_0_0@root_4")
> we can't use it anayway.
>
>
> <element name="phoneCanada">
>    <validator type="group">
>      <validator type="expression">
>        <pattern>^[0-9]{10}$</pattern>
>        <error lang="en">The % is invalid.</error>
>        <error lang="fr">Le % est invalide.</error>
> 	   <error lang="sp">El % es inválido.</error>
>      </validator>
>      <validator type="expression">
>
> <pattern>^(204|250|289|306|403|416|418|450|506|514|519|604|613|647
> |705|709|778|780|807|819|867|902|905)</pattern>
>        <error lang="en">The % has a invalid Canada area code.</error>
>        <error lang="fr">Le % a un indicatif régional Canadien
> invalide.</error>
> 	   <error lang="sp">El % tiene inválido Canadiense un código de
> área.</error>
>      </validator>
>    </validator>
> </element>
>
> Here, when we will retrieve the error message we will replace the
> "%" by the
> appropriate expression
> (ex: "The home phone has a invalid Canada area code") in our DBForms
> Interceptor.
>
> For this reason, we can't validate the ArrayList correctly
> because we don't
> know
> which one is in error with the isValid("phoneCanada") method.
>
> 		ArrayList formDataList = new ArrayList();
> 		formDataList.add(new FormData("phoneCanada",
> request("phoneWork")));
> 		formDataList.add(new FormData("phoneCanada",
> request("phoneHome")));
> 		formDataList.add(new FormData("phoneCanada",
> request("phoneCell")));
> 		formDataList.add(new FormData("phoneCanada",
> request("fax")));
>
>
> I can perhaps suggest one of two solutions for this problem.
>
> (1) Better one :
>
>     Adding a new property to the FormData class (ex: String context)
>     Like this, when we will retrieve the Enumeration of the errors by
> 	the getErrorElements() of ValidationResultMap class, we will enable
> 	to retrieve the context of which "phoneCanada" validation
> are in error...
>
> 		ArrayList formDataList = new ArrayList();
> 		formDataList.add(new FormData("phoneCanada",
> request("phoneWork"),
> "phoneWork"));
> 		formDataList.add(new FormData("phoneCanada",
> request("phoneHome"),
> "phoneHome"));
> 		formDataList.add(new FormData("phoneCanada",
> request("phoneCell"),
> "phoneCell"));
> 		formDataList.add(new FormData("phoneCanada",
> request("fax"), "fax"));
>
>
>
> (2) Allowing the "validate" method in Form class as "public" to do the
> validation
>     one by one ...  But first one is far better.
>
> 	"public ValidationResult validate(FormData formData) throws
> Exception{"
>
> 	// phoneWork
> 	ValidationResult results = form.validate(new
> FormData("phoneCanada",
> request("phoneWork"));
>     if(result.isValid() {}
> 	// phoneHome
> 	ValidationResult results = form.validate(new
> FormData("phoneCanada",
> request("phoneHome"));
>     if(result.isValid() {}
>     ...
>
>
>
>
> 	Finnally, I did not have enough time to look the code for
> retrieving error
> message for
> 	a specific validator...  But is it possible to retrieve
> error message for a
> specific
> 	language?
> 	...
> 	<validator type="expression">
>        <pattern>^[0-9]{10}$</pattern>
>        <error lang="en">The % is invalid.</error>
>        <error lang="fr">Le % est invalide.</error>
> 	   <error lang="sp">El % es inválido.</error>
>      </validator>
> 	 ...
>
>
>
>
> Thanks again.
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
>
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>

[FormProc-developer] Validation by type

[Eric B. <eri...@ho...>]

Hi Anthony,

Actually FormProc works by mapping distinct name to the XML file.
To avoid to create as much of entries in this XML file as we have in
a web form, we use the "element" as a kind of validation TYPE and
we do the mapping for the validation.

Used in DBForms it can looks like :

<db:textField fieldName="phoneWork" fieldValidator="phoneCanada"/>
<db:textField fieldName="phoneHome" fieldValidator="phoneCanada"/>
<db:textField fieldName="phoneCell" fieldValidator="phoneCanada"/>
<db:textField fieldName="fax" fieldValidator="phoneCanada"/>
...
and because DBForms generate a fuzzy name for each textfield in the form 
(looks like NAME="f_0_0@root_4")
we can't use it anayway.


<element name="phoneCanada">
   <validator type="group">
     <validator type="expression">
       <pattern>^[0-9]{10}$</pattern>
       <error lang="en">The % is invalid.</error>
       <error lang="fr">Le % est invalide.</error>
	   <error lang="sp">El % es inválido.</error>
     </validator>
     <validator type="expression">
      
<pattern>^(204|250|289|306|403|416|418|450|506|514|519|604|613|647|705|709|778|780|807|819|867|902|905)</pattern>
       <error lang="en">The % has a invalid Canada area code.</error>
       <error lang="fr">Le % a un indicatif régional Canadien 
invalide.</error>
	   <error lang="sp">El % tiene inválido Canadiense un código de 
área.</error>
     </validator>
   </validator>
</element>

Here, when we will retrieve the error message we will replace the "%" by the 
appropriate expression
(ex: "The home phone has a invalid Canada area code") in our DBForms 
Interceptor.

For this reason, we can't validate the ArrayList correctly because we don't 
know
which one is in error with the isValid("phoneCanada") method.

		ArrayList formDataList = new ArrayList();
		formDataList.add(new FormData("phoneCanada", request("phoneWork")));
		formDataList.add(new FormData("phoneCanada", request("phoneHome")));
		formDataList.add(new FormData("phoneCanada", request("phoneCell")));
		formDataList.add(new FormData("phoneCanada", request("fax")));


I can perhaps suggest one of two solutions for this problem.

(1) Better one :

    Adding a new property to the FormData class (ex: String context)
    Like this, when we will retrieve the Enumeration of the errors by
	the getErrorElements() of ValidationResultMap class, we will enable
	to retrieve the context of which "phoneCanada" validation are in error...

		ArrayList formDataList = new ArrayList();
		formDataList.add(new FormData("phoneCanada", request("phoneWork"), 
"phoneWork"));
		formDataList.add(new FormData("phoneCanada", request("phoneHome"), 
"phoneHome"));
		formDataList.add(new FormData("phoneCanada", request("phoneCell"), 
"phoneCell"));
		formDataList.add(new FormData("phoneCanada", request("fax"), "fax"));



(2) Allowing the "validate" method in Form class as "public" to do the 
validation
    one by one ...  But first one is far better.

	"public ValidationResult validate(FormData formData) throws Exception{"

	// phoneWork
	ValidationResult results = form.validate(new FormData("phoneCanada", 
request("phoneWork"));
    if(result.isValid() {}
	// phoneHome
	ValidationResult results = form.validate(new FormData("phoneCanada", 
request("phoneHome"));
    if(result.isValid() {}
    ...




	Finnally, I did not have enough time to look the code for retrieving error 
message for
	a specific validator...  But is it possible to retrieve error message for a 
specific
	language?
	...
	<validator type="expression">
       <pattern>^[0-9]{10}$</pattern>
       <error lang="en">The % is invalid.</error>
       <error lang="fr">Le % est invalide.</error>
	   <error lang="sp">El % es inválido.</error>
     </validator>
	 ...




Thanks again.


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

[FormProc-developer] RE: Question on FormProc

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

Eric,

I have added this to the CVS and it will be in the next release.

-Anthony

> -----Original Message-----
> From: Eric Beaumier [mailto:eri...@ho...]
> Sent: Wednesday, January 16, 2002 9:24 AM
> To: me...@an...
> Subject: Question on FormProc
>
>
> Following question of previous user.
>
>
> Actually with this configuration :
> ==================================================================
> ...
>
> <element name="age">
>   <validator type="group">
>     <validator type="rule">
>       <rule>org.formproc.example.IsIntRule</rule>
>       <error lang="en">Age is not a integer.</error>
>     </validator>
>     <validator type="expression">
>       <pattern>^(1[0-9]|2[0-9])</pattern>
>       <error lang="en">Must be between 10-29.</error>
>     </validator>
>   </validator>
>   <message lang="en">Valid age required.</message>
> </element>
>
> ...
> =====================================================================
>
>
> ArrayList formDataList = new ArrayList();
> formDataList.add(new FormData("name", args[0]));
> formDataList.add(new FormData("age", args[1]));
> formDataList.add(new FormData("username", args[2]));
> formDataList.add(new FormData("password", args[3]));
>
> ValidationResultMap results = form.process(formDataList);
> ...
>
>
>
> Could we add these two functions to ValidationResultMap class ?
> ====================================================================
>
> (1) To retrieve error message associated to the first validator in error
> for the element name.
> ------------------------------------------------------------------------
> public String getErrorMessage(String field){
>      ValidationResult result = (ValidationResult)get(field);
>      if(result != null && !result.isValid()){
> 	return result.getErrorMessage();
>      }
>      return null;
> }
>
>
> (2) To retrieve an Enumeration of all elements in error.  To avoid to
> call isValid() for each element.  Could be an Enumeration or Iteration,
> of ValidationResult.
> ------------------------------------------------------------------------
> public Enumeration getErrorElements(){
>   ...
> }
>
>
>
> Thanks.
>
>
> >From: "Anthony Eden" <me...@an...>
> >To: "Eric Beaumier" <eri...@ho...>
> >Subject: RE: [FormProc-developer] Log4J & LogManager in FormProc
> >Date: Mon, 14 Jan 2002 15:25:36 -0500
> >
> >Sorry I didn't get back to you sooner.  I am not sure what the problem is
> >but I am going to look into it right now.  I will let you know
> when I have
> >found something.
> >
> >-Anthony
> >
> > > -----Original Message-----
> > > From: for...@li...
> > > [mailto:for...@li...]On
> Behalf Of Eric
> > > Beaumier
> > > Sent: Monday, January 14, 2002 3:06 PM
> > > To: for...@li...
> > > Subject: [FormProc-developer] Log4J & LogManager in FormProc
> > >
> > >
> > >
> > >
> > > Hi Anthony,
> > >
> > > I sent you a mail at your personnal email regarding a problem (I
> > > think) with
> > > your LogManager in the EdenLib.
> > >
> > > When I load the properties file, I have traced it and I'm
> > > sure it's the good one, I have remarked the type of logging is not
> > > respected.  Example, here the rootCategory must log ERROR, but all
> > > the DEBUG message appears again at the console ...   Have you an idea
> > > for this problem.
> > >
> > >
> > >
> > > log.properties
> > > ================================================================
> > > # Set root category
> > > log4j.rootCategory=ERROR,A1
> > >
> > > # A1 is set to be a ConsoleAppender which outputs to System.out.
> > > log4j.appender.A1=org.apache.log4j.ConsoleAppender
> > >
> > > # A1 uses PatternLayout.
> > > log4j.appender.A1.layout=org.apache.log4j.PatternLayout
> > > log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c %x - %m%n
> > > ================================================================
> > >
> > >
> > >
> > > ExampleApp.java
> > > ================================================================
> > > if(logPropertiesFile.exists()){
> > >     // Exist and good one (log.properties)
> > >
> PropertyConfigurator.configure(logPropertiesFile.getAbsolutePath());
> > > } else {
> > >     BasicConfigurator.configure();
> > > }
> > >
> > >                 . . .
> > >
> > > ====================================================================
> > >
> > >
> > >
> > >
> > >
> > > Console
> > > ====================================================================
> > > [DEBUG]:org.formproc.FormManager - Loading formproc configuration
> > > [DEBUG]:org.formproc.FormConfiguration - Loading form configuration
> > > [DEBUG]:org.formproc.FormConfiguration - Element name found.
> > > [DEBUG]:org.formproc.FormElement - Validator type expression.
> > > [DEBUG]:org.formproc.FormElement - Configuring validator.
> > > [DEBUG]:org.formproc.FormConfiguration - Element username found.
> > > [DEBUG]:org.formproc.FormElement - Validator type class.
> > > [DEBUG]:org.formproc.FormElement - Creating Java class validator.
> > > [DEBUG]:org.formproc.FormConfiguration - Element age found.
> > > [DEBUG]:org.formproc.FormElement - Validator type rule.
> > > [DEBUG]:org.formproc.FormElement - Configuring validator.
> > > [DEBUG]:org.formproc.FormConfiguration - Element password found.
> > > [DEBUG]:org.formproc.FormElement - Validator type script.
> > > [DEBUG]:org.formproc.FormElement - Configuring validator.
> > > [DEBUG]:org.formproc.FormConfiguration - Form configuration
> > > loaded for form
> > > example
> > > [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - Starting
> > > FileMonitor
> > > [DEBUG]:org.formproc.FormManager - Formproc configuration loaded
> > > [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - FileMonitor
> > > running.
> > >
> > >
> > >
> > >
> > >
> > > Thanks.
> > >
> > > _________________________________________________________________
> > > Send and receive Hotmail on your mobile device: http://mobile.msn.com
> > >
> > >
> > > _______________________________________________
> > > FormProc-developer mailing list
> > > For...@li...
> > > https://lists.sourceforge.net/lists/listinfo/formproc-developer
> > >
> >
>
>
> _________________________________________________________________
> Join the world’s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>

RE: [FormProc-developer] Log4J & LogManager in FormProc

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

The hardest thing about this is handling the initial configuration of
different logging systems.  If anyone has any suggestions on how to
improve this in the EdenLib LogManager system I am interested in
improving it.

-Anthony

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Nick Bauman
> Sent: Monday, January 14, 2002 5:30 PM
> To: for...@li...
> Subject: RE: [FormProc-developer] Log4J & LogManager in FormProc
> 
> 
> Right,
> 
> There's a saying "Code to an interface, not an 
> implementation". It applies 
> here.
> 
> The reason for the inderection is because other people will want to 
> include Anthony's system within theirs and will not be able 
> to unify the 
> logging if there is a direct dependency on log4j in FormProc, 
> _even if 
> they want to use log4j in their own systems_.
> 
> > Eric,
> > 
> > The LogManager is there to support multiple logging 
> systems.  I added 
> > this as a suggestion from one of FormProc's users who 
> pointed out that 
> > developers may be required to use a particular logging system other 
> > than Log4J and FormProc should be flexible enough to handle those 
> > other systems.
> > 
> > Rather than only use Log4J I would prefer to improve the LogManager 
> > and the way it is integrated with FormProc.  For example it would 
> > probably be a good idea to automatically configure FormProc 
> to use a 
> > logger specified in the formproc.xml file.  In addition I could 
> > improve the System.out logger so that it can understand property 
> > files.  Finally I can improve the documentation so that logging is 
> > easier to understand (of course integrating LogManager into 
> FormProc 
> > better might remove the need for this last step.)
> > 
> > As for contributions: initially I would prefer if you send 
> the code so  
> >that I can determine if it fits well into FormProc, both 
> logically and 
> >stylistically.  If you do this at least once and it works 
> out fine then 
> >I have no problem adding you in as a developer.  The more  people 
> >involved the better.
> > 
> > Sincerely,
> > Anthony Eden
> > 
> >> -----Original Message-----
> >> From: for...@li...
> >> [mailto:for...@li...]On 
> Behalf Of 
> >> Eric Beaumier
> >> Sent: Monday, January 14, 2002 4:51 PM
> >> To: for...@li...
> >> Subject: RE: [FormProc-developer] Log4J & LogManager in FormProc
> >>
> >>
> >>
> >>
> >> >Make sure that the following line is in your main() method:
> >> >
> >> 
> >LogManager.setLoggerClassName("com.anthonyeden.lib.log.Log4JLogger")
> >> >;
> >> >
> >> >It should really be the very first line in the main() method.
> >> >
> >> >The default logger is actually just a System.out logger 
> and it does 
> >> >not understand property file configuration.  I am 
> considering making
> >> Log4J the
> >> >default logger in the LogManager...what do you think?
> >>
> >> Yes.  Why the LogManager, to support more than one Logger 
> component?
> >>
> >> I think the better way, it to let entirely the job to Log4J, by 
> >> removing the LogManager step. Not because the code is not correct,
> >> but this class don't give value added.
> >>
> >> Actually, by logging all at the console, the problem here, it slow 
> >> down considerably the validation process.  Because all are 
> logged in 
> >> the System.out and this one is a Synchronized method ...  With one 
> >> Thread, it's not a problem, but when you have a lot of it, 
> it can be 
> >> a bottleneck.
> >>
> >> This what I think, correct me if I'm wrong.
> >>
> >>
> >> Do you accept contributor in your Open Source?  Or do you 
> prefer than 
> >> we send you the code and you will do the update?
> >>
> >> Thanks.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 
> _________________________________________________________________ MSN 
> >> Photos is the easiest way to share and print your photos: 
> >> http://photos.msn.com/support/worldwide.aspx
> >>
> >>
> >> _______________________________________________
> >> FormProc-developer mailing list 
> >> For...@li...
> >> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> >>
> > 
> > 
> > _______________________________________________
> > 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] Log4J & LogManager in FormProc

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

Right,

There's a saying "Code to an interface, not an implementation". It applies 
here.

The reason for the inderection is because other people will want to 
include Anthony's system within theirs and will not be able to unify the 
logging if there is a direct dependency on log4j in FormProc, _even if 
they want to use log4j in their own systems_.

> Eric,
> 
> The LogManager is there to support multiple logging systems.  I added
> this as a suggestion from one of FormProc's users who pointed out that
> developers may be required to use a particular logging system other
> than Log4J and FormProc should be flexible enough to handle those other
> systems.
> 
> Rather than only use Log4J I would prefer to improve the LogManager and
> the way it is integrated with FormProc.  For example it would probably
> be a good idea to automatically configure FormProc to use a logger
> specified in the formproc.xml file.  In addition I could improve the
> System.out logger so that it can understand property files.  Finally I
> can improve the
> documentation so that logging is easier to understand (of course
> integrating LogManager into FormProc better might remove the need for
> this last step.)
> 
> As for contributions: initially I would prefer if you send the code so
> that I can determine if it fits well into FormProc, both logically and
>stylistically.  If you do this at least once and it works out fine then
>I have no problem adding you in as a developer.  The more  people
>involved the better.
> 
> Sincerely,
> Anthony Eden
> 
>> -----Original Message-----
>> From: for...@li...
>> [mailto:for...@li...]On Behalf Of
>> Eric Beaumier
>> Sent: Monday, January 14, 2002 4:51 PM
>> To: for...@li...
>> Subject: RE: [FormProc-developer] Log4J & LogManager in FormProc
>>
>>
>>
>>
>> >Make sure that the following line is in your main() method:
>> >
>> >LogManager.setLoggerClassName("com.anthonyeden.lib.log.Log4JLogger");
>> >
>> >It should really be the very first line in the main() method.
>> >
>> >The default logger is actually just a System.out logger and it does
>> >not understand property file configuration.  I am considering making
>> Log4J the
>> >default logger in the LogManager...what do you think?
>>
>> Yes.  Why the LogManager, to support more than one Logger component?
>>
>> I think the better way, it to let entirely the job to Log4J, by
>> removing the
>> LogManager step. Not because the code is not correct,
>> but this class don't give value added.
>>
>> Actually, by logging all at the console, the problem here, it slow
>> down considerably the validation process.  Because all are logged in
>> the System.out and this one is a Synchronized method ...  With one
>> Thread, it's not a problem, but when you have a lot of it, it can be a
>> bottleneck.
>>
>> This what I think, correct me if I'm wrong.
>>
>>
>> Do you accept contributor in your Open Source?  Or do you prefer than
>> we send you the code and you will do the update?
>>
>> Thanks.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _________________________________________________________________ MSN
>> Photos is the easiest way to share and print your photos:
>> http://photos.msn.com/support/worldwide.aspx
>>
>>
>> _______________________________________________
>> FormProc-developer mailing list
>> For...@li...
>> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>>
> 
> 
> _______________________________________________
> 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/

RE: [FormProc-developer] Log4J & LogManager in FormProc

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

Eric,

The LogManager is there to support multiple logging systems.  I added this
as a suggestion from one of FormProc's users who pointed out that developers
may be required to use a particular logging system other than Log4J and
FormProc should be flexible enough to handle those other systems.

Rather than only use Log4J I would prefer to improve the LogManager and the
way it is integrated with FormProc.  For example it would probably be a good
idea to automatically configure FormProc to use a logger specified in the
formproc.xml file.  In addition I could improve the System.out logger so
that it can understand property files.  Finally I can improve the
documentation so that logging is easier to understand (of course integrating
LogManager into FormProc better might remove the need for this last step.)

As for contributions: initially I would prefer if you send the code so that
I can determine if it fits well into FormProc, both logically and
stylistically.  If you do this at least once and it works out fine then I
have no problem adding you in as a developer.  The more  people involved the
better.

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of Eric
> Beaumier
> Sent: Monday, January 14, 2002 4:51 PM
> To: for...@li...
> Subject: RE: [FormProc-developer] Log4J & LogManager in FormProc
>
>
>
>
> >Make sure that the following line is in your main() method:
> >
> >LogManager.setLoggerClassName("com.anthonyeden.lib.log.Log4JLogger");
> >
> >It should really be the very first line in the main() method.
> >
> >The default logger is actually just a System.out logger and it does not
> >understand property file configuration.  I am considering making
> Log4J the
> >default logger in the LogManager...what do you think?
>
> Yes.  Why the LogManager, to support more than one Logger component?
>
> I think the better way, it to let entirely the job to Log4J, by
> removing the
> LogManager step. Not because the code is not correct,
> but this class don't give value added.
>
> Actually, by logging all at the console, the problem here, it slow down
> considerably the validation process.  Because all are logged in the
> System.out and this one is a Synchronized method ...  With one Thread,
> it's not a problem, but when you have a lot of it, it can be a
> bottleneck.
>
> This what I think, correct me if I'm wrong.
>
>
> Do you accept contributor in your Open Source?  Or do you prefer than
> we send you the code and you will do the update?
>
> Thanks.
>
>
>
>
>
>
>
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
>
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>

RE: [FormProc-developer] Log4J & LogManager in FormProc

[Eric B. <eri...@ho...>]

>Make sure that the following line is in your main() method:
>
>LogManager.setLoggerClassName("com.anthonyeden.lib.log.Log4JLogger");
>
>It should really be the very first line in the main() method.
>
>The default logger is actually just a System.out logger and it does not
>understand property file configuration.  I am considering making Log4J the 
>default logger in the LogManager...what do you think?

Yes.  Why the LogManager, to support more than one Logger component?

I think the better way, it to let entirely the job to Log4J, by removing the 
LogManager step. Not because the code is not correct,
but this class don't give value added.

Actually, by logging all at the console, the problem here, it slow down
considerably the validation process.  Because all are logged in the
System.out and this one is a Synchronized method ...  With one Thread,
it's not a problem, but when you have a lot of it, it can be a
bottleneck.

This what I think, correct me if I'm wrong.


Do you accept contributor in your Open Source?  Or do you prefer than
we send you the code and you will do the update?

Thanks.









_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

RE: [FormProc-developer] Log4J & LogManager in FormProc

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

Make sure that the following line is in your main() method:

LogManager.setLoggerClassName("com.anthonyeden.lib.log.Log4JLogger");

It should really be the very first line in the main() method.

The default logger is actually just a System.out logger and it does not
understand property file configuration.  I am considering making Log4J the
default logger in the LogManager...what do you think?

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of Eric
> Beaumier
> Sent: Monday, January 14, 2002 3:06 PM
> To: for...@li...
> Subject: [FormProc-developer] Log4J & LogManager in FormProc
>
>
>
>
> Hi Anthony,
>
> I sent you a mail at your personnal email regarding a problem (I
> think) with
> your LogManager in the EdenLib.
>
> When I load the properties file, I have traced it and I'm
> sure it's the good one, I have remarked the type of logging is not
> respected.  Example, here the rootCategory must log ERROR, but all
> the DEBUG message appears again at the console ...   Have you an idea
> for this problem.
>
>
>
> log.properties
> ================================================================
> # Set root category
> log4j.rootCategory=ERROR,A1
>
> # A1 is set to be a ConsoleAppender which outputs to System.out.
> log4j.appender.A1=org.apache.log4j.ConsoleAppender
>
> # A1 uses PatternLayout.
> log4j.appender.A1.layout=org.apache.log4j.PatternLayout
> log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c %x - %m%n
> ================================================================
>
>
>
> ExampleApp.java
> ================================================================
> if(logPropertiesFile.exists()){
>     // Exist and good one (log.properties)
>     PropertyConfigurator.configure(logPropertiesFile.getAbsolutePath());
> } else {
>     BasicConfigurator.configure();
> }
>
>                 . . .
>
> ====================================================================
>
>
>
>
>
> Console
> ====================================================================
> [DEBUG]:org.formproc.FormManager - Loading formproc configuration
> [DEBUG]:org.formproc.FormConfiguration - Loading form configuration
> [DEBUG]:org.formproc.FormConfiguration - Element name found.
> [DEBUG]:org.formproc.FormElement - Validator type expression.
> [DEBUG]:org.formproc.FormElement - Configuring validator.
> [DEBUG]:org.formproc.FormConfiguration - Element username found.
> [DEBUG]:org.formproc.FormElement - Validator type class.
> [DEBUG]:org.formproc.FormElement - Creating Java class validator.
> [DEBUG]:org.formproc.FormConfiguration - Element age found.
> [DEBUG]:org.formproc.FormElement - Validator type rule.
> [DEBUG]:org.formproc.FormElement - Configuring validator.
> [DEBUG]:org.formproc.FormConfiguration - Element password found.
> [DEBUG]:org.formproc.FormElement - Validator type script.
> [DEBUG]:org.formproc.FormElement - Configuring validator.
> [DEBUG]:org.formproc.FormConfiguration - Form configuration
> loaded for form
> example
> [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - Starting
> FileMonitor
> [DEBUG]:org.formproc.FormManager - Formproc configuration loaded
> [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - FileMonitor
> running.
>
>
>
>
>
> Thanks.
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>

[FormProc-developer] Log4J & LogManager in FormProc

[Eric B. <eri...@ho...>]

Hi Anthony,

I sent you a mail at your personnal email regarding a problem (I think) with 
your LogManager in the EdenLib.

When I load the properties file, I have traced it and I'm
sure it's the good one, I have remarked the type of logging is not
respected.  Example, here the rootCategory must log ERROR, but all
the DEBUG message appears again at the console ...   Have you an idea
for this problem.



log.properties
================================================================
# Set root category
log4j.rootCategory=ERROR,A1

# A1 is set to be a ConsoleAppender which outputs to System.out.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c %x - %m%n
================================================================



ExampleApp.java
================================================================
if(logPropertiesFile.exists()){
    // Exist and good one (log.properties)
    PropertyConfigurator.configure(logPropertiesFile.getAbsolutePath());
} else {
    BasicConfigurator.configure();
}

                . . .

====================================================================





Console
====================================================================
[DEBUG]:org.formproc.FormManager - Loading formproc configuration
[DEBUG]:org.formproc.FormConfiguration - Loading form configuration
[DEBUG]:org.formproc.FormConfiguration - Element name found.
[DEBUG]:org.formproc.FormElement - Validator type expression.
[DEBUG]:org.formproc.FormElement - Configuring validator.
[DEBUG]:org.formproc.FormConfiguration - Element username found.
[DEBUG]:org.formproc.FormElement - Validator type class.
[DEBUG]:org.formproc.FormElement - Creating Java class validator.
[DEBUG]:org.formproc.FormConfiguration - Element age found.
[DEBUG]:org.formproc.FormElement - Validator type rule.
[DEBUG]:org.formproc.FormElement - Configuring validator.
[DEBUG]:org.formproc.FormConfiguration - Element password found.
[DEBUG]:org.formproc.FormElement - Validator type script.
[DEBUG]:org.formproc.FormElement - Configuring validator.
[DEBUG]:org.formproc.FormConfiguration - Form configuration loaded for form 
example
[DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - Starting 
FileMonitor
[DEBUG]:org.formproc.FormManager - Formproc configuration loaded
[DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - FileMonitor 
running.





Thanks.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

[FormProc-developer] FormProc 0.6 Released

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

FormProc version 0.6 is now available at http://formproc.sf.net/  This
release includes fixes for a large number of bugs in the 0.5 and 0.5.1
releases.

FormProc is an open source Java library designed to make handling and
validating forms easy.  Forms are represented as objects which manage a
collection of form elements.  Submitted data can be validated through
several mechanisms including regular expressions, BSF supported scripting
languages and custom Java classes.

Removed XMLConstants interface which is no longer required.  Removed
references to this interface in all classes.  Fixed numerous bugs from the
0.5.1 release.  Replaced configuration with classes from EdenLib config
package.  Example of web app now packaged as a WAR for easy deployment.
Example application now packaged as an executable JAR.  Added
script-root-type property to the ScriptFormValidator which can have a value
of 'file' or 'classpath'.  If file then the script-root is a file.  If
classpath then the script-root is relative to the classpath.  Example apps
both use ClassPathResourceLoader from EdenLib to load their configuration
files.  Changed age example field to use group validator with two nested
validators.  Fixed FormElement configuration bug (was sending wrong config
object).

[FormProc-developer] Update on 0.6

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

I made a large number of fixes tonight and numerous enhancements as
well.  The example applications will now be distributed as an executable
JAR for the example Swing app and a WAR for the web app.  I also added
support for loading form configuration files and scripts from the
classpath (to facilitate JAR and WAR distribution.)  I have to update
the docs, but I should have a new release out by tomorrow.

Sincerely,
Anthony Eden

[FormProc-developer] Its been one of those weeks

[Anthony E. <ae...@si...>]

After further review I have decided that the  0.5.1 release of FormProc
still has significant bugs.  I am working on the 0.6 release and I hope to
have it out within a day or two.  In the meantime you may want to stick with
0.4 for the moment.

Sincerely,
Anthony Eden

[FormProc-developer] Bug in FormManager.loadConfiguration()

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

I just fixed a bug in the FormManager.loadConfiguration() method which
caused an error if the default configuration file was not found by the class
loader.  I will release FormProc 0.5.2 today with this fix.

-Anthony

[FormProc-developer] FormProc 0.5.1 Released

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

FormProc version 0.5.1 is now available at http://formproc.sf.net/.

FormProc is an open source Java library designed to make handling and
validating forms easy.  Forms are represented as objects which manage a
collection of form elements.  Submitted data can be validated through
several mechanisms including regular expressions, BSF supported scripting
languages and custom Java classes.

Added note to README about removal of formproc namespace from configuration
files.  Fixed error in example-form.xml configuration file.

For more information please visit http://formproc.sf.net/ or contact Anthony
Eden [me...@an...].

[FormProc-developer] Notes about 0.5

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

Just wanted to mention a few things which are a result of the 0.5 changes:

1.) The formproc namespace has been removed from all configuration files.
Thus what was once formproc:form now is just form.
2.) There is an error in the example-form.xml configuration file where one
of the element closing tags still has the formproc name space.

I will release a 0.5.1 release shortly which will include point 1 in the
README and will include the fixed example-form.xml configuration file.  If
you notice any other problems please let me know and I will repair them.

Sincerely,
Anthony Eden

[FormProc-developer] RE: multi-validator

[INFO II <in...@ya...>]

Thanks for your precisions.

By the way, FormProc do a great job!

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

[FormProc-developer] FormProc 0.5 Released

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

FormProc version 0.5 is now available at http://formproc.sf.net/

FormProc is an open source Java library designed to make handling and
validating forms easy.  Forms are represented as objects which manage a
collection of form elements.  Submitted data can be validated through
several mechanisms including regular expressions, BSF supported
scripting languages and custom Java classes.

Added constructors to HttpForm with the same signatures as the Form
constructors.  Form elements can now be defined without a validator.  If
no form element for a particular form field is found, then the form data
is considered valid.  Added a FormValidatorGroup class which is
collection of FormValidator objects which must all evaluate to true in
order for the field data to be valid.  Removed formproc name space from
all XML configuration files.  Added Configuration class which replaces
the use of JDOM Element objects for configuration in Validators.  Form
configuration paths can be relative to main form configuration file
(contributed by JD Evora).

For more information please visit http://formproc.sf.net/ or contact
Anthony Eden [me...@an...].