Re: [FormProc-developer] Integradata and FormProc working together

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

> This is a suggestion for future development.  I think it would be a
> 'nice-to-have' feature.
> 
> I was looking at Nick Bauman's API and noticed that his RuleResult
> class holds the error message while FormProc's getMessage method is in
> the FormElement.

Correct, and I know this is a problem with Integradata. However, my thinking
is this:

I like that Anthony has I18N error messages "built right in", which
Integradata doesn't have (right now). He does this by putting the error
message in the XML. But since the Rule knows why, how and when it's field is
invalid, the Rule should return a specific result code, which then is mapped
to subsequent I18N responses, either in a properties file in the distro or
in the XML. The point is, you shouldn't be forced to put the error message
in there if you don't want to. 

Also, Integradata will soon optionally autogenerate Javascript validation
functions for validation _on the front end_ too, which I hope Anthony's lib
will be able to adopt as well!

This is where Integradata is going. If we can go there together, we can
leverage the strengths of choice, cohesiveness of each other's parts and
scale the maintainability appropriately: a win-win for both FormProc and
Integradata.

> It looks to me like this design prevents FormProc from being able to
> implement multiple rules.

If this is true, this is definitely a problem. Integradata does not have
this limitation. Your illustration of a valid case for having multiple rules
per field is right on the money.

> For example, I think it would be useful to be able to configure a field
> like this:
> 
> <element name="postalcode">
> 
>   <!-- Rule for making the field required -->
>   <validator type="rule">
>     <rule>org.formproc.example.RequiredRule</rule>
>     <error lang="en">This field is required</error>
>   </validator>
> 
>   <!-- Rule for validating a Canadian Postal Code -->
>   <validator type="rule">
>     <rule>org.formproc.example.CanPostalCodeRule</rule>
>     <error lang="en">This is not a valid Canadian Postal Code</error>
>   </validator>
> 
>   <message lang="en">Please enter a valid postal code</message>
> 
> </element>
> 
> 
> The first rule would be evaluated, and if the field is blank then the
> user would be given the "This field is required" message.  If the field
> is entered, but the postal code is invalid, then the second rule is
> evaluated and he/she would be presented with the invalid postal code
> message.
> 
> It also seems logical to me that the error message would be a property
> of the validator for a particular field.
> 
> This change might make porting/merging Nick's rules easier as well.

Yup, agreed.

> 
> Regards,
> -Kerry
> 
> -- 
> Kerry Todyruik <ke...@to...>
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer


-- 
Nick Bauman 
Cortexity Development
Intellectual Process is more important than
Intellectual Property -- you'll see.
http://www.cortexity.com/