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