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