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

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...>]

> 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

[<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: 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: 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...>]

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

[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...>]

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 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 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?
> 
> 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.