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