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

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

Response inline.

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...] On 
> Behalf Of Brad Cox
> Sent: Saturday, February 16, 2002 8:12 PM
> To: FormProc Developer List
> Subject: [FormProc-developer] Re: Why FormProc? Was RE: [ANN] 
> JPublish 0.8 Released
> 
> 
> Thanks for the most helpful response, Anthony. I've moved this
> on-list as you requested.
> 
> At 7:10 PM -0500 2/16/02, Anthony Eden wrote:
> >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.
> 
> The source is at http://virtualschool.edu/jwaa, but I've enclosed the
> Zipcode class as a sample below. The business logic clutter problem 
> can't happen; business logic goes at a separate higher level (beans 
> == models == molecules).

After looking over it a bit (at the site) I understand more about how
your fields are defined.

> 
> Field classes are the atoms from which beans are composed. Fields are
> a particularly nice unit of reuse because users immediately know what 
> they are. They're concretions, not abstractions; everybody knows what 
> a Zipcode is, which makes them uniquely easy to define, collect, and 
> reuse.

I can see the validity in this argument.  Strongly typed can be a good
thing.

> I've been experimenting with making Fields double-faced objects,
> where one side provides Validation to the user interface and the 
> other side database load/save services. You'll see signs of this in 
> the sample. The word's still out on that.
> 
> >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.
> 
> The Zipcode sample uses regular expresssions too and can be reused
> over and over. True, the Zipcode class needs to be recompiled if 
> zipcodes ever change. But I really don't see this as objectionable 
> since Zipcode definition changes infrequently. And besides, I find it 
> far more straightforward to edit java source code configuration files.

While zip code rules may not change on a regular basis there are other
more complicated validation rules which are modified more often.  In
addition, there are rules which are specific to a particular application
but will not be the same on the next app (for example one app may have
more stringent password validation rules than another).

> 
> But the main argument is the atoms vs molecules issue. Atoms should
> be, well, atomic. Indivisible. Immutable. Hardcoded and all that.
> 
> >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.
> 
> Yes, that's clear. But the atoms thing again. I feel atoms should be
> immutable and buried, not on the boundary where either side can 
> change them.

I suppose I just have a different opinion.  I believe that it is best to
maintain mutability for the purpose of being more flexible as systems
change.  The less I have to compile, the better.

Sincerely,
Anthony Eden