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

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

I downloaded the jwaa but I could only find some of the fields you
mention.

Looking at the code that is there I still worry about the design.  I see
no support for i18n and the validation logic seems to be rather
simplistic.  I'm not saying that this is a bad thing, but when others
start to use and extend your system, you will start to see the number of
classes required to handle different types of fields increase.  Over
time I think that it would start to become bloated.

Additionally, I keep coming back to the fact that these fields need to
be recompiled to handle validation changes.  What happens if you need to
handle international phone numbers, zip codes, etc.  I would have to
extend or modify your classes and recompile to handle that and this just
seems like a lot of extra work.  Finally, if your regular expression is
wrong you still have to debug that at runtime.

I want to stress that I don't think your approach is wrong, I just think
that the runtime configuration approach is better for a general purpose
validation framework, which is what FormProc is.

Sincerely,
Anthony Eden

> -----Original Message-----
> From: Brad Cox [mailto:bc...@vi...] 
> Sent: Sunday, February 17, 2002 9:21 AM
> To: Anthony Eden; jpu...@li...
> Subject: [JPublish-developer] RE: [FormProc-developer] Re: 
> Why FormProc? Was RE: [ANN] JPublish 0.8 Released
> 
> 
> At 10:54 PM -0500 2/16/02, Anthony Eden wrote:
> >>    Another possible argument is that the
> >>  >first method may result in class overload.  Then again,  
> maybe not. 
> >> :-)
> >>
> >>  Don't follow that. What's class overload? Never a hint of 
> a problem  
> >> with the mybank system at least, which is HUGE.
> >
> >I mean an abundance of very small classes.  There seems to be a nice 
> >balance between too many small classes and a few large classes.  I 
> >worry that one class for each field type may result in too 
> many small 
> >classes which become unwieldly over time, especially when 
> the system is 
> >handed off to other developers for maintainence and 
> extension.  Is the 
> >code for mybank available?  How many classes are we talking? 
>  How many 
> >developers?  Is it a production system which has evolved over time?
> 
> Fields are reusable so they're packaged with the jwaa substrate, not 
> mybank. Applications sometimes extend the hierarchy with internal 
> classes for credit card numbers and so forth. Here's the full 
> edu.virtualschool.field package, including test cases. They are 
> reused by all of the projects in my .sig. I'm the sole developer 
> currently.
> 
> I see little likelihood of overload. There are only so many field 
> types in the world after all and such things only rarely change.
> 
> AbstractID.java
> City.java
> CityTest.java
> Country.java
> DateField.java
> DateFieldTest.java
> Description.java
> Discussion.java
> DoubleField.java
> Email.java
> EmailTest.java
> FieldFault.java
> FilePath.java
> FinancialAmount.java
> FinancialAmountTest.java
> GradeField.java
> Identifier.java
> IntegerField.java
> LongField.java
> Menu.java
> Month.java
> MonthTest.java
> Name.java
> NameTest.java
> Op.java
> Pass.java
> PassTest.java
> PathField.java
> Percent.java
> Phone.java
> PhoneTest.java
> Street.java
> StringField.java
> Union.java
> Url.java
> USState.java
> USStateTest.java
> YesNo.java
> YesNoTest.java
> Zipcode.java
> ZipcodeTest.java
> -- 
> 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
> 
>