Response inline.
> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...] On
> Behalf Of Brad Cox
> Sent: Saturday, February 16, 2002 8:31 PM
> To: FormProc Developer List
> Subject: [FormProc-developer] Re: Why FormProc? Was RE: [ANN]
> JPublish 0.8 Released
>
>
> At 7:10 PM -0500 2/16/02, Anthony Eden wrote:
>
> Oh yes, one other thing. The http://virtualschool.edu/jwaa article
> discusses another difference at some length. With my approach, the
> rest of the application is written in terms of Fields (Name, Zipcode,
> etc) which are converted to Strings only at the last moment before
> hitting the database.
>
> My understanding is that with FormProc, fields are converted to
> Strings once validated. If so, the application winds up being
> declared in terms of Strings, not in descriptive types like Zipcode.
Well, I wouldn't say they are converted to Strings, rather they are
maintained as Strings as that is what both HTML and Swing fields tend to
produce. I can see the value of converting to strongly typed objects,
but I find that pretty easy to do with method overloading:
public void setZipCode(ZipCode zipCode){ this.zipCode = zipCode; }
public void setZipCode(String zipCode){ this.zipCode = new
ZipCode(zipCode); }
>
> So I get to write higher level classes like this:
> new Address(Name n, Street s, City c, Zipcode z, State s);
> not like this:
> new Address(String n, String s, String c, ...
Once again, an interesting approach, but doing this:
new Address(String name, String street, String city, String zipCode,
String state) is just as clear. Another possible argument is that the
first method may result in class overload. Then again, maybe not. :-)
Sincerely,
Anthony Eden
|
