formproc-developer — Developer interests

[FormProc-developer] REValidator

[Dan B. <da...@ch...>]

REValidator doesn't appear to be working the way it used to...

I have the following:

------ formproc.xml ---------

    <shared-validator name="notempty">
        <validator type="expression">
           <pattern>.{1,}</pattern>
           <error lang="en">Field must not be empty</error>
        </validator>
    </shared-validator>

------ userform.xml ---------

    <element name="username">
        <validator type="shared" name="notempty"/>
        <message lang="en">username must not be empty.</message>
    </element>


------ my log -------------

[DEBUG]:org.formproc.validation.REValidator - Validating form data
username with value of test
[DEBUG]:org.formproc.validation.REValidator - The pattern is: 
[DEBUG]:org.formproc.validation.REValidator - Form data value NOT
matched.


so.. REValidator doesn't seem to have my expression in it... is my
configuration wrong?

thanks,
dan

[FormProc-developer] Runaway thread problem fixed

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

I have updated the EdenLib library in the JPublish and FormProc CVS
repositories to fix a runaway thread which would utilize 100% CPU when
the com.anthonyeden.lib.resource.FileResourceLoader was used.  The
JPublish example code was exhibiting this behavior prior to the fix.  I
don't believe the FormProc examples exhibited this behavior, but to be
safe you may want to update the copy of EdenLib (either from the
FormProc/lib directory or from today's EdenLib release).

Sincerely,
Anthony Eden

[FormProc-developer] FormProc 0.9 Released

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

FormProc version 0.9 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.

This release includes the following changes: Complete rewrite of
validation interface to simplify creation and configuration of
validators.  Mechanism for storing field values in a form's target
object is now pluggable through the Storer interface.  Created two
storers: ReflectionStorer and MapStorer.  Class validator's now
configured properly.  Added ErrorDialog to example application.

Sincerely,
Anthony Eden

RE: [FormProc-developer] Form handling over multiple pages or screens

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

>> Anthony,
>> 
>> > Nick,
>> > 
>> > Take this FormProc configuration example:
>> > 
>> > <form>
>> >   <element name="field1">
>> >     <validator type="class" classname="SomeValidatorClass">
>> >       <param name="param1" value="x"/>
>> >       <param name="param2" value="y"/>
>> >     </validator>
>> >   </element>
>> > 
>> >   <element name="field2">
>> >     <validator type="group">
>> >       <validator type="class" classname="AnotherValidatorClass"/>
>> >       <validator type="class" classname="MoreValidation"/>
>> >     </validator>
>> >   </element>
>> > </form>
>> > 
>> > Not sure how that is much more complex than your example.  Messages,
>> 
>> 
>> Well, when you remove the frills it seems our design is very 
>> similar. We 
>> just have different entity tag names and I hook a form to a 
>> controller 
>> using a global (per webapp) config. I suppose you are using 
>> the filename 
>> for each form?
> 
> Actually, forms are defined and named in the formproc.xml file and can
> load from any ResourceLoader (which comes from the EdenLib project).


I don't have a need to store that stuff anyplace other than the filesystem 
yet, so I don't do that.


>> > errors, converters, storers, etc. are all optional.  Validators can 
>> > use any nested configuration data (I used param tags, but it could 
>> > just as well be more complex XML).  Those features sure are nice to 
>> > have if you need to change the behavior, though.  As always, this 
>> > comes back to the
>> 
>> 
>> I haven't as yet encountered a need to change the behavior of 
>> a Rule's 
>> config (you call it a validator)
> 
> Perhaps I wasn't clear: converters, storers, etc. are optional and
> their implementations can be defined at runtime.


Reflecting different goals of (parts) of our systems.

 
>> > fact that FormProc is supposed to be more than just a validation 
>> > system, rather it is for form processing.
>> 
>> 
>> I prefer to partition those two requirements. A data 
>> validation engine 
>> should not be an object populator. Different problems, IMO, require 
>> disparate solutions. But more power to you if you have that itch.
> 
> :-)  We've been down this road before.


Yup.

  
>> 
>> > Perhaps you are talking about the formproc.xml file being complex?
>> > 
>> > By the way: what is an i18n codepage?  I'll admit that the error
>> 
>> 
>> It's pretty flexible. Via the Locale, Integradata dynamically 
>> loads the 
>> correct error messages from an nls codepage, which is 
>> essentially nothing 
>> more than a properties file. This is standard in Java 
>> i18n/l10n. Since the 
>> client reveals its Locale to the servlet engine for each 
>> request, it's 
>> trivial.
> 
> So you use the PropertyResourceBundles or something similar?  What
> class in your system actually loads the error message?

AbstractRule.java

http://www.cortexity.com/cgi-
py/viewcvs.cgi/integradata/src/com/cortexity/integradata/rules/AbstractRule.
java?rev=1.22&content-type=text/vnd.viewcvs-markup

The checkLocaleBundle(Locale locale) method does it. Rules extend this and 
get the functionality.

RE: [FormProc-developer] Form handling over multiple pages or screens

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

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Nick Bauman
> Sent: Thursday, March 14, 2002 7:46 PM
> To: for...@li...
> Subject: RE: [FormProc-developer] Form handling over multiple 
> pages or screens
> 
> 
> Anthony,
> 
> > Nick,
> > 
> > Take this FormProc configuration example:
> > 
> > <form>
> >   <element name="field1">
> >     <validator type="class" classname="SomeValidatorClass">
> >       <param name="param1" value="x"/>
> >       <param name="param2" value="y"/>
> >     </validator>
> >   </element>
> > 
> >   <element name="field2">
> >     <validator type="group">
> >       <validator type="class" classname="AnotherValidatorClass"/>
> >       <validator type="class" classname="MoreValidation"/>
> >     </validator>
> >   </element>
> > </form>
> > 
> > Not sure how that is much more complex than your example.  Messages,
> 
> 
> Well, when you remove the frills it seems our design is very 
> similar. We 
> just have different entity tag names and I hook a form to a 
> controller 
> using a global (per webapp) config. I suppose you are using 
> the filename 
> for each form?

Actually, forms are defined and named in the formproc.xml file and can
load from any ResourceLoader (which comes from the EdenLib project).

> > errors, converters, storers, etc. are all optional.  Validators can 
> > use any nested configuration data (I used param tags, but it could 
> > just as well be more complex XML).  Those features sure are nice to 
> > have if you need to change the behavior, though.  As always, this 
> > comes back to the
> 
> 
> I haven't as yet encountered a need to change the behavior of 
> a Rule's 
> config (you call it a validator)

Perhaps I wasn't clear: converters, storers, etc. are optional and their
implementations can be defined at runtime.

> > fact that FormProc is supposed to be more than just a validation 
> > system, rather it is for form processing.
> 
> 
> I prefer to partition those two requirements. A data 
> validation engine 
> should not be an object populator. Different problems, IMO, require 
> disparate solutions. But more power to you if you have that itch.

:-)  We've been down this road before.
 
> 
> > Perhaps you are talking about the formproc.xml file being complex?
> > 
> > By the way: what is an i18n codepage?  I'll admit that the error
> 
> 
> It's pretty flexible. Via the Locale, Integradata dynamically 
> loads the 
> correct error messages from an nls codepage, which is 
> essentially nothing 
> more than a properties file. This is standard in Java 
> i18n/l10n. Since the 
> client reveals its Locale to the servlet engine for each 
> request, it's 
> trivial.

So you use the PropertyResourceBundles or something similar?  What class
in your system actually loads the error message?

Sincerely,
Anthony Eden

RE: [FormProc-developer] Form handling over multiple pages or screens

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

Anthony,

> Nick,
> 
> Take this FormProc configuration example:
> 
> <form>
>   <element name="field1">
>     <validator type="class" classname="SomeValidatorClass">
>       <param name="param1" value="x"/>
>       <param name="param2" value="y"/>
>     </validator>
>   </element>
> 
>   <element name="field2">
>     <validator type="group">
>       <validator type="class" classname="AnotherValidatorClass"/>
>       <validator type="class" classname="MoreValidation"/>
>     </validator>
>   </element>
> </form>
> 
> Not sure how that is much more complex than your example.  Messages,


Well, when you remove the frills it seems our design is very similar. We 
just have different entity tag names and I hook a form to a controller 
using a global (per webapp) config. I suppose you are using the filename 
for each form?


> errors, converters, storers, etc. are all optional.  Validators can use
> any nested configuration data (I used param tags, but it could just as
> well be more complex XML).  Those features sure are nice to have if you
> need to change the behavior, though.  As always, this comes back to the


I haven't as yet encountered a need to change the behavior of a Rule's 
config (you call it a validator)


> fact that FormProc is supposed to be more than just a validation
> system, rather it is for form processing.


I prefer to partition those two requirements. A data validation engine 
should not be an object populator. Different problems, IMO, require 
disparate solutions. But more power to you if you have that itch.


> Perhaps you are talking about the formproc.xml file being complex?
> 
> By the way: what is an i18n codepage?  I'll admit that the error


It's pretty flexible. Via the Locale, Integradata dynamically loads the 
correct error messages from an nls codepage, which is essentially nothing 
more than a properties file. This is standard in Java i18n/l10n. Since the 
client reveals its Locale to the servlet engine for each request, it's 
trivial.

Also I use MessageFormatter to populate dynamic data from the engine into 
the message. Pretty nice. So a message in German for an email that's 
missing the end caret looks like this in the codepage:

"Email \"{0}\" fehlendes '<' Zeichen" (DE codepage)
"Missing '<' character in email \"{0}\"" (EN codepage)

The client, it's gets populated like so for a German client:

Email "joh...@th...>" fehlendes '<' Zeichen

for an English locale, it looks like this:

Missing '<' character in email "joh...@th...>" 

> message handling still has room for improvement.  But, it is important
> to note that it can be ignored completely.

Same here.

> Sincerely,
> Anthony Eden
> 
>> -----Original Message-----
>> From: for...@li... 
>> [mailto:for...@li...] On 
>> Behalf Of Nick Bauman
>> Sent: Thursday, March 14, 2002 4:27 PM
>> To: for...@li...
>> Subject: Re: [FormProc-developer] Form handling over multiple 
>> pages or screens
>> 
>> 
>> Legit forms that fall into this catagory are examinations, tests and 
>> quizzes. I'm not sure I know of a good way to solve this 
>> problem right off 
>> the bat.
>> 
>> BTW, maybe I'm just stupid, but I still think the whole 
>> config file format 
>> for FormProc is overly complex. In Integradata, a form config is this 
>> simple:
>>  
>> <?xml version="1.0" encoding="ISO-8859-1"?> 
>> <integradata> 
>>   <!-- any number of controllers can be in a config --> 
>>   <controller 
>>       controllerClass="com.xyz.servlet.controllers.PurchaseProduct"> 
>>     <field label="nameAppearingOnCard"> 
>>       <rule ruleClass="com.cortexity.integradata.rule.StringLength"> 
>>         <param name="min" value="9"/> 
>>         <param name="max" value="32"/> 
>>       </rule> 
>>       <rule ruleClass="com.cortexity.integradata.rule.WordCount"> 
>>         <param name="min" value="2"/> 
>>         <param name="max" value="4"/> 
>>       </rule> 
>>     </field> 
>>     <field label="creditCardNumber"> 
>>       <rule ruleClass="com.cortexity.integradata.rule.IsCreditCard"> 
>>         <param name="american_express" value="true"/> 
>>         <param name="visa" value="true"/> 
>>         <param name="mastercard" value="true"/> 
>>       </field> 
>>     </controller> 
>>     <!-- ... --> 
>> </integradata> 
>> 
>> Since error messages don't change that often, I think it's a 
>> mistake to put 
>> them in the config. I put them into i18n codepages. You pass 
>> a locale to 
>> the engine and the error message of the correct i18n codepage 
>> is displayed. 
>> Of course it's all aimed at MVC Model II right now.
>> 
>> Incidentally, the concept of a "rule" is similar to 
>> FormProc's concept of 
>> a "validator". 
>> 
>> > not sure i would find this useful.. I try and keep my forms 
>> as "stand 
>> > alone" as possible.. i.e. a choice made on an earlier form 
>> is already 
>> > reflected in the rendering of the current form... and elements that 
>> > are likely to effect each other will tend to be on the same page...
>> > 
>> > do you have a concrete example of where you would find this concept 
>> > useful?
>> > 
>> > On Thu, 14 March 2002, "Anthony Eden" wrote:
>> > 
>> >> 
>> >> I was just thinking about how to handle submission of forms over 
>> >> multiple pages or multiple dialogs or screens.  I am thinking of 
>> >> something along the lines of sub forms or form chunks, where the 
>> >> request could include the name of the sub form or chunk 
>> which should 
>> >> be used for the current request.  Does anyone have any thoughts on 
>> >> this?  Is this useful?
>> >> 
>> >> Sincerely,
>> >> Anthony Eden

RE: [FormProc-developer] Form handling over multiple pages: epistemology

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

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Nick Bauman
> Sent: Thursday, March 14, 2002 5:51 PM
> To: ch...@ch...
> Cc: for...@li...
> Subject: Re: [FormProc-developer] Form handling over multiple 
> pages: epistemology
> 
> 
> :) We're having an epistemological disconnect.
> 
> If you have multiple forms that each have their own set of validation 
> rules, but they are parts of a cardinal, logical form, it 
> would be nice to 
> script the validation rules for that cardinal form, thereby 
> making that 
> desire "larger grained". (g)
> 
> Instead what we have are lots of tedious little sets of 
> validators mapping 
> to screens. Too fine grained. See?
> 
> Incidentally, in proper MVC Model II, the controller would 
> decide what to 
> do with an invalid form element, making this conversation moot. 

That is true and a good argument for NOT making FormProc handle
validation over multiple pages.  FormProc's integration with JPublish
works in this fashion: i.e. JPublish is the controller and determines
what to do when the form fails (go back to the form for example).

> > Still not sure what you mean... "less fine grained" with regard to 
> > what?
> > 
> > On Thu, 14 March 2002, "Nick Bauman" wrote:
> > 
> >> 
> >> > I see tests quizes and examinations as groups of small 
> >> > validations... perhaps on the individual question level... at 
> >> > least, that is how I have implemented it in the past...
> >> 
> >> Right, that's how you'd do it, but I think Anthony wants something 
> >> less  fine grained but still flexible enough.
> >> 
> >> > In that particular config file, are you able to reuse validators?
> >> 
> >> Godd question. Not yet but that's a minor tweak to the 
> >> ConfigSaxHandler.  Next release.
> >>  
> >> > 
> >> > On Thu, 14 March 2002, "Nick Bauman" wrote:
> >> > 
> >> >> 
> >> >> Legit forms that fall into this catagory are 
> examinations, tests 
> >> >> and  quizzes. I'm not sure I know of a good way to solve this 
> >> >> problem right off  the bat.
> >> >> 
> >> >> BTW, maybe I'm just stupid, but I still think the whole config 
> >> >> file format  for FormProc is overly complex. In Integradata, a 
> >> >> form config is this  simple:
> >> >>  
> >> >> <?xml version="1.0" encoding="ISO-8859-1"?>
> >> >> <integradata> 
> >> >>   <!-- any number of controllers can be in a config --> 
> >> >>   <controller 
> >> >>       
> controllerClass="com.xyz.servlet.controllers.PurchaseProduct">
> >> >>       
> >> >>     <field label="nameAppearingOnCard"> 
> >> >>       <rule
> >> >>       ruleClass="com.cortexity.integradata.rule.StringLength"> 
> >> >>         <param name="min" value="9"/> 
> >> >>         <param name="max" value="32"/> 
> >> >>       </rule> 
> >> >>       <rule 
> ruleClass="com.cortexity.integradata.rule.WordCount"> 
> >> >>         <param name="min" value="2"/> 
> >> >>         <param name="max" value="4"/> 
> >> >>       </rule> 
> >> >>     </field> 
> >> >>     <field label="creditCardNumber"> 
> >> >>       <rule
> >> >>       ruleClass="com.cortexity.integradata.rule.IsCreditCard"> 
> >> >>         <param name="american_express" value="true"/> 
> >> >>         <param name="visa" value="true"/> 
> >> >>         <param name="mastercard" value="true"/> 
> >> >>       </field> 
> >> >>     </controller> 
> >> >>     <!-- ... -->
> >> >> </integradata> 
> >> >> 
> >> >> Since error messages don't change that often, I think it's a 
> >> >> mistake to put  them in the config. I put them into i18n 
> >> >> codepages. You pass a locale to  the engine and the 
> error message 
> >> >> of the correct i18n codepage is displayed.  Of course it's all 
> >> >> aimed at MVC Model II right now.
> >> >> 
> >> >> Incidentally, the concept of a "rule" is similar to FormProc's 
> >> >> concept of  a "validator".
> >> >> 
> >> >> > not sure i would find this useful.. I try and keep my 
> forms as 
> >> >> > "stand alone" as possible.. i.e. a choice made on an earlier 
> >> >> > form is already reflected in the rendering of the current 
> >> >> > form... and elements that are likely to effect each 
> other will 
> >> >> > tend to be on the same page...
> >> >> > 
> >> >> > do you have a concrete example of where you would find this 
> >> >> > concept useful?
> >> >> > 
> >> >> > On Thu, 14 March 2002, "Anthony Eden" wrote:
> >> >> > 
> >> >> >> 
> >> >> >> I was just thinking about how to handle submission of forms 
> >> >> >> over multiple pages or multiple dialogs or screens.  I am 
> >> >> >> thinking of something along the lines of sub forms or form 
> >> >> >> chunks, where the request could include the name of the sub 
> >> >> >> form or chunk which should be used for the current request.  
> >> >> >> Does anyone have any thoughts on this?  Is this useful?
> >> >> >> 
> >> >> >> Sincerely,
> >> >> >> Anthony Eden
> 
> 
> 
> _______________________________________________
> FormProc-developer mailing list 
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> 

RE: [FormProc-developer] Form handling over multiple pages or screens

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

Nick,

Take this FormProc configuration example:

<form>
  <element name="field1">
    <validator type="class" classname="SomeValidatorClass">
      <param name="param1" value="x"/>
      <param name="param2" value="y"/>
    </validator>
  </element>

  <element name="field2">
    <validator type="group">
      <validator type="class" classname="AnotherValidatorClass"/>
      <validator type="class" classname="MoreValidation"/>
    </validator>
  </element>
</form>

Not sure how that is much more complex than your example.  Messages,
errors, converters, storers, etc. are all optional.  Validators can use
any nested configuration data (I used param tags, but it could just as
well be more complex XML).  Those features sure are nice to have if you
need to change the behavior, though.  As always, this comes back to the
fact that FormProc is supposed to be more than just a validation system,
rather it is for form processing.

Perhaps you are talking about the formproc.xml file being complex?

By the way: what is an i18n codepage?  I'll admit that the error message
handling still has room for improvement.  But, it is important to note
that it can be ignored completely.

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Nick Bauman
> Sent: Thursday, March 14, 2002 4:27 PM
> To: for...@li...
> Subject: Re: [FormProc-developer] Form handling over multiple 
> pages or screens
> 
> 
> Legit forms that fall into this catagory are examinations, tests and 
> quizzes. I'm not sure I know of a good way to solve this 
> problem right off 
> the bat.
> 
> BTW, maybe I'm just stupid, but I still think the whole 
> config file format 
> for FormProc is overly complex. In Integradata, a form config is this 
> simple:
>  
> <?xml version="1.0" encoding="ISO-8859-1"?> 
> <integradata> 
>   <!-- any number of controllers can be in a config --> 
>   <controller 
>       controllerClass="com.xyz.servlet.controllers.PurchaseProduct"> 
>     <field label="nameAppearingOnCard"> 
>       <rule ruleClass="com.cortexity.integradata.rule.StringLength"> 
>         <param name="min" value="9"/> 
>         <param name="max" value="32"/> 
>       </rule> 
>       <rule ruleClass="com.cortexity.integradata.rule.WordCount"> 
>         <param name="min" value="2"/> 
>         <param name="max" value="4"/> 
>       </rule> 
>     </field> 
>     <field label="creditCardNumber"> 
>       <rule ruleClass="com.cortexity.integradata.rule.IsCreditCard"> 
>         <param name="american_express" value="true"/> 
>         <param name="visa" value="true"/> 
>         <param name="mastercard" value="true"/> 
>       </field> 
>     </controller> 
>     <!-- ... --> 
> </integradata> 
> 
> Since error messages don't change that often, I think it's a 
> mistake to put 
> them in the config. I put them into i18n codepages. You pass 
> a locale to 
> the engine and the error message of the correct i18n codepage 
> is displayed. 
> Of course it's all aimed at MVC Model II right now.
> 
> Incidentally, the concept of a "rule" is similar to 
> FormProc's concept of 
> a "validator". 
> 
> > not sure i would find this useful.. I try and keep my forms 
> as "stand 
> > alone" as possible.. i.e. a choice made on an earlier form 
> is already 
> > reflected in the rendering of the current form... and elements that 
> > are likely to effect each other will tend to be on the same page...
> > 
> > do you have a concrete example of where you would find this concept 
> > useful?
> > 
> > On Thu, 14 March 2002, "Anthony Eden" wrote:
> > 
> >> 
> >> I was just thinking about how to handle submission of forms over 
> >> multiple pages or multiple dialogs or screens.  I am thinking of 
> >> something along the lines of sub forms or form chunks, where the 
> >> request could include the name of the sub form or chunk 
> which should 
> >> be used for the current request.  Does anyone have any thoughts on 
> >> this?  Is this useful?
> >> 
> >> Sincerely,
> >> Anthony Eden
> >> 
> >> 
> >> _______________________________________________
> >> 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 
> "It Is The Fate Of All Operating 
> Systems To Become Free" -- Neal Stephenson
> 
> 
> _______________________________________________
> FormProc-developer mailing list 
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> 

Re: [FormProc-developer] Form handling over multiple pages: epistemology

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

:) We're having an epistemological disconnect.

If you have multiple forms that each have their own set of validation 
rules, but they are parts of a cardinal, logical form, it would be nice to 
script the validation rules for that cardinal form, thereby making that 
desire "larger grained". (g)

Instead what we have are lots of tedious little sets of validators mapping 
to screens. Too fine grained. See?

Incidentally, in proper MVC Model II, the controller would decide what to 
do with an invalid form element, making this conversation moot. 

> Still not sure what you mean... "less fine grained" with regard to
> what?
> 
> On Thu, 14 March 2002, "Nick Bauman" wrote:
> 
>> 
>> > I see tests quizes and examinations as groups of small
>> > validations... perhaps on the individual question level... at least,
>> > that is how I have implemented it in the past...
>> 
>> Right, that's how you'd do it, but I think Anthony wants something
>> less  fine grained but still flexible enough.
>> 
>> > In that particular config file, are you able to reuse validators?
>> 
>> Godd question. Not yet but that's a minor tweak to the
>> ConfigSaxHandler.  Next release.
>>  
>> > 
>> > On Thu, 14 March 2002, "Nick Bauman" wrote:
>> > 
>> >> 
>> >> Legit forms that fall into this catagory are examinations, tests
>> >> and  quizzes. I'm not sure I know of a good way to solve this
>> >> problem right off  the bat.
>> >> 
>> >> BTW, maybe I'm just stupid, but I still think the whole config file
>> >> format  for FormProc is overly complex. In Integradata, a form
>> >> config is this  simple:
>> >>  
>> >> <?xml version="1.0" encoding="ISO-8859-1"?> 
>> >> <integradata> 
>> >>   <!-- any number of controllers can be in a config --> 
>> >>   <controller 
>> >>       controllerClass="com.xyz.servlet.controllers.PurchaseProduct">
>> >>       
>> >>     <field label="nameAppearingOnCard"> 
>> >>       <rule
>> >>       ruleClass="com.cortexity.integradata.rule.StringLength"> 
>> >>         <param name="min" value="9"/> 
>> >>         <param name="max" value="32"/> 
>> >>       </rule> 
>> >>       <rule ruleClass="com.cortexity.integradata.rule.WordCount"> 
>> >>         <param name="min" value="2"/> 
>> >>         <param name="max" value="4"/> 
>> >>       </rule> 
>> >>     </field> 
>> >>     <field label="creditCardNumber"> 
>> >>       <rule
>> >>       ruleClass="com.cortexity.integradata.rule.IsCreditCard"> 
>> >>         <param name="american_express" value="true"/> 
>> >>         <param name="visa" value="true"/> 
>> >>         <param name="mastercard" value="true"/> 
>> >>       </field> 
>> >>     </controller> 
>> >>     <!-- ... --> 
>> >> </integradata> 
>> >> 
>> >> Since error messages don't change that often, I think it's a
>> >> mistake to put  them in the config. I put them into i18n codepages.
>> >> You pass a locale to  the engine and the error message of the
>> >> correct i18n codepage is displayed.  Of course it's all aimed at
>> >> MVC Model II right now.
>> >> 
>> >> Incidentally, the concept of a "rule" is similar to FormProc's
>> >> concept of  a "validator". 
>> >> 
>> >> > not sure i would find this useful.. I try and keep my forms as
>> >> > "stand alone" as possible.. i.e. a choice made on an earlier form
>> >> > is already reflected in the rendering of the current form... and
>> >> > elements that are likely to effect each other will tend to be on
>> >> > the same page...
>> >> > 
>> >> > do you have a concrete example of where you would find this
>> >> > concept useful? 
>> >> > 
>> >> > On Thu, 14 March 2002, "Anthony Eden" wrote:
>> >> > 
>> >> >> 
>> >> >> I was just thinking about how to handle submission of forms over
>> >> >> multiple pages or multiple dialogs or screens.  I am thinking of
>> >> >> something along the lines of sub forms or form chunks, where the
>> >> >> request could include the name of the sub form or chunk which
>> >> >> should be used for the current request.  Does anyone have any
>> >> >> thoughts on this?  Is this useful?
>> >> >> 
>> >> >> Sincerely,
>> >> >> Anthony Eden

Re: [FormProc-developer] Form handling over multiple pages or screens

[<ch...@ch...>]

Still not sure what you mean... "less fine grained" with regard to what?

On Thu, 14 March 2002, "Nick Bauman" wrote:

> 
> > I see tests quizes and examinations as groups of small validations...
> > perhaps on the individual question level... at least, that is how I
> > have implemented it in the past...
> 
> Right, that's how you'd do it, but I think Anthony wants something less 
> fine grained but still flexible enough.
> 
> > In that particular config file, are you able to reuse validators?
> 
> Godd question. Not yet but that's a minor tweak to the ConfigSaxHandler. 
> Next release.
>  
> > 
> > On Thu, 14 March 2002, "Nick Bauman" wrote:
> > 
> >> 
> >> Legit forms that fall into this catagory are examinations, tests and 
> >> quizzes. I'm not sure I know of a good way to solve this problem right
> >> off  the bat.
> >> 
> >> BTW, maybe I'm just stupid, but I still think the whole config file
> >> format  for FormProc is overly complex. In Integradata, a form config
> >> is this  simple:
> >>  
> >> <?xml version="1.0" encoding="ISO-8859-1"?> 
> >> <integradata> 
> >>   <!-- any number of controllers can be in a config --> 
> >>   <controller 
> >>       controllerClass="com.xyz.servlet.controllers.PurchaseProduct"> 
> >>     <field label="nameAppearingOnCard"> 
> >>       <rule ruleClass="com.cortexity.integradata.rule.StringLength"> 
> >>         <param name="min" value="9"/> 
> >>         <param name="max" value="32"/> 
> >>       </rule> 
> >>       <rule ruleClass="com.cortexity.integradata.rule.WordCount"> 
> >>         <param name="min" value="2"/> 
> >>         <param name="max" value="4"/> 
> >>       </rule> 
> >>     </field> 
> >>     <field label="creditCardNumber"> 
> >>       <rule ruleClass="com.cortexity.integradata.rule.IsCreditCard"> 
> >>         <param name="american_express" value="true"/> 
> >>         <param name="visa" value="true"/> 
> >>         <param name="mastercard" value="true"/> 
> >>       </field> 
> >>     </controller> 
> >>     <!-- ... --> 
> >> </integradata> 
> >> 
> >> Since error messages don't change that often, I think it's a mistake
> >> to put  them in the config. I put them into i18n codepages. You pass a
> >> locale to  the engine and the error message of the correct i18n
> >> codepage is displayed.  Of course it's all aimed at MVC Model II right
> >> now.
> >> 
> >> Incidentally, the concept of a "rule" is similar to FormProc's concept
> >> of  a "validator". 
> >> 
> >> > not sure i would find this useful.. I try and keep my forms as
> >> > "stand alone" as possible.. i.e. a choice made on an earlier form is
> >> > already reflected in the rendering of the current form... and
> >> > elements that are likely to effect each other will tend to be on the
> >> > same page...
> >> > 
> >> > do you have a concrete example of where you would find this concept
> >> > useful? 
> >> > 
> >> > On Thu, 14 March 2002, "Anthony Eden" wrote:
> >> > 
> >> >> 
> >> >> I was just thinking about how to handle submission of forms over
> >> >> multiple pages or multiple dialogs or screens.  I am thinking of
> >> >> something along the lines of sub forms or form chunks, where the
> >> >> request could include the name of the sub form or chunk which
> >> >> should be used for the current request.  Does anyone have any
> >> >> thoughts on this?  Is this useful?
> >> >> 
> >> >> Sincerely,
> >> >> Anthony Eden
> >> >> 
> >> >> 
> >> >> _______________________________________________
> >> >> 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 
> >> "It Is The Fate Of All Operating 
> >> Systems To Become Free" -- Neal Stephenson
> >> 
> >> 
> >> _______________________________________________
> >> 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 
> "It Is The Fate Of All Operating 
> Systems To Become Free" -- Neal Stephenson

Re: [FormProc-developer] Form handling over multiple pages or screens

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

> I see tests quizes and examinations as groups of small validations...
> perhaps on the individual question level... at least, that is how I
> have implemented it in the past...

Right, that's how you'd do it, but I think Anthony wants something less 
fine grained but still flexible enough.

> In that particular config file, are you able to reuse validators?

Godd question. Not yet but that's a minor tweak to the ConfigSaxHandler. 
Next release.
 
> 
> On Thu, 14 March 2002, "Nick Bauman" wrote:
> 
>> 
>> Legit forms that fall into this catagory are examinations, tests and 
>> quizzes. I'm not sure I know of a good way to solve this problem right
>> off  the bat.
>> 
>> BTW, maybe I'm just stupid, but I still think the whole config file
>> format  for FormProc is overly complex. In Integradata, a form config
>> is this  simple:
>>  
>> <?xml version="1.0" encoding="ISO-8859-1"?> 
>> <integradata> 
>>   <!-- any number of controllers can be in a config --> 
>>   <controller 
>>       controllerClass="com.xyz.servlet.controllers.PurchaseProduct"> 
>>     <field label="nameAppearingOnCard"> 
>>       <rule ruleClass="com.cortexity.integradata.rule.StringLength"> 
>>         <param name="min" value="9"/> 
>>         <param name="max" value="32"/> 
>>       </rule> 
>>       <rule ruleClass="com.cortexity.integradata.rule.WordCount"> 
>>         <param name="min" value="2"/> 
>>         <param name="max" value="4"/> 
>>       </rule> 
>>     </field> 
>>     <field label="creditCardNumber"> 
>>       <rule ruleClass="com.cortexity.integradata.rule.IsCreditCard"> 
>>         <param name="american_express" value="true"/> 
>>         <param name="visa" value="true"/> 
>>         <param name="mastercard" value="true"/> 
>>       </field> 
>>     </controller> 
>>     <!-- ... --> 
>> </integradata> 
>> 
>> Since error messages don't change that often, I think it's a mistake
>> to put  them in the config. I put them into i18n codepages. You pass a
>> locale to  the engine and the error message of the correct i18n
>> codepage is displayed.  Of course it's all aimed at MVC Model II right
>> now.
>> 
>> Incidentally, the concept of a "rule" is similar to FormProc's concept
>> of  a "validator". 
>> 
>> > not sure i would find this useful.. I try and keep my forms as
>> > "stand alone" as possible.. i.e. a choice made on an earlier form is
>> > already reflected in the rendering of the current form... and
>> > elements that are likely to effect each other will tend to be on the
>> > same page...
>> > 
>> > do you have a concrete example of where you would find this concept
>> > useful? 
>> > 
>> > On Thu, 14 March 2002, "Anthony Eden" wrote:
>> > 
>> >> 
>> >> I was just thinking about how to handle submission of forms over
>> >> multiple pages or multiple dialogs or screens.  I am thinking of
>> >> something along the lines of sub forms or form chunks, where the
>> >> request could include the name of the sub form or chunk which
>> >> should be used for the current request.  Does anyone have any
>> >> thoughts on this?  Is this useful?
>> >> 
>> >> Sincerely,
>> >> Anthony Eden
>> >> 
>> >> 
>> >> _______________________________________________
>> >> 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 
>> "It Is The Fate Of All Operating 
>> Systems To Become Free" -- Neal Stephenson
>> 
>> 
>> _______________________________________________
>> 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 
"It Is The Fate Of All Operating 
Systems To Become Free" -- Neal Stephenson

Re: [FormProc-developer] Form handling over multiple pages or screens

[Dan B. <ch...@ch...>]

I see tests quizes and examinations as groups of small validations... perhaps on the individual question level... at least, that is how I have implemented it in the past...


In that particular config file, are you able to reuse validators?


On Thu, 14 March 2002, "Nick Bauman" wrote:

> 
> Legit forms that fall into this catagory are examinations, tests and 
> quizzes. I'm not sure I know of a good way to solve this problem right off 
> the bat.
> 
> BTW, maybe I'm just stupid, but I still think the whole config file format 
> for FormProc is overly complex. In Integradata, a form config is this 
> simple:
>  
> <?xml version="1.0" encoding="ISO-8859-1"?> 
> <integradata> 
>   <!-- any number of controllers can be in a config --> 
>   <controller 
>       controllerClass="com.xyz.servlet.controllers.PurchaseProduct"> 
>     <field label="nameAppearingOnCard"> 
>       <rule ruleClass="com.cortexity.integradata.rule.StringLength"> 
>         <param name="min" value="9"/> 
>         <param name="max" value="32"/> 
>       </rule> 
>       <rule ruleClass="com.cortexity.integradata.rule.WordCount"> 
>         <param name="min" value="2"/> 
>         <param name="max" value="4"/> 
>       </rule> 
>     </field> 
>     <field label="creditCardNumber"> 
>       <rule ruleClass="com.cortexity.integradata.rule.IsCreditCard"> 
>         <param name="american_express" value="true"/> 
>         <param name="visa" value="true"/> 
>         <param name="mastercard" value="true"/> 
>       </field> 
>     </controller> 
>     <!-- ... --> 
> </integradata> 
> 
> Since error messages don't change that often, I think it's a mistake to put 
> them in the config. I put them into i18n codepages. You pass a locale to 
> the engine and the error message of the correct i18n codepage is displayed. 
> Of course it's all aimed at MVC Model II right now.
> 
> Incidentally, the concept of a "rule" is similar to FormProc's concept of 
> a "validator". 
> 
> > not sure i would find this useful.. I try and keep my forms as "stand
> > alone" as possible.. i.e. a choice made on an earlier form is already
> > reflected in the rendering of the current form... and elements that are
> > likely to effect each other will tend to be on the same page...
> > 
> > do you have a concrete example of where you would find this concept
> > useful? 
> > 
> > On Thu, 14 March 2002, "Anthony Eden" wrote:
> > 
> >> 
> >> I was just thinking about how to handle submission of forms over
> >> multiple pages or multiple dialogs or screens.  I am thinking of
> >> something along the lines of sub forms or form chunks, where the
> >> request could include the name of the sub form or chunk which should
> >> be used for the current request.  Does anyone have any thoughts on
> >> this?  Is this useful?
> >> 
> >> Sincerely,
> >> Anthony Eden
> >> 
> >> 
> >> _______________________________________________
> >> 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 
> "It Is The Fate Of All Operating 
> Systems To Become Free" -- Neal Stephenson
> 
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer

Re: [FormProc-developer] Form handling over multiple pages or screens

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

Legit forms that fall into this catagory are examinations, tests and 
quizzes. I'm not sure I know of a good way to solve this problem right off 
the bat.

BTW, maybe I'm just stupid, but I still think the whole config file format 
for FormProc is overly complex. In Integradata, a form config is this 
simple:
 
<?xml version="1.0" encoding="ISO-8859-1"?> 
<integradata> 
  <!-- any number of controllers can be in a config --> 
  <controller 
      controllerClass="com.xyz.servlet.controllers.PurchaseProduct"> 
    <field label="nameAppearingOnCard"> 
      <rule ruleClass="com.cortexity.integradata.rule.StringLength"> 
        <param name="min" value="9"/> 
        <param name="max" value="32"/> 
      </rule> 
      <rule ruleClass="com.cortexity.integradata.rule.WordCount"> 
        <param name="min" value="2"/> 
        <param name="max" value="4"/> 
      </rule> 
    </field> 
    <field label="creditCardNumber"> 
      <rule ruleClass="com.cortexity.integradata.rule.IsCreditCard"> 
        <param name="american_express" value="true"/> 
        <param name="visa" value="true"/> 
        <param name="mastercard" value="true"/> 
      </field> 
    </controller> 
    <!-- ... --> 
</integradata> 

Since error messages don't change that often, I think it's a mistake to put 
them in the config. I put them into i18n codepages. You pass a locale to 
the engine and the error message of the correct i18n codepage is displayed. 
Of course it's all aimed at MVC Model II right now.

Incidentally, the concept of a "rule" is similar to FormProc's concept of 
a "validator". 

> not sure i would find this useful.. I try and keep my forms as "stand
> alone" as possible.. i.e. a choice made on an earlier form is already
> reflected in the rendering of the current form... and elements that are
> likely to effect each other will tend to be on the same page...
> 
> do you have a concrete example of where you would find this concept
> useful? 
> 
> On Thu, 14 March 2002, "Anthony Eden" wrote:
> 
>> 
>> I was just thinking about how to handle submission of forms over
>> multiple pages or multiple dialogs or screens.  I am thinking of
>> something along the lines of sub forms or form chunks, where the
>> request could include the name of the sub form or chunk which should
>> be used for the current request.  Does anyone have any thoughts on
>> this?  Is this useful?
>> 
>> Sincerely,
>> Anthony Eden
>> 
>> 
>> _______________________________________________
>> 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 
"It Is The Fate Of All Operating 
Systems To Become Free" -- Neal Stephenson

RE: [FormProc-developer] Form handling over multiple pages or screens

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

One example:

In a web form, there will be times when it is easier for the end user if the form is broken up over several pages where
each page has groups together some common elements.  I do this regularly on my company's web site.  So, as it stands
right now, you would need one form configuration file for each page, even if ultimately all of the data were going to be
stored in the same business object.  The question is: "Is this a bad thing or a good thing?"

You can take this same concept and apply it to a desktop application as well if you have wizards.

Thanks for the feedback though.  I am not really sure that it is a good idea either, but I do know that I spread out
form processing across many pages on a regular basis, so I thought it might be useful.  I will probably not introduce
the idea into the code until after 1.0, if at all.

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of Dan
> Bachelder
> Sent: Thursday, March 14, 2002 4:23 PM
> To: for...@li...
> Subject: Re: [FormProc-developer] Form handling over multiple pages or
> screens
>
>
> not sure i would find this useful.. I try and keep my forms as "stand alone" as possible.. i.e. a choice made
> on an earlier form is already reflected in the rendering of the current form... and elements that are likely
> to effect each other will tend to be on the same page...
>
> do you have a concrete example of where you would find this concept useful?
>
> On Thu, 14 March 2002, "Anthony Eden" wrote:
>
> >
> > I was just thinking about how to handle submission of forms over multiple pages or multiple dialogs or
> screens.  I am
> > thinking of something along the lines of sub forms or form chunks, where the request could include the name
> of the sub
> > form or chunk which should be used for the current request.  Does anyone have any thoughts on this?  Is this useful?
> >
> > Sincerely,
> > Anthony Eden
> >
> >
> > _______________________________________________
> > 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
>

Re: [FormProc-developer] Form handling over multiple pages or screens

[Dan B. <ch...@ch...>]

not sure i would find this useful.. I try and keep my forms as "stand alone" as possible.. i.e. a choice made on an earlier form is already reflected in the rendering of the current form... and elements that are likely to effect each other will tend to be on the same page...

do you have a concrete example of where you would find this concept useful? 

On Thu, 14 March 2002, "Anthony Eden" wrote:

> 
> I was just thinking about how to handle submission of forms over multiple pages or multiple dialogs or screens.  I am
> thinking of something along the lines of sub forms or form chunks, where the request could include the name of the sub
> form or chunk which should be used for the current request.  Does anyone have any thoughts on this?  Is this useful?
> 
> Sincerely,
> Anthony Eden
> 
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer

[FormProc-developer] Form handling over multiple pages or screens

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

I was just thinking about how to handle submission of forms over multiple pages or multiple dialogs or screens.  I am
thinking of something along the lines of sub forms or form chunks, where the request could include the name of the sub
form or chunk which should be used for the current request.  Does anyone have any thoughts on this?  Is this useful?

Sincerely,
Anthony Eden

[FormProc-developer] API Redesign Complete

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

I have completed and tested the API redesign which I mentioned yesterday.  The new design does away with a separation of
element and group validators, favoring a unified validator interface (defined in the Validator abstract base class.)  I
have updated the examples and they seem to run fine and give valid results.  The new code is much cleaner and happily
reminds me of what it looked like prior to the current release.

So, for those who are interested, check out the current CVS code and have at it [ Dan ;-) ].

FWIW, I am going to try and make this the last revision to break the API significantly, so if you have any thoughts on
other possible areas which need to be modified to be more usable, please let me know.  I would like to release this next
revision as 0.9 and then go to 1.0 beta 1 as the following revision, so now is the time to make any necessary API
changes.

Sincerely,
Anthony Eden

[FormProc-developer] Note: Code in CVS is currently in flux

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

I just wanted to send a note out to everyone about the current state of the code in the CVS.  I made quite a few changes
this morning and last night to implement the changes that Dan and I were discussing.  Because of this the code in the
CVS  is currently broken.  While it will compile I do not believe that it will validate correctly.  I am going to try to
fix this today, but I felt that it was important that everyone knew so as to not cause any confusion.

FWIW, the new code is MUCH clearer.  Thanks Dan for the direction on this.

-Anthony

Re: [FormProc-developer] Simplifying the API

[Dan B. <da...@ch...>]

+1 ;)

On Wed, 2002-03-13 at 13:10, Anthony Eden wrote:
> Greetings all,
> 
> Dan and I have been discussing ways to simplify the validation part of the FormProc API.  The main issue is with the
> fact that group validators and element validators are currently treated as separate validator types.  This leads to
> confusing configuration files, more classes, etc.  Dan suggested that all element validators should be just considered a
> group of 1.  After some discussion back and forth we agreed upon the following validator API:
> 
>   public abstract ValidationResult validate(FormElement[] formElements, FormData[] formData) throws Exception;
> 
> Then, validators can either validate each element in the array individually using the same algorithm, or validators
> could look at the data as a single entity (i.e. the group validator behavior as it is currently defined.)
> 
> There will also be a change from the current behavior with respect to how forms are processed.  Currently the form data
> received dictates which elements are processed.  The new behavior will be that all elements defined in the form's XML
> configuration file will be processed, thus catching cases where no value is received from the client (and perhaps
> failing out because of that.)  This leads me to the question: what to with submitted data where there is no validator?
> The current behavior would just not validate and would only try to call the target object's write method with the data.
> If this is OK, I will keep this behavior.
> 
> Any opinions?  This will of course break the API once again, but it would greatly simplify it as well.  If you see any
> problems with this new design please speak your piece now before I go forward with the changes.
> 
> Sincerely,
> Anthony Eden
> 
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> 

[FormProc-developer] Simplifying the API

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

Greetings all,

Dan and I have been discussing ways to simplify the validation part of the FormProc API.  The main issue is with the
fact that group validators and element validators are currently treated as separate validator types.  This leads to
confusing configuration files, more classes, etc.  Dan suggested that all element validators should be just considered a
group of 1.  After some discussion back and forth we agreed upon the following validator API:

  public abstract ValidationResult validate(FormElement[] formElements, FormData[] formData) throws Exception;

Then, validators can either validate each element in the array individually using the same algorithm, or validators
could look at the data as a single entity (i.e. the group validator behavior as it is currently defined.)

There will also be a change from the current behavior with respect to how forms are processed.  Currently the form data
received dictates which elements are processed.  The new behavior will be that all elements defined in the form's XML
configuration file will be processed, thus catching cases where no value is received from the client (and perhaps
failing out because of that.)  This leads me to the question: what to with submitted data where there is no validator?
The current behavior would just not validate and would only try to call the target object's write method with the data.
If this is OK, I will keep this behavior.

Any opinions?  This will of course break the API once again, but it would greatly simplify it as well.  If you see any
problems with this new design please speak your piece now before I go forward with the changes.

Sincerely,
Anthony Eden

[FormProc-developer] Added MapStorer

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

I added a MapStorer implementation to the CVS just to see how hard it
would be - the good news is it is very easy (takes a couple of minutes
for something simple like the Map example.)  Does anyone have any other
interesting ideas on how to use this new feature?

Sincerely,
Anthony Eden

[FormProc-developer] Storer interface

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

I have added the org.formproc.store.Storer interface and a single
implementation, the org.formproc.store.ReflectionStorer to the FormProc
CVS.  The idea here is that the system for writing field values to your
object can be defined at runtime by specifying an alternate Storer
implementation for a particular FormElement:

<element name="firstName">
	<storer classname="com.mycompany.MyStorer"/>
</element>

If no storer is specified then the default storer is used.  Currently
the default storer is always the ReflectionStorer - I can imagine that
the default storer should be configurable.  Do you agree?

I haven't tested out an alternate storer yet, but one possible use would
be to store all of the field data in a HashMap.

In addition I have modified the Form class so that some of the methods
which used to be private are now protected (in case you want to overload
some of the functionality).

Sincerely,
Anthony Eden

[FormProc-developer] FormProc 0.8 Released

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

FormProc version 0.8 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.

This release includes the following changes: Added support for FormElement
groups and validators which are applied to these groups. Renamed classes to
provide more accurate names. Form.process() now returns a FormResult object.
Added TypeConverter classes for converting types before calling the target
object's write methods. Upgraded to EdenLib 1.0b4.  Removed xerces.jar and
jdom.jar.  Now using JAXP and Crimson for configuration parsing. Updated
examples and documentation to demonstrate new features.

For more information please visit http://formproc.sf.net/ or contact Anthony
Eden [me...@an...].  You can also join the FormProc mailing list at
http://lists.sourceforge.net/lists/listinfo/formproc-developer

[FormProc-developer] New Code in CVS

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

Greetings all,

The code in the CVS is finally in a stable state.  I have added support for
element groups and validation on said groups.  The group validators can
either be Java classes which extend from the FormElementGroupValidator base
class or scripts written in a BSF scripting language (same as
FormElementValidators).  I have also changed a number of the class names to
provide a more accurate naming system.  The Form.process() method now
returns a FormResult object which will allow you to determine if all
validators (element and group) passed.  It also gives you access to the
ValidationResultMaps for element and groups.

I have also updated the example applications to demonstrate the new grouping
feature.  I hope everyone enjoys these enhancements.  I plan on doing a bit
of documentation work and then will provide a new release within the next
few days.  If you see any problems please post them to the list so I can fix
them before the release.

Sincerely,
Anthony Eden

[FormProc-developer] Recent Changes

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

Greetings all,

I am currently making changes to FormProc which will break existing code if:

a.) You have written your own validator classes which extend from
FormValidator
b.) You are using the ValidationResult.getFormData() method

These changes are necessary in order to further abstract validators to
support both validators which work on a single FormElement as well as
validators which work on a FormElementGroup.  In addition, I am using this
time to try and make the class naming a bit clearer (i.e. FormValidator
becomes FormElementValidator, since that is what it really is.)

Any major objections?

Sincerely,
Anthony Eden