From: Anthony E. <me...@an...> - 2002-02-17 00:13:31
|
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. 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. One final advantage is that while you may be working with systems where validation logic is stable and defined by your SQL database, there are many systems out there which must rely on validation rules provided by other parties, and those rules do change. In your system you would have to modify your code and recompile, whereas with FormProc you could potentially just change the regular expression or validation script and you are done. 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. 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. Sincerely, Anthony Eden > -----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 > > |
From: Nick B. <ni...@co...> - 2002-02-17 01:06:24
|
Anthony said: > 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. I have to agree with Anthony on this one. He points out all the valid reasons regarding data validation: ie, reuse, uncoupling and specificity to the problem. > 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. BTW: Anthony, my credit card validator (Rule) now supports 7 different cards that are deploy-time configurable, and will correctly speak whatever language your client understands (based on Locale). > One final advantage is that while you may be working with systems where > validation logic is stable and defined by your SQL database, there are > many systems out there which must rely on validation rules provided by > other parties, and those rules do change. In your system you would > have to modify your code and recompile, whereas with FormProc you could > potentially just change the regular expression or validation script and > you are done. A deploy-time tweak, in other words. > 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. Whereas simplicty is the key. > 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. > > Sincerely, > Anthony Eden > >> -----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 >> >> > > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer -- Nick Bauman "It Is The Fate Of All Operating Systems To Become Free" -- Neal Stephenson |
From: Brad C. <bc...@vi...> - 2002-02-17 01:13:54
|
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 |
From: Anthony E. <me...@an...> - 2002-02-17 02:10:18
|
Response inline. > -----Original Message----- > From: for...@li... > [mailto:for...@li...] On > Behalf Of Brad Cox > Sent: Saturday, February 16, 2002 8:12 PM > To: FormProc Developer List > Subject: [FormProc-developer] Re: Why FormProc? Was RE: [ANN] > JPublish 0.8 Released > > > 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). After looking over it a bit (at the site) I understand more about how your fields are defined. > > 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 can see the validity in this argument. Strongly typed can be a good thing. > 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. While zip code rules may not change on a regular basis there are other more complicated validation rules which are modified more often. In addition, there are rules which are specific to a particular application but will not be the same on the next app (for example one app may have more stringent password validation rules than another). > > 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 suppose I just have a different opinion. I believe that it is best to maintain mutability for the purpose of being more flexible as systems change. The less I have to compile, the better. Sincerely, Anthony Eden |
From: Brad C. <bc...@vi...> - 2002-02-17 02:34:47
|
At 9:07 PM -0500 2/16/02, Anthony Eden wrote: >I suppose I just have a different opinion. I believe that it is best to >maintain mutability for the purpose of being more flexible as systems >change. The less I have to compile, the better. Yeah, reasonable minds can differ there. I've been on both sides over the years. Objective-C for example, ADDED dynamic typing to C of all things. But as a programmer, I don't object to compiling at all and experience with jakarta projects makes me equate mutablility with flexibility... as when pushing a rope. That's exactly why jwaa deals with entire websites statically. It was driving me nuts keeping all the stray bits straight with jsp and before that, perl. The whole flesibility argument has given me an abiding dislike for configuration "languages" as a solution to mutability/flesibility. There's a whole rant on this in one of the jwaa articles. Compile it with jikes and you get sensible error messages. Botch a configuration file and you get to debug exceptions from code you may not even have source for. -- 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 |
From: Anthony E. <me...@an...> - 2002-02-17 04:01:12
|
> -----Original Message----- > From: Brad Cox [mailto:bc...@vi...] > Sent: Saturday, February 16, 2002 9:33 PM > To: Anthony Eden; FormProc Developer List > Subject: RE: [FormProc-developer] Re: Why FormProc? Was RE: > [ANN] JPublish 0.8 Released > <snip> > > That's exactly why jwaa deals with entire websites statically. It was > driving me nuts keeping all the stray bits straight with jsp and > before that, perl. How do you deal with many developers working on the same site? Do you have a centralized compile system or does everyone have to compile everything locally first? Or both? > The whole flesibility argument has given me an abiding dislike for > configuration "languages" as a solution to mutability/flesibility. > There's a whole rant on this in one of the jwaa articles. Compile it > with jikes and you get sensible error messages. Botch a configuration > file and you get to debug exceptions from code you may not even have > source for. That's why I love open source. ;-) Another thing to consider: a good development cycle includes testing. Thus, your testing should locate problems before going into production and you should be testing whether or not you compile, right? So is the compiling still a necessary step? Sincerely, Anthony Eden |
From: Brad C. <bc...@vi...> - 2002-02-17 14:40:49
|
At 10:58 PM -0500 2/16/02, Anthony Eden wrote: >> That's exactly why jwaa deals with entire websites statically. It was >> driving me nuts keeping all the stray bits straight with jsp and >> before that, perl. > >How do you deal with many developers working on the same site? Do you >have a centralized compile system or does everyone have to compile >everything locally first? Or both? I use perforce, a commercial alternative to CVS. Each developer (just me currently) checks out a copy of the source, updates it each morning, and checks it back in each evening. Compiling the source (with jikes this is instantaneous) builds jars in that developers WEB-INF/lib or copies in unchanging jars (third party stuff, etc). Each developer runs an independent servlet instance during unit testing and shifts to a single one for integration testing. Working with compiled jars has EXACTLY the same issues as configuration files for multiperson development. >> The whole flesibility argument has given me an abiding dislike for >> configuration "languages" as a solution to mutability/flesibility. >> There's a whole rant on this in one of the jwaa articles. Compile it >> with jikes and you get sensible error messages. Botch a configuration >> file and you get to debug exceptions from code you may not even have >> source for. > >That's why I love open source. ;-) Another thing to consider: a good >development cycle includes testing. Thus, your testing should locate >problems before going into production and you should be testing whether >or not you compile, right? So is the compiling still a necessary step? Debugging other people's code is not my idea of fun, open source notwithstanding. Compilers check static correctness, testing checks dynamic (behavioral) correctness. You need both. -- 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 |
From: Anthony E. <me...@an...> - 2002-02-17 16:03:31
|
<snip> > >That's why I love open source. ;-) Another thing to > consider: a good > >development cycle includes testing. Thus, your testing > should locate > >problems before going into production and you should be > testing whether > >or not you compile, right? So is the compiling still a > necessary step? > > Debugging other people's code is not my idea of fun, open source > notwithstanding. Really...I find it to be just a barrel of laughs. ;-) > > Compilers check static correctness, testing checks dynamic > (behavioral) correctness. You need both. If you can prove behavioral correctness aren't you proving static correctness at the same time? I mean, in the end it has to be statically correct to work, right? Sincerely, Anthony Eden |
From: Brad C. <bc...@vi...> - 2002-02-17 16:47:18
|
At 11:00 AM -0500 2/17/02, Anthony Eden wrote: >> Compilers check static correctness, testing checks dynamic >> (behavioral) correctness. You need both. > >If you can prove behavioral correctness aren't you proving static >correctness at the same time? I mean, in the end it has to be >statically correct to work, right? You can't "prove" behavioral correctness. Wasn't it Dijkstra (or perhaps Hoare) who said you can prove the presence of bugs but not their absence? Static correctness can be proved insofar as type correctness goes by compilers. On the other hand, see my IEEE rebuttal, Planning the Software Industrial Revolution. Its at http://virtualschool.edu/cox under publications I think. -- 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 |