Menu
▾
▴
formproc-developer — Developer interests
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(37) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(37) |
Feb
(18) |
Mar
(33) |
Apr
(8) |
May
(7) |
Jun
(13) |
Jul
(20) |
Aug
|
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(2) |
| 2003 |
Jan
|
Feb
(7) |
Mar
(3) |
Apr
(15) |
May
(7) |
Jun
(6) |
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
|
Nov
(5) |
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
|
From: Brad C. <bc...@vi...> - 2002-02-18 13:10:26
|
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
|
|
From: Anthony E. <me...@an...> - 2002-02-18 12:41:50
|
> -----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 |
|
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 |
|
From: Brad C. <bc...@vi...> - 2002-02-17 16:47:15
|
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
|
|
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: Anthony E. <me...@an...> - 2002-02-17 16:00:44
|
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 > > |
|
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 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 02:53:05
|
At 9:15 PM -0500 2/16/02, Anthony Eden wrote:
>> 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.
Except that if you get the order wrong, you get an compile time error
with the first, a debugging exercise with the latter.
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.
--
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: 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 02:18:05
|
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 |
|
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 01:30:43
|
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. 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, ... -- 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: 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: 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: 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: Anthony E. <ae...@si...> - 2002-01-28 22:01:26
|
Greetings all, I would like to start thinking about what it will take to bring FormProc to a 1.0 version. I would like comments from you regarding features which you deem essential for a 1.0 release of FormProc. Also, have you found any bugs (major or minor) which need to be fixed? Please post your comments back to the mailing list and let's get a discussion going about what FormProc needs to go 1.0. -Anthony |
|
From: Dan B. <da...@ch...> - 2002-01-26 21:37:29
|
I was using an old build of tomcat 4.x i built from cvs... i built a new version and everything worked fine... thanks... On Sat, 2002-01-26 at 07:04, Anthony Eden wrote: > Dan, > > Have you tried the formproc-example.war web application that comes with > the FormProc distribution? I just tested it in Tomcat 4.0.1 both with > war unpacking and without and it worked fine. If you got FormProc from > the CVS then your should build it first and then deploy the war. > > What version of Tomcat are you using? Have you modified Tomcat's > configuration? Is Tomcat automatically unpacking the WAR? > > Sincerely, > Anthony Eden > > > -----Original Message----- > > From: for...@li... > > [mailto:for...@li...] On > > Behalf Of Dan Bachelder > > Sent: Saturday, January 26, 2002 4:22 AM > > To: for...@li... > > Subject: [FormProc-developer] formproc > > > > > > I get the following when i try to access index.jsp from > > tomcat... i am also unable to deploy it on resin... not sure > > what to do about it... > > > > 2002-01-26 04:16:33 HostConfig[localhost]: Deploying web > > application archive formproc-example.war 2002-01-26 04:16:33 > > StandardHost[localhost]: Installing web application at > > context path /formproc-example from URL > > jar:file:/home/chowda/dev/tomcat/webapps/formproc-example.war!/ > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: > > Deploying class repositories to work directory > > /home/chowda/dev/tomcat/work/localhost/formproc-example > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > > class files /WEB-INF/classes to > > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > > F/classes > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > > JAR /WEB-INF/lib/EdenLib.jar to > > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > > F/lib/EdenLib.jar > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > > JAR /WEB-INF/lib/FormProc.jar to > > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > > F/lib/FormProc.jar > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > > JAR /WEB-INF/lib/bsf.jar to > > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > > F/lib/bsf.jar > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > > JAR /WEB-INF/lib/jakarta-oro-2.0.2.jar to > > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > > F/lib/jakarta-oro-2.0.2.jar > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > > JAR /WEB-INF/lib/jdom.jar to > > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > > F/lib/jdom.jar > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > > JAR /WEB-INF/lib/jython.jar to > > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > > F/lib/jython.jar > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > > JAR /WEB-INF/lib/log4j-core.jar to > > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > > F/lib/log4j-core.jar > > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > > JAR /WEB-INF/lib/xerces.jar to > > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > > F/lib/xerces.jar > > 2002-01-26 04:16:33 StandardManager[/formproc-example]: > > Seeding random number generator class > > java.security.SecureRandom 2002-01-26 04:16:33 > > StandardManager[/formproc-example]: Seeding of random number > > generator has been completed 2002-01-26 04:16:35 > > StandardWrapper[/formproc-example:default]: Loading container > > servlet default 2002-01-26 04:16:35 default: init 2002-01-26 > > 04:16:35 StandardWrapper[/formproc-example:invoker]: Loading > > container servlet invoker 2002-01-26 04:16:35 invoker: init > > 2002-01-26 04:16:35 jsp: init 2002-01-26 04:16:35 > > StandardContext[/formproc-example]: Servlet /formproc-example > > threw load() exception > > javax.servlet.ServletException: Servlet.init() for servlet > > jsp threw exception > > at > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper. > > java:871) > > at > > org.apache.catalina.core.StandardContext.loadOnStartup(Standar > > dContext.java:3272) > > at > > org.apache.catalina.core.StandardContext.start(StandardContext > > .java:3393) > > at > > org.apache.catalina.core.ContainerBase.addChildInternal(Contai > > nerBase.java:821) > > at > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase. > > java:807) > > at > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:486) > > at > > org.apache.catalina.core.StandardHostDeployer.install(Standard > > HostDeployer.java:278) > > at > > org.apache.catalina.core.StandardHost.install(StandardHost.java:678) > > at > > org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:394) > > at > > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:319) > > at > > org.apache.catalina.startup.HostConfig.run(HostConfig.java:688) > > at java.lang.Thread.run(Thread.java:484) > > ----- Root Cause ----- > > java.lang.ClassCastException: > > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl > > at > > javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentB > > uilderFactory.java:139) > > at > > org.apache.jasper.parser.ParserUtils.parseXMLDocument(ParserUt > > ils.java:183) > > at > > org.apache.jasper.compiler.TldLocationsCache.processWebDotXml( > > TldLocationsCache.java:165) > > at > > org.apache.jasper.compiler.TldLocationsCache.<init>(TldLocatio > > nsCache.java:138) > > at > > org.apache.jasper.EmbededServletOptions.<init>(EmbededServletO > > ptions.java:345) > > at > > org.apache.jasper.servlet.JspServlet.init(JspServlet.java:266) > > at > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper. > > java:852) > > at > > org.apache.catalina.core.StandardContext.loadOnStartup(Standar > > dContext.java:3272) > > at > > org.apache.catalina.core.StandardContext.start(StandardContext > > .java:3393) > > at > > org.apache.catalina.core.ContainerBase.addChildInternal(Contai > > nerBase.java:821) > > at > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase. > > java:807) > > at > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:486) > > at > > org.apache.catalina.core.StandardHostDeployer.install(Standard > > HostDeployer.java:278) > > at > > org.apache.catalina.core.StandardHost.install(StandardHost.java:678) > > at > > org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:394) > > at > > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:319) > > at > > org.apache.catalina.startup.HostConfig.run(HostConfig.java:688) > > at java.lang.Thread.run(Thread.java:484) > > > > > > > > _______________________________________________ > > FormProc-developer mailing list > > For...@li... > > https://lists.sourceforge.net/lists/listinfo/formproc-developer > > > > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer > |
|
From: Anthony E. <me...@an...> - 2002-01-26 12:13:37
|
That's a small typo. I have fixed it in the CVS and it will be in the next release. Thanks, Anthony Eden > -----Original Message----- > From: for...@li... > [mailto:for...@li...] On > Behalf Of Dan Bachelder > Sent: Saturday, January 26, 2002 4:29 AM > To: for...@li... > Subject: [FormProc-developer] index.jsp > > > i got the project from cvs.... i'm not much of a jsp guy... > but it looks like line 15 is extraneous... all the useBean > tags above it seem to have a trailing '/'.... > > still doesnt deploy though... > > > > > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer > |
|
From: Anthony E. <me...@an...> - 2002-01-26 12:07:30
|
Dan, Have you tried the formproc-example.war web application that comes with the FormProc distribution? I just tested it in Tomcat 4.0.1 both with war unpacking and without and it worked fine. If you got FormProc from the CVS then your should build it first and then deploy the war. What version of Tomcat are you using? Have you modified Tomcat's configuration? Is Tomcat automatically unpacking the WAR? Sincerely, Anthony Eden > -----Original Message----- > From: for...@li... > [mailto:for...@li...] On > Behalf Of Dan Bachelder > Sent: Saturday, January 26, 2002 4:22 AM > To: for...@li... > Subject: [FormProc-developer] formproc > > > I get the following when i try to access index.jsp from > tomcat... i am also unable to deploy it on resin... not sure > what to do about it... > > 2002-01-26 04:16:33 HostConfig[localhost]: Deploying web > application archive formproc-example.war 2002-01-26 04:16:33 > StandardHost[localhost]: Installing web application at > context path /formproc-example from URL > jar:file:/home/chowda/dev/tomcat/webapps/formproc-example.war!/ > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: > Deploying class repositories to work directory > /home/chowda/dev/tomcat/work/localhost/formproc-example > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > class files /WEB-INF/classes to > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > F/classes > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > JAR /WEB-INF/lib/EdenLib.jar to > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > F/lib/EdenLib.jar > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > JAR /WEB-INF/lib/FormProc.jar to > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > F/lib/FormProc.jar > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > JAR /WEB-INF/lib/bsf.jar to > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > F/lib/bsf.jar > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > JAR /WEB-INF/lib/jakarta-oro-2.0.2.jar to > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > F/lib/jakarta-oro-2.0.2.jar > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > JAR /WEB-INF/lib/jdom.jar to > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > F/lib/jdom.jar > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > JAR /WEB-INF/lib/jython.jar to > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > F/lib/jython.jar > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > JAR /WEB-INF/lib/log4j-core.jar to > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > F/lib/log4j-core.jar > 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy > JAR /WEB-INF/lib/xerces.jar to > /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-IN > F/lib/xerces.jar > 2002-01-26 04:16:33 StandardManager[/formproc-example]: > Seeding random number generator class > java.security.SecureRandom 2002-01-26 04:16:33 > StandardManager[/formproc-example]: Seeding of random number > generator has been completed 2002-01-26 04:16:35 > StandardWrapper[/formproc-example:default]: Loading container > servlet default 2002-01-26 04:16:35 default: init 2002-01-26 > 04:16:35 StandardWrapper[/formproc-example:invoker]: Loading > container servlet invoker 2002-01-26 04:16:35 invoker: init > 2002-01-26 04:16:35 jsp: init 2002-01-26 04:16:35 > StandardContext[/formproc-example]: Servlet /formproc-example > threw load() exception > javax.servlet.ServletException: Servlet.init() for servlet > jsp threw exception > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper. > java:871) > at > org.apache.catalina.core.StandardContext.loadOnStartup(Standar > dContext.java:3272) > at > org.apache.catalina.core.StandardContext.start(StandardContext > .java:3393) > at > org.apache.catalina.core.ContainerBase.addChildInternal(Contai > nerBase.java:821) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase. > java:807) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:486) > at > org.apache.catalina.core.StandardHostDeployer.install(Standard > HostDeployer.java:278) > at > org.apache.catalina.core.StandardHost.install(StandardHost.java:678) > at > org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:394) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:319) > at > org.apache.catalina.startup.HostConfig.run(HostConfig.java:688) > at java.lang.Thread.run(Thread.java:484) > ----- Root Cause ----- > java.lang.ClassCastException: > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl > at > javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentB > uilderFactory.java:139) > at > org.apache.jasper.parser.ParserUtils.parseXMLDocument(ParserUt > ils.java:183) > at > org.apache.jasper.compiler.TldLocationsCache.processWebDotXml( > TldLocationsCache.java:165) > at > org.apache.jasper.compiler.TldLocationsCache.<init>(TldLocatio > nsCache.java:138) > at > org.apache.jasper.EmbededServletOptions.<init>(EmbededServletO > ptions.java:345) > at > org.apache.jasper.servlet.JspServlet.init(JspServlet.java:266) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper. > java:852) > at > org.apache.catalina.core.StandardContext.loadOnStartup(Standar > dContext.java:3272) > at > org.apache.catalina.core.StandardContext.start(StandardContext > .java:3393) > at > org.apache.catalina.core.ContainerBase.addChildInternal(Contai > nerBase.java:821) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase. > java:807) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:486) > at > org.apache.catalina.core.StandardHostDeployer.install(Standard > HostDeployer.java:278) > at > org.apache.catalina.core.StandardHost.install(StandardHost.java:678) > at > org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:394) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:319) > at > org.apache.catalina.startup.HostConfig.run(HostConfig.java:688) > at java.lang.Thread.run(Thread.java:484) > > > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer > |
|
From: Dan B. <da...@ch...> - 2002-01-26 09:33:55
|
i got the project from cvs.... i'm not much of a jsp guy... but it looks like line 15 is extraneous... all the useBean tags above it seem to have a trailing '/'.... still doesnt deploy though... |
|
From: Dan B. <da...@ch...> - 2002-01-26 09:27:06
|
I get the following when i try to access index.jsp from tomcat... i am also unable to deploy it on resin... not sure what to do about it... 2002-01-26 04:16:33 HostConfig[localhost]: Deploying web application archive formproc-example.war 2002-01-26 04:16:33 StandardHost[localhost]: Installing web application at context path /formproc-example from URL jar:file:/home/chowda/dev/tomcat/webapps/formproc-example.war!/ 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploying class repositories to work directory /home/chowda/dev/tomcat/work/localhost/formproc-example 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy class files /WEB-INF/classes to /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-INF/classes 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy JAR /WEB-INF/lib/EdenLib.jar to /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-INF/lib/EdenLib.jar 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy JAR /WEB-INF/lib/FormProc.jar to /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-INF/lib/FormProc.jar 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy JAR /WEB-INF/lib/bsf.jar to /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-INF/lib/bsf.jar 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy JAR /WEB-INF/lib/jakarta-oro-2.0.2.jar to /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-INF/lib/jakarta-oro-2.0.2.jar 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy JAR /WEB-INF/lib/jdom.jar to /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-INF/lib/jdom.jar 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy JAR /WEB-INF/lib/jython.jar to /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-INF/lib/jython.jar 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy JAR /WEB-INF/lib/log4j-core.jar to /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-INF/lib/log4j-core.jar 2002-01-26 04:16:33 WebappLoader[/formproc-example]: Deploy JAR /WEB-INF/lib/xerces.jar to /home/chowda/dev/tomcat/bin/../webapps/formproc-example/WEB-INF/lib/xerces.jar 2002-01-26 04:16:33 StandardManager[/formproc-example]: Seeding random number generator class java.security.SecureRandom 2002-01-26 04:16:33 StandardManager[/formproc-example]: Seeding of random number generator has been completed 2002-01-26 04:16:35 StandardWrapper[/formproc-example:default]: Loading container servlet default 2002-01-26 04:16:35 default: init 2002-01-26 04:16:35 StandardWrapper[/formproc-example:invoker]: Loading container servlet invoker 2002-01-26 04:16:35 invoker: init 2002-01-26 04:16:35 jsp: init 2002-01-26 04:16:35 StandardContext[/formproc-example]: Servlet /formproc-example threw load() exception javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:871) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3272) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3393) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:486) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:278) at org.apache.catalina.core.StandardHost.install(StandardHost.java:678) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:394) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:319) at org.apache.catalina.startup.HostConfig.run(HostConfig.java:688) at java.lang.Thread.run(Thread.java:484) ----- Root Cause ----- java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:139) at org.apache.jasper.parser.ParserUtils.parseXMLDocument(ParserUtils.java:183) at org.apache.jasper.compiler.TldLocationsCache.processWebDotXml(TldLocationsCache.java:165) at org.apache.jasper.compiler.TldLocationsCache.<init>(TldLocationsCache.java:138) at org.apache.jasper.EmbededServletOptions.<init>(EmbededServletOptions.java:345) at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:266) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:852) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3272) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3393) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:486) at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:278) at org.apache.catalina.core.StandardHost.install(StandardHost.java:678) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:394) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:319) at org.apache.catalina.startup.HostConfig.run(HostConfig.java:688) at java.lang.Thread.run(Thread.java:484) |
|
From: Anthony E. <me...@an...> - 2002-01-25 18:29:47
|
FormProc version 0.7 is now available at http://formproc.sf.net/ FormProc is an open source Java library designed to make handling and validating forms easy. Forms are represented as objects which manage a collection of form elements. Submitted data can be validated through several mechanisms including regular expressions, BSF supported scripting languages and custom Java classes. Added shared validators. Validators can now have locale sensitive error messages. Removed FormElement level error messages in favor of validator error messages. FormValidator is now an abstract base class. Removed AbstractFormValidator. All FormValidator implementations now extend from FormValidator. FormValidator.configure() method now final; implementations should override configureInternal() to do implementation-specific configuration. FormValidator instances can now be aquired from a single location: FormManager.getValidator(). Updated examples to demonstrate how shared validators work. Sincerely, Anthony Eden |
|
From: Anthony E. <me...@an...> - 2002-01-24 16:13:50
|
> >> > >> Also, Anthony, the object population portion has taken root in your > >> design. Is that a good thing? Maybe it is, but it makes me think. > > > > I wouldn't say that it has taken root, rather it is the most common way > > that people think about forms (AFAICT). Even if FormProc was not > > designed to populate objects I would still maintain the one-to-one > > relationship between form widgets and FormElements in FormProc. > > I was being too obtuse by the phrase "taken root", my fault. > Specifically, > and not to belabor the point, I was implying "the subsystem of object > population is influencing the (potentially unrelated) data validation > subsystem". And there's nothing wrong with that, it's just something to > consider. :-) Duly noted. If it ever becomes a problem (for you or other FormProc users) then we can re-address it then. -Anthony |
|
From: Nick B. <ni...@co...> - 2002-01-24 15:59:06
|
Anthony Wrote: > Comments inline. > >> -----Original Message----- >> From: for...@li... >> [mailto:for...@li...] On >> Behalf Of Nick Bauman >> Sent: Wednesday, January 23, 2002 11:37 AM >> To: for...@li... >> Subject: [FormProc-developer] Object Population and >> Validation (was: Validation by type) >> >> >> I understand. That's great, I think it's a good idea. I was making an >> assumption that these are 2 different goals that s/b >> decoupled. It is, >> however, not wrong to couple them. > > Good, glad we agree. :-) > >> >> Thinking aloud: >> >> For myself, and maybe I need some religion on this one, but I >> personally >> don't like frameworks that make me change my objects to fit >> them better, >> or have to make discriptors of my objects that are external >> to them which >> make it possible for a framework to use them. > > The good news is that you don't have to change your objects to work > with FormProc. The data population is not required. You do not have > to specify write methods and if a setXXX() method is not found then > that field will be skipped (validation will still occur though). Perfect. >> For me to >> accept this, I'm >> going to take a long hard look before leaping. This is why I >> like the idea >> of decoupling the data validation from the object population. >> Maybe I want >> to plug in my own object population strategy? > > Being able to plug in an object population strategy is not a bad idea. > If you ever find that you do need to do this then let me know and I > will work on making the population part of FormProc pluggable. One > thing to note is that FormProc attempts to follow the JavaBeans > standards when populating objects since it is the accepted standard for > working with unknown components at runtime. Sure, JavaBeans is what I assumed. Principle of Least Astonishment. >> For this a peer >> interface is >> all that's needed. (If you've guessed that I dislike CORBA >> for this reason >> you're partially right, but only in particular when everyone >> is speaking >> Java, but that's another argument) >> >> Also, Anthony, the object population portion has taken root in your >> design. Is that a good thing? Maybe it is, but it makes me think. > > I wouldn't say that it has taken root, rather it is the most common way > that people think about forms (AFAICT). Even if FormProc was not > designed to populate objects I would still maintain the one-to-one > relationship between form widgets and FormElements in FormProc. I was being too obtuse by the phrase "taken root", my fault. Specifically, and not to belabor the point, I was implying "the subsystem of object population is influencing the (potentially unrelated) data validation subsystem". And there's nothing wrong with that, it's just something to consider. :-) > -Anthony > -- Nick Bauman - A Fella That Thinks FormProc is awesome |
2 messages has been excluded from this view by a project administrator.
