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.