[FormProc-developer] Why FormProc? Was RE: [ANN] JPublish 0.8 Released

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

The method of validation you describe is perfectly valid (no pun
intended).  One of the downsides is that it may be more complicated to
reuse your field objects from application to application than an
equivalent FormProc field definition, although I would have to see your
actual code to verify that.  In addition to the potential problem of
reuse, having the validation logic mixed in with your business logic
could potentially clutter your code, but again I would have to see your
code in order to say whether or not this is true.

Ultimately it comes down to simplifying validation.  It is very easy
with FormProc to define validation of phone numbers as a regular
expression and then reuse the validation rule over and over.  Thanks to
the extensibility of FormProc others have even created complicated
validation logic such as credit card number validators which can be
reused by many developers.

One final advantage is that while you may be working with systems where
validation logic is stable and defined by your SQL database, there are
many systems out there which must rely on validation rules provided by
other parties, and those rules do change.  In your system you would have
to modify your code and recompile, whereas with FormProc you could
potentially just change the regular expression or validation script and
you are done.

You mention that you want validation to be in the programmers
realm...since FormProc is essentially a middle layer it can be
controlled by the programmers, deployers, or whoever your organization
determines is the most appropriate controller for that logic.

I hope this sheds some light on the subject.  If you would like to
discuss this further then perhaps we can do so in the FormProc mailing
list and others may be able to offer different reasons for having form
validation separate from business objects.

Sincerely,
Anthony Eden

> -----Original Message-----
> From: Brad Cox [mailto:bc...@vi...] 
> Sent: Saturday, February 16, 2002 10:56 AM
> To: Brad Cox; Anthony Eden
> Subject: RE: [ANN] JPublish 0.8 Released
> 
> 
> At 10:05 AM -0500 2/16/02, Brad Cox wrote:
> >At 8:51 AM -0500 2/16/02, Anthony Eden wrote:
> >>I saw that.  Your work sounds interesting.  Any idea when 
> the initial 
> >>revision will be available?
> 
> Anthony, I've started looking into JPublish and FormProc and have a 
> few early questions; probably more to come.
> 
> The biggest is formproc's approach to validation. Your user class for 
> example, defines a User bean with fields for Name, etc, which it 
> returns to the app as Strings, with validation rules provided 
> externally, via xml.
> 
> But my mind is conditioned to see fields as the lowest-level atoms 
> from which webapps are composed, since assumptions about them 
> (maximum length for example) will end up hardwired into sql table 
> definitions). In this view, fields are defined statically, at compile 
> time, since dynamic definition is likely to break things.
> 
> I deal with this by hardcoding Java classes for every field (Name, 
> PhoneNumber, State, Country), with the validation rules coded into 
> each class. E.g. there is no central FormValidator because each field 
> validates itself. The idea is to push field definitions and 
> validation firmly into the programmer's domain where they are out of 
> the end-user's view. User code never sees Strings, just Fields.
> 
> There's a discussion of this at http://virtualschool.edu/jwaa towards 
> the middle, under "Fields are objects, not Strings" or similar. I'd 
> value your comments; I've not used FormProc enough to be confident in 
> my understanding.
> -- 
> Brad Cox, PhD; bc...@vi... 703 361 4751
> o For industrial age goods there were checks and credit cards.
>     For everything else there is 
> http://virtualschool.edu/mybank o Java > Interactive Learning 
> Environment http://virtualschool.edu/jile o Java Web 
> Application Architecture: http://virtualschool.edu/jwaa
> 
>