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

[Brad C. <bc...@vi...>]

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

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

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

package edu.virtualschool.field;

import edu.virtualschool.jwaa.BeanFault;
import edu.virtualschool.jwaa.SqlResults;
import edu.virtualschool.jwaa.Validatable;
import gnu.regexp.RE;
import java.lang.Object;
import java.lang.String;

public class Zipcode
	extends edu.virtualschool.field.StringField
{
	private final static RE re = re("\\d{5}([ -_]\\d{4})?");
	public final static Zipcode Null = new Zipcode("");

	public Zipcode(String value)
	{
		super(value);
		requireNonNull();
		requireMatch(re, "Expecting a 5- or 9-disit zipcode");
	}
	public final Validatable replica(String v) { return new Zipcode(v); }
	public final int getMaxWidth() { return 9; }
	public static Zipcode load(String n, SqlResults r) throws BeanFault
	{ return new Zipcode(r.getString(n)); }
	public final static String getSqlDefinition()
	{
		return "varchar(9) NOT NULL DEFAULT ''";
	}
}


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

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