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: Anthony E. <me...@an...> - 2001-11-20 04:34:31
|
Right now there is a single error message for each field because there is a single validator. I can see the value in allowing error messages for each validator though. As far as multiple validators I have checked in a class to CVS called FormValidatorGroup. I have not yet added the configuration routines, but it is essentially a collection of FormValidators which must all be valid for a successful validation. The FormValidatorGroup extends from AbstractFormValidator so it can be used in the same place as any other FormValidator. I will add the configuration logic tomorrow. Sincerely, Anthony Eden > -----Original Message----- > From: for...@li... > [mailto:for...@li...]On Behalf Of Nick > Bauman > Sent: Monday, November 19, 2001 3:32 PM > To: for...@li... > Subject: Re: [FormProc-developer] Integradata and FormProc working > together > > > > This is a suggestion for future development. I think it would be a > > 'nice-to-have' feature. > > > > I was looking at Nick Bauman's API and noticed that his RuleResult > > class holds the error message while FormProc's getMessage method is in > > the FormElement. > > Correct, and I know this is a problem with Integradata. However, > my thinking > is this: > > I like that Anthony has I18N error messages "built right in", which > Integradata doesn't have (right now). He does this by putting the error > message in the XML. But since the Rule knows why, how and when > it's field is > invalid, the Rule should return a specific result code, which > then is mapped > to subsequent I18N responses, either in a properties file in the distro or > in the XML. The point is, you shouldn't be forced to put the error message > in there if you don't want to. > > Also, Integradata will soon optionally autogenerate Javascript validation > functions for validation _on the front end_ too, which I hope > Anthony's lib > will be able to adopt as well! > > This is where Integradata is going. If we can go there together, we can > leverage the strengths of choice, cohesiveness of each other's parts and > scale the maintainability appropriately: a win-win for both FormProc and > Integradata. > > > It looks to me like this design prevents FormProc from being able to > > implement multiple rules. > > If this is true, this is definitely a problem. Integradata does not have > this limitation. Your illustration of a valid case for having > multiple rules > per field is right on the money. > > > For example, I think it would be useful to be able to configure a field > > like this: > > > > <element name="postalcode"> > > > > <!-- Rule for making the field required --> > > <validator type="rule"> > > <rule>org.formproc.example.RequiredRule</rule> > > <error lang="en">This field is required</error> > > </validator> > > > > <!-- Rule for validating a Canadian Postal Code --> > > <validator type="rule"> > > <rule>org.formproc.example.CanPostalCodeRule</rule> > > <error lang="en">This is not a valid Canadian Postal Code</error> > > </validator> > > > > <message lang="en">Please enter a valid postal code</message> > > > > </element> > > > > > > The first rule would be evaluated, and if the field is blank then the > > user would be given the "This field is required" message. If the field > > is entered, but the postal code is invalid, then the second rule is > > evaluated and he/she would be presented with the invalid postal code > > message. > > > > It also seems logical to me that the error message would be a property > > of the validator for a particular field. > > > > This change might make porting/merging Nick's rules easier as well. > > Yup, agreed. > > > > > Regards, > > -Kerry > > > > -- > > Kerry Todyruik <ke...@to...> > > > > _______________________________________________ > > FormProc-developer mailing list > > For...@li... > > https://lists.sourceforge.net/lists/listinfo/formproc-developer > > > -- > Nick Bauman > Cortexity Development > Intellectual Process is more important than > Intellectual Property -- you'll see. > http://www.cortexity.com/ > > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer > > |
From: Anthony E. <me...@an...> - 2001-11-20 04:32:06
|
There is no method at this time to enumerate through the element names. Would you expect the list to be in the same order as defined in the configuration or in some other order? Or does it not matter what order they are in? I suppose that the list should also be passed through the Collections.unmodifiableList() method first. I wonder: should it be possible to configure forms programtically? Should you be able to add new FormElement objects to FormConfiguration? What other areas should be programitically accessible which are not? Sincerely, Anthony Eden > -----Original Message----- > From: for...@li... > [mailto:for...@li...]On Behalf Of > Kerry Todyruik > Sent: Monday, November 19, 2001 7:35 PM > To: for...@li... > Subject: [FormProc-developer] Getting an iteration of the form element > names > > > I am using the Apache Velocity template engine. To reduce the code in > my template, I would like to retrieve a list of the names of the form > elements. It doesn't look like there is a method to retrieve this yet. > How should I go about this? > > It looks like I could get a FormConfiguration object for the form from > the FormManager. Then if there was an accessor method in the > FormConfiguration that would make the private formElements Map > available, I could use that. > > Alternatively, I could write a getFieldNames method that processes the > formElements Map, putting the names in a list and returning that list or > iterator. > > If I could get some feedback on what would be an acceptible addition, I > will code the method and then post it to the mailing list. > > Regards, > -Kerry > > -- > Kerry Todyruik <ke...@to...> > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer > > |
From: Anthony E. <me...@an...> - 2001-11-20 04:23:19
|
Fixed in CVS. -Anthony > -----Original Message----- > From: for...@li... > [mailto:for...@li...]On Behalf Of > Kerry Todyruik > Sent: Monday, November 19, 2001 6:42 PM > To: for...@li... > Subject: [FormProc-developer] FormElement.java Bug > > > All of the error messages have been returning null. I found this bug in > FormElement.java > > Line 194: > > Iterator errorMessageElements = element.getChildren("error", > NS).iterator(); > while(messageElements.hasNext()){ > Element errorMessageElement = (Element)errorMessageElements.next(); > String lang = errorMessageElement.getAttributeValue("lang"); > errorMessages.put(lang, errorMessageElement.getTextTrim()); > } > > Should be: > > Iterator errorMessageElements = element.getChildren("error", > NS).iterator(); > while(errorMessageElements.hasNext()){ > Element errorMessageElement = (Element)errorMessageElements.next(); > String lang = errorMessageElement.getAttributeValue("lang"); > errorMessages.put(lang, errorMessageElement.getTextTrim()); > } > > -- > Kerry Todyruik <ke...@to...> > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer > > |
From: Anthony E. <me...@an...> - 2001-11-20 04:21:55
|
Thanks, Kerry. I have commited it to CVS and have added you as a contributor. Are you interested in becoming a full-fledge developer with CVS write access? Sincerely, Anthony Eden > -----Original Message----- > From: for...@li... > [mailto:for...@li...]On Behalf Of > Kerry Todyruik > Sent: Monday, November 19, 2001 3:00 PM > To: for...@li... > Subject: [FormProc-developer] build.sh > > > Hi. Appologies for forgetting the subject line in my last post... :-) > > Could somebody add build.sh for the Linux/Unix people to the FormProc > source tree? Here is one I used yesterday to compile FormProc. Use > this if you like: > > > > #! /bin/sh > > if [ -z "$JAVA_HOME" ] ; then > JAVA=`which java` > if [ -z "$JAVA" ] ; then > echo "Cannot find JAVA. Please set your PATH." > exit 1 > fi > JAVA_BIN=`dirname $JAVA` > JAVA_HOME=$JAVA_BIN/.. > fi > > JAVA=$JAVA_HOME/bin/java > > CLASSPATH=`echo lib/*.jar | tr ' ' ':'` > CLASSPATH=build-lib/ant.jar:build/classes/:$CLASSPATH:$JAVA_HOME/l > ib/tools.jar > > $JAVA -classpath $CLASSPATH -Dant.home=lib org.apache.tools.ant.Main > "$@" -buildfile build.xml > > > > -- > Kerry Todyruik <ke...@to...> > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer > > |
From: Anthony E. <me...@an...> - 2001-11-20 04:16:59
|
> Other projects that employ XML configuration files (Castor, Tomcat, > Poolman, etc.) use concise, simple tag names. Wouldn't it be more > straightforward to read and maintain if 'formproc:' was removed from > the tags in the formproc.xml and example-form.xml files? I agree and thus have removed all name spaces from the XML configuration files. I probably should have made them optional, but since FormProc is in alpha state I suppose now is a good time to make these kinds of changes. Sincerely, Anthony Eden |
From: Anthony E. <me...@an...> - 2001-11-20 02:01:56
|
> Anthony, > > I've written a bunch of rules, but they are for my own framework. > My desire > is to see if we can write some kind of bridge that will allow my > rules to be > plugged into your framework without me having to develop in the FormProc > tree. Can we agree this is a worthy goal? If not, you could always cut and > paste, and I would be fine with that, but that means we miss out on long > term cohesiveness and maintainability. As long as your rules implement the org.formproc.validation.Rule interface then you should be able to use them in FormProc. You could also create a wrapper Rule which just executes your rules through some interface you design. Two things make this possible: 1.) Rule implementations are specified in the XML file and 2.) you can pass any XML configuration data to you rule through the configure(Element element) method of the Rule interface. If this is not sufficient then tell me what you have in mind. Sincerely, Anthony Eden |
From: Anthony E. <me...@an...> - 2001-11-20 01:51:50
|
> Hello. > > I've been trying out FormProc the last couple of days. Overall, I think > it is an excellent tool. Very nice work! I would like to share some of > my impressions being a first time user. I also have a few questions. Thanks. I always look forward to comments and questions from others. > > My first question is how do you set up a field with no validator? When > I configure a field like: > > <formproc:element name="address" /> > > or even > > <formproc:element name="address"> > <formproc:write-method>setAddress</formproc:write-method> > </formproc:element> > > It throws a ResourceException. Correct me if I'm wrong, but this field > configuration seems valid. if not, an exception with some description > of the problem would be helpful. Like "ResourceException: Missing > required --- tag" for example. I have modified the source in the CVS to allow both forms of the element method as described above. > > Secondly, I received this error that seems due to the fact that I had > fields in my form that were not included in the configuration file: > > [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - Starting > FileMonitor > [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - FileMonitor > running. > [DEBUG]:org.formproc.FormManager - Formproc configuration loaded > [DEBUG]:org.formproc.servlet.HttpForm - Processing servlet request. > [DEBUG]:org.formproc.Form - Validating field action > [DEBUG]:org.formproc.Form - getName: action > [DEBUG]:org.formproc.Form - Found form element. > java.lang.NullPointerException > at org.formproc.Form.validate(Form.java:300) > at org.formproc.Form.process(Form.java:266) > at org.formproc.servlet.HttpForm.process(HttpForm.java:38) > at EntryForm.handle(EntryForm.java:49) > > Wouldn't it be better to gracefully ignore fields in the form that are > not included in the xml configuration file? Or at least throw a > meaningfull exception with some description of the problem with the > config file? I have modified the source code in the CVS so that fields which are not in the XML configuration are ignored. I have created a new class PassFormValidator which implements this functionality. I have not tested these modifications yet, but I have modified the example app to simulate this new behavior - I just need to run it. Sincerely, Anthony Eden |
From: Kerry T. <ke...@to...> - 2001-11-19 23:34:23
|
I am using the Apache Velocity template engine. To reduce the code in my template, I would like to retrieve a list of the names of the form elements. It doesn't look like there is a method to retrieve this yet. How should I go about this? It looks like I could get a FormConfiguration object for the form from the FormManager. Then if there was an accessor method in the FormConfiguration that would make the private formElements Map available, I could use that. Alternatively, I could write a getFieldNames method that processes the formElements Map, putting the names in a list and returning that list or iterator. If I could get some feedback on what would be an acceptible addition, I will code the method and then post it to the mailing list. Regards, -Kerry -- Kerry Todyruik <ke...@to...> |
From: Kerry T. <ke...@to...> - 2001-11-19 22:42:11
|
All of the error messages have been returning null. I found this bug in FormElement.java Line 194: Iterator errorMessageElements = element.getChildren("error", NS).iterator(); while(messageElements.hasNext()){ Element errorMessageElement = (Element)errorMessageElements.next(); String lang = errorMessageElement.getAttributeValue("lang"); errorMessages.put(lang, errorMessageElement.getTextTrim()); } Should be: Iterator errorMessageElements = element.getChildren("error", NS).iterator(); while(errorMessageElements.hasNext()){ Element errorMessageElement = (Element)errorMessageElements.next(); String lang = errorMessageElement.getAttributeValue("lang"); errorMessages.put(lang, errorMessageElement.getTextTrim()); } -- Kerry Todyruik <ke...@to...> |
From: Nick B. <ni...@co...> - 2001-11-19 20:27:42
|
> This is a suggestion for future development. I think it would be a > 'nice-to-have' feature. > > I was looking at Nick Bauman's API and noticed that his RuleResult > class holds the error message while FormProc's getMessage method is in > the FormElement. Correct, and I know this is a problem with Integradata. However, my thinking is this: I like that Anthony has I18N error messages "built right in", which Integradata doesn't have (right now). He does this by putting the error message in the XML. But since the Rule knows why, how and when it's field is invalid, the Rule should return a specific result code, which then is mapped to subsequent I18N responses, either in a properties file in the distro or in the XML. The point is, you shouldn't be forced to put the error message in there if you don't want to. Also, Integradata will soon optionally autogenerate Javascript validation functions for validation _on the front end_ too, which I hope Anthony's lib will be able to adopt as well! This is where Integradata is going. If we can go there together, we can leverage the strengths of choice, cohesiveness of each other's parts and scale the maintainability appropriately: a win-win for both FormProc and Integradata. > It looks to me like this design prevents FormProc from being able to > implement multiple rules. If this is true, this is definitely a problem. Integradata does not have this limitation. Your illustration of a valid case for having multiple rules per field is right on the money. > For example, I think it would be useful to be able to configure a field > like this: > > <element name="postalcode"> > > <!-- Rule for making the field required --> > <validator type="rule"> > <rule>org.formproc.example.RequiredRule</rule> > <error lang="en">This field is required</error> > </validator> > > <!-- Rule for validating a Canadian Postal Code --> > <validator type="rule"> > <rule>org.formproc.example.CanPostalCodeRule</rule> > <error lang="en">This is not a valid Canadian Postal Code</error> > </validator> > > <message lang="en">Please enter a valid postal code</message> > > </element> > > > The first rule would be evaluated, and if the field is blank then the > user would be given the "This field is required" message. If the field > is entered, but the postal code is invalid, then the second rule is > evaluated and he/she would be presented with the invalid postal code > message. > > It also seems logical to me that the error message would be a property > of the validator for a particular field. > > This change might make porting/merging Nick's rules easier as well. Yup, agreed. > > Regards, > -Kerry > > -- > Kerry Todyruik <ke...@to...> > > _______________________________________________ > FormProc-developer mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formproc-developer -- Nick Bauman Cortexity Development Intellectual Process is more important than Intellectual Property -- you'll see. http://www.cortexity.com/ |
From: Kerry T. <ke...@to...> - 2001-11-19 18:59:51
|
Hi. Appologies for forgetting the subject line in my last post... :-) Could somebody add build.sh for the Linux/Unix people to the FormProc source tree? Here is one I used yesterday to compile FormProc. Use this if you like: #! /bin/sh if [ -z "$JAVA_HOME" ] ; then JAVA=`which java` if [ -z "$JAVA" ] ; then echo "Cannot find JAVA. Please set your PATH." exit 1 fi JAVA_BIN=`dirname $JAVA` JAVA_HOME=$JAVA_BIN/.. fi JAVA=$JAVA_HOME/bin/java CLASSPATH=`echo lib/*.jar | tr ' ' ':'` CLASSPATH=build-lib/ant.jar:build/classes/:$CLASSPATH:$JAVA_HOME/lib/tools.jar $JAVA -classpath $CLASSPATH -Dant.home=lib org.apache.tools.ant.Main "$@" -buildfile build.xml -- Kerry Todyruik <ke...@to...> |
From: Kerry T. <ke...@to...> - 2001-11-19 18:47:43
|
This is a suggestion for future development. I think it would be a 'nice-to-have' feature. I was looking at Nick Bauman's API and noticed that his RuleResult class holds the error message while FormProc's getMessage method is in the FormElement. It looks to me like this design prevents FormProc from being able to implement multiple rules. For example, I think it would be useful to be able to configure a field like this: <element name="postalcode"> <!-- Rule for making the field required --> <validator type="rule"> <rule>org.formproc.example.RequiredRule</rule> <error lang="en">This field is required</error> </validator> <!-- Rule for validating a Canadian Postal Code --> <validator type="rule"> <rule>org.formproc.example.CanPostalCodeRule</rule> <error lang="en">This is not a valid Canadian Postal Code</error> </validator> <message lang="en">Please enter a valid postal code</message> </element> The first rule would be evaluated, and if the field is blank then the user would be given the "This field is required" message. If the field is entered, but the postal code is invalid, then the second rule is evaluated and he/she would be presented with the invalid postal code message. It also seems logical to me that the error message would be a property of the validator for a particular field. This change might make porting/merging Nick's rules easier as well. Regards, -Kerry -- Kerry Todyruik <ke...@to...> |
From: Kerry T. <ke...@to...> - 2001-11-19 18:14:10
|
Other projects that employ XML configuration files (Castor, Tomcat, Poolman, etc.) use concise, simple tag names. Wouldn't it be more straightforward to read and maintain if 'formproc:' was removed from the tags in the formproc.xml and example-form.xml files? For example: ---------- <?xml version="1.0"?> <formproc xmlns:formproc="http://www.formproc.org/"> <validator-map type="script" classname="org.formproc.validation.ScriptFormValidator"> <property name="script-root" value="g:\osscvs\formproc\formproc\example"/> </validator-map> <validator-map type="expression" classname="org.formproc.validation.REFormValidator"/> <validator-map type="rule" classname="org.formproc.validation.RuleFormValidator"/> <form name="exampleform" loader="com.anthonyeden.lib.resource.FileResourceLoader" path="example-form.xml" monitor="true"/> </formproc> ---------- <?xml version="1.0"?> <form xmlns:formproc="http://www.formproc.org/"> <name>example</name> <element name="name"> <validator type="expression"> <pattern>\w{1,}</pattern> </validator> <write-method>setName</write-method> <message lang="en">Required</message> <error lang="en">The name cannot be empty.</error> </element> <element name="username"> <validator type="class" classname="org.formproc.example.UsernameValidator"/> <message lang="en">5 characters or more.</message> </element> <element name="age"> <validator type="rule"> <rule>org.formproc.example.IsIntRule</rule> </validator> <message lang="en">Valid age required.</message> </element> <element name="password"> <validator type="script"> <script>PasswordValidator.py</script> </validator> <message lang="en">Minimum 8 characters.</message> <error lang="en">Passwords must be at least 8 characters.</error> </element> </form> -- Kerry Todyruik <ke...@to...> |
From: Nick B. <ni...@co...> - 2001-11-19 16:18:15
|
Anthony, I've written a bunch of rules, but they are for my own framework. My desire is to see if we can write some kind of bridge that will allow my rules to be plugged into your framework without me having to develop in the FormProc tree. Can we agree this is a worthy goal? If not, you could always cut and paste, and I would be fine with that, but that means we miss out on long term cohesiveness and maintainability. Let me know what you think, meanwhile, take a look at the rules: http://www.cortexity.com/cgi-py/viewcvs.cgi/integradata/src/com/cortexity/integradata/rules/ javadoc: http://www.cortexity.com/nightly/integradata-javadoc/ -- Nick Bauman Cortexity Development Intellectual Process is more important than Intellectual Property -- you'll see. http://www.cortexity.com/ |
From: Kerry T. <ke...@to...> - 2001-11-19 06:14:14
|
Hello. I've been trying out FormProc the last couple of days. Overall, I think it is an excellent tool. Very nice work! I would like to share some of my impressions being a first time user. I also have a few questions. My first question is how do you set up a field with no validator? When I configure a field like: <formproc:element name="address" /> or even <formproc:element name="address"> <formproc:write-method>setAddress</formproc:write-method> </formproc:element> It throws a ResourceException. Correct me if I'm wrong, but this field configuration seems valid. if not, an exception with some description of the problem would be helpful. Like "ResourceException: Missing required --- tag" for example. Secondly, I received this error that seems due to the fact that I had fields in my form that were not included in the configuration file: [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - Starting FileMonitor [DEBUG]:com.anthonyeden.lib.resource.ResourceFileMonitor - FileMonitor running. [DEBUG]:org.formproc.FormManager - Formproc configuration loaded [DEBUG]:org.formproc.servlet.HttpForm - Processing servlet request. [DEBUG]:org.formproc.Form - Validating field action [DEBUG]:org.formproc.Form - getName: action [DEBUG]:org.formproc.Form - Found form element. java.lang.NullPointerException at org.formproc.Form.validate(Form.java:300) at org.formproc.Form.process(Form.java:266) at org.formproc.servlet.HttpForm.process(HttpForm.java:38) at EntryForm.handle(EntryForm.java:49) Wouldn't it be better to gracefully ignore fields in the form that are not included in the xml configuration file? Or at least throw a meaningfull exception with some description of the problem with the config file? Regards, Kerry -- Kerry Todyruik <ke...@to...> |
From: BUDI W. <bu...@li...> - 2001-11-02 07:36:34
|
I have one input text field. The input contain several records with ";" delimited input data. With structure: hiredate;sal;ename;empno Data: 1996-09-01;1250.00;jackson;7123 1980-01-01;2500.50;walsh;7124 1985-01-01;12345.67;gates;7125 I have to validate the input records with several rules: - hiredate as date format (YYYY-MM-DD), can't Null - sal as number, can't Null - ename as character, can't Null - empno as number, can't Null Can we use FormProc as mass data import interface ? Regards. |
From: Nick B. <ni...@co...> - 2001-10-07 02:58:11
|
> >> Okay, here's what I want to give FormProc: >> >> IsEmailRule (that doesn't require Java Mail) >> StringLengthRule (whether a String is in a range of size) >> StringMatchesRule (whether a String contains a POSIX regex) >> IntegerRangeRule (whether a String represents an Integer between x and >> y) DoubleRangeRule (obvious) >> OrRule (whether a String is one of a set domain of values) >> NegateRule (will accept any Rule and return true if false, false if >> true) AndRule (will accept a collection of Rules and process each one >> to pass) IsCreditCardNumRule (will do mod-10 checksum and credit card >> logic to see if >> the field looks like a valid credit card) >> >> Sound good for starters? > > Sounds very good. JPublish already has the Jakarta ORO package > included so feel free to use that for your regular expressions. I am > looking forward to receiving your code. I saw that. Can you give me a 25-word how-to on how to _configure_ a rule? I'll be reading the source, but I'm not sure what to expect. IE I'd like to have IntegerRange rule accept attributes describing the range requested from the config xml file. How should that look? Don't worry about details, just the very high level. I can get the rest from the source. > Have you tried the SourceForge CVS yet? I have added your SourceForge > account to the developer list and I am curious if you have write access > to the repository. > > -Anthony > I would prefer for the time being have you review, approve and commit my changes until we have a more solid working relationship, ie: so that you know what to expect and I know what to expect. Maybe in a few more rounds of contributions from me and then it makes sense for me to have full commit status. Sound good? -Nick |