RE: [FormProc-developer] RE: Validation by type

[Anthony E. <me...@an...>]

Eric,

I have been thinking a bit more about your request.  I have a different
approach that I am considering and I wanted to run it by you  to see what
you think.

I would rather keep the one-to-one relationship between an HTML form widget
and the FormElement class.  My reason for this is that the FormElement does
more than just validation - it also maps the form field to a write method on
a target object.  Thus having a single FormElement for multiple form widgets
would be problematic for auto-populating the target object.

As an alternative solution I propose that you should be able to create
validator configurations which can be defined once (say in your formproc.xml
configuration file) and then the form configuration file can have something
like this:

<form>
	<element name="homePhone">
		<validator type="shared" name="phone"/>
	</element>
	<element name="workPhone">
		<validator type="shared" name="phone"/>
	</element>
</form>

Doing it this way would allow the current API to remain untouched yet would
provide the ability to reuse complex validators.  What do you think?

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of Eric
> Beaumier
> Sent: Tuesday, January 22, 2002 12:02 PM
> To: for...@li...
> Subject: [FormProc-developer] RE: Validation by type
>
>
>
> Hi Anthony,
>
> The goal of this demand, it's just to give the option to the user,
> to use FormProc as "validation by name" or "validation by type".  It's
> not necessarily for a DBForms compatibility.
>
>
> If I re-use the same example, here I have 4 textfields using the same
> type of validation ("phoneCanada") and it can be re-use again in
> several other JSP pages.
>
> <db:textField fieldName="phoneWork" fieldValidator="phoneCanada"/>
> <db:textField fieldName="phoneHome" fieldValidator="phoneCanada"/>
> <db:textField fieldName="phoneCell" fieldValidator="phoneCanada"/>
> <db:textField fieldName="fax"       fieldValidator="phoneCanada"/>
>
> Actually, if I want to do validation, I need to create 4 elements
> ("phoneWork", "phoneHome", "phoneCell", "fax") in "example-form.xml"
> and if fieldname haven't the same name in other JSP pages, we
> must to create
> as much of elements in "example-form.xml" as we have differents
> fieldnames ...
>
> Like this we will do a lot of duplication of element/validator and in
> reel, it's the same validation.
>
>
>
> To continue, maybe we can re-use FormProc for parameter validator
> in EJB, Web apps, Web Service, ... on the same server.  This give you
> the opportunity to declare "Enterprise Validation Type" (EVT).
> You declare each type of validator in your xml file and it can be
> re-use by any kind of applications on this server ...   or remotly
> using EJB.
>
> Because enterprise web server contains a lot of differents web
> apps on the
> same server and frequently use the same validation type, like this
> we can re-use it ...
>
> By adding the "context" (getter/setter) to the "FormData" class,
> when we call the process method, we will be enable to pass a context
> of this validation.
>
> ArrayList formDataList = new ArrayList();
> formDataList.add(new FormData("phoneCanada",
>                               request("phoneWork"),"phoneWork"));
> formDataList.add(new FormData("phoneCanada",
>                               request("phoneHome"),"phoneHome"));
> ...
>
> But if a user want to work in "name" mode, it can continue to use
> the FormData("elementName", "value") constructor.
>
>
> Naturally, we need to be enable to retrieve the context in validation
> result.
>
> I think it's a good way to manage re-usable validation of data.  Without
> modifying the core of FormProc.
>
>
> Thanks.
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp.
>
>
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
>