formproc-developer

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

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

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

At 10:58 AM -0500 2/17/02, Anthony Eden wrote:
>I downloaded the jwaa but I could only find some of the fields you
>mention.

You have the current release. I copied these from my the development 
system (next release).

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

I'm never tried to boil the ocean by defining every possible field 
type, just the ones I've encountered in my work. You don't provide 
validators for every possible field type either, just a tool for 
users to define their own via config files.

We've a paradigm block here that I doubt can be solved. You dislike 
compiling and see configuration files as the solution to flexibility. 
I have no problem with compiling and see editing java source and 
compiling as less error prone (reliable  diagnostics) than editing 
config files. You see fields as mutable and ever changing. I see them 
as atoms; immutable, reusable components that are rarely changed once 
they've been adopted, during which reusers will edit them to adopt 
them to local conditions.

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

As I said, I see modifying java source as more reliable (better 
diagnostics) than editing config files and with jikes, just as fast. 
You see it the opposite way. You see "needing to extend or modify" as 
a problem. I see it as the solution, certainly until config file 
systems give serious attention to  detecting and reporting errors at 
load time rather than leaving it to the application to run into them 
at run time.

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

So it goes. To each his own. ;)
-- 
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

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

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

> -----Original Message-----
> From: Brad Cox [mailto:bc...@vi...] 
> Sent: Sunday, February 17, 2002 11:35 AM
> To: Anthony Eden; FormProc Developer List
> Subject: RE: [JPublish-developer] RE: [FormProc-developer] 
> Re: Why FormProc? Was RE: [ANN] JPublish 0.8 Released
> 
> 
> At 10:58 AM -0500 2/17/02, Anthony Eden wrote:
> >I downloaded the jwaa but I could only find some of the fields you 
> >mention.
> 
> You have the current release. I copied these from my the development 
> system (next release).

OK.

> >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.
>
> I'm never tried to boil the ocean by defining every possible field 
> type, just the ones I've encountered in my work. You don't provide 
> validators for every possible field type either, just a tool for 
> users to define their own via config files.

I think that you still ought to consider some of the advantages of
configuration based systems.  Consider that with FormProc you can
include locale-specific messages, group validators and fields together
(the latter being a new feature of the next release) and more without
having to write any Java code.  Just the i18n issue alone is difficult
to solve without externalizing your resources.  I know that you are
solving just your problem with your framework, but my intention with
FormProc is that it should solve my problems AND other developer's
problems as well, with the easiest solution.
 
> We've a paradigm block here that I doubt can be solved. You dislike 
> compiling and see configuration files as the solution to flexibility. 
> I have no problem with compiling and see editing java source and 
> compiling as less error prone (reliable  diagnostics) than editing 
> config files. You see fields as mutable and ever changing. I see them 
> as atoms; immutable, reusable components that are rarely changed once 
> they've been adopted, during which reusers will edit them to adopt 
> them to local conditions.
> 
> >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.
> 
> As I said, I see modifying java source as more reliable (better 
> diagnostics) than editing config files and with jikes, just as fast. 
> You see it the opposite way. You see "needing to extend or modify" as 
> a problem. I see it as the solution, certainly until config file 
> systems give serious attention to  detecting and reporting errors at 
> load time rather than leaving it to the application to run into them 
> at run time.

FWIW, FormProc does attempt to detect and report errors at load time.
It may not be perfect at this point, but rest assured that I am thinking
about it.

> >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.
> 
> So it goes. To each his own. ;)

Right.  Nothing wrong with that.

Sincerely,
Anthony Eden

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

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

At 7:38 AM -0500 2/18/02, Anthony Eden wrote:
Just the i18n issue alone is difficult
>to solve without externalizing your resources.

Agreed.

>FWIW, FormProc does attempt to detect and report errors at load time.
>It may not be perfect at this point, but rest assured that I am thinking
>about it.

Please keep me posted on you progress and thanks for a most 
productive discussion!
-- 
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