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

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

Anthony said:

> 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.

I have to agree with Anthony on this one. He points out all the valid 
reasons regarding data validation: ie, reuse, uncoupling and specificity to 
the problem.

> 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.

BTW: Anthony, my credit card validator (Rule) now supports 7 different 
cards that are deploy-time configurable, and will correctly speak whatever 
language your client understands (based on Locale).

> 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.

A deploy-time tweak, in other words.

> 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.

Whereas simplicty is the key.
 
> 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
>> 
>> 
> 
> 
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer


-- 
Nick Bauman 
"It Is The Fate Of All Operating 
Systems To Become Free" -- Neal Stephenson