From: Anthony E. <me...@an...> - 2001-11-20 04:34:31
|
Right now there is a single error message for each field because there is a single validator. I can see the value in allowing error messages for each validator though. As far as multiple validators I have checked in a class to CVS called FormValidatorGroup. I have not yet added the configuration routines, but it is essentially a collection of FormValidators which must all be valid for a successful validation. The FormValidatorGroup extends from AbstractFormValidator so it can be used in the same place as any other FormValidator. I will add the configuration logic tomorrow. Sincerely, Anthony Eden > -----Original Message----- > From: for...@li... > [mailto:for...@li...]On Behalf Of Nick > Bauman > Sent: Monday, November 19, 2001 3:32 PM > To: for...@li... > Subject: Re: [FormProc-developer] Integradata and FormProc working > together > > > > 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/ > > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer > > |