formproc-developer — Developer interests

RE: [FormProc-developer] Build Errors with Latest CVS Drop

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

Fixed.  I forgot to check in some updated files.  Sorry about that.

-Anthony

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Anthony W. Marino
> Sent: Friday, July 26, 2002 7:07 AM
> To: for...@li...
> Subject: [FormProc-developer] Build Errors with Latest CVS Drop
> 
> 
> Buildfile: build.xml
> 
> init:
> 
> compile:
>      [copy] Copying 71 files to 
> /usr/local/src/formproc/formproc/build/src
>      [copy] Copied 2 empty directories to 
> /usr/local/src/formproc/formproc/build/src
>     [mkdir] Created dir: 
> /usr/local/src/formproc/formproc/build/classes
>      [echo] javac classpath = 
> lib/jakarta-oro-2.0.6.jar:lib/log4j-core.jar:lib/jaxp.jar:lib/
> bsf.jar:lib/EdenLib.jar:build-lib/servlet.jar
>     [javac] Compiling 63 source files to 
> /usr/local/src/formproc/formproc/build/classes
>     [javac] 
> /usr/local/src/formproc/formproc/build/src/org/formproc/config
> /XMLFormConfiguration.java:84: 
> org.formproc.config.XMLFormConfiguration should be declared 
> abstract; it does 
> not define isSkipNullValues() in 
> org.formproc.config.AbstractFormConfiguration
>     [javac] public class XMLFormConfiguration extends 
> AbstractFormConfiguration implements
>     [javac]        ^
>     [javac] 1 error
> 
> BUILD FAILED
> file:/usr/local/src/formproc/formproc/build.xml:68: Compile 
> failed; see the 
> compiler error output for details.
> 
> 
> Thank You,
> Anthony
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> FormProc-developer mailing list 
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> 

[FormProc-developer] Build Errors with Latest CVS Drop

[Anthony W. M. <an...@AW...>]

Buildfile: build.xml

init:

compile:
     [copy] Copying 71 files to /usr/local/src/formproc/formproc/build/sr=
c
     [copy] Copied 2 empty directories to=20
/usr/local/src/formproc/formproc/build/src
    [mkdir] Created dir: /usr/local/src/formproc/formproc/build/classes
     [echo] javac classpath =3D=20
lib/jakarta-oro-2.0.6.jar:lib/log4j-core.jar:lib/jaxp.jar:lib/bsf.jar:lib=
/EdenLib.jar:build-lib/servlet.jar
    [javac] Compiling 63 source files to=20
/usr/local/src/formproc/formproc/build/classes
    [javac]=20
/usr/local/src/formproc/formproc/build/src/org/formproc/config/XMLFormCon=
figuration.java:84:=20
org.formproc.config.XMLFormConfiguration should be declared abstract; it =
does=20
not define isSkipNullValues() in=20
org.formproc.config.AbstractFormConfiguration
    [javac] public class XMLFormConfiguration extends=20
AbstractFormConfiguration implements
    [javac]        ^
    [javac] 1 error

BUILD FAILED
file:/usr/local/src/formproc/formproc/build.xml:68: Compile failed; see t=
he=20
compiler error output for details.


Thank You,
Anthony

RE: [FormProc-developer] Data from session Object

[Nick B. <ni...@co...>]

Nicholas,

I can be such a killjoy at times, can't I? To be clear, I for one am very 
gald you're here and are looking at FormProc and want to encourage you to 
do so. 

Because the world needs you and there is much work to be done!

Thanks again.

-Nick

> Nick
> 
> You're probably completely correct.
> 
> The performance gain probably comes from creating far fewer objects and
> not having to configure each new object, as the overhead of maintaining
> the pool means that for smaller  numbers of invocations non pooled  is 
> faster.
> 
> I created a simple servlet and used both pooled and non pooled
> implementations. As the load increases the pooled implementation shows
> fewer non available errors and probably takes up less memory. I haven't
> really had time to run exhaustive trials.
> 
> I've implemented the pool so that it is basically an add on rather than
> intrinsic to FormProc. The underlying implementation is the
> jakarta-commons pool -so if it's fundamentally sound the credit is all
> theirs. Think of it not as redesigning the bow but as being an extra
> arrow in your quiver ;-) As Anthony said, it's not really core FormProc
> stuff but at least if anyone asks if you've considered pooling there's
> an example of how it could be done ( or of the folly of  trying :-) )
> 
> Regards
> 
> Nick
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> We have stuff for geeks like you.
> http://thinkgeek.com/sf
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer


- /\/

--
Nick Bauman 
Cortexity Development
Minneapolis, MN, 55412 
612-232-7120

RE: [FormProc-developer] Data from session Object

[Nicholas S. <ni...@sa...>]

Nick

You're probably completely correct.

The performance gain probably comes from creating far fewer objects and not
having to configure each new object, as the overhead of maintaining the pool
means that for smaller  numbers of invocations non pooled  is  faster.

I created a simple servlet and used both pooled and non pooled
implementations. As the load increases the pooled implementation shows fewer
non available errors and probably takes up less memory. I haven't really had
time to run exhaustive trials.

I've implemented the pool so that it is basically an add on rather than
intrinsic to FormProc. The underlying implementation is the jakarta-commons
pool -so if it's fundamentally sound the credit is all theirs. Think of it
not as redesigning the bow but as being an extra arrow in your quiver ;-)
As Anthony said, it's not really core FormProc stuff but at least if anyone
asks if you've considered pooling there's an example of how it could be done
( or of the folly of  trying :-) )

Regards

Nick

RE: [FormProc-developer] Data from session Object

[Nick B. <ni...@co...>]

Nicholas,

> I appreciate Nick's point about home grown object pools and I know it
> may well be a fruitless excercise but I was interested in using the
> jakart-commons pool project code so I have written a set of classes to
> enable one to pool HttpForms.
> It seems to work OK and under heavy loads shows a marginal performance
> improvement over a non pooled implementation.
> 

<snip>

Not to be too picky on this point, but adding pooling for a marginal 
performance boost adds unecessary complexity, IMHO. 

I know, I know ...  you're thinking that's what we do, we make 
things "better" by having more going on. But consider this quote: 

"... Any [system] that reaches a certain level of complexity becomes 
essentially immune to wholesale innovation that may be required for it to 
adapt and survive ..." 
                         -- Peter D. Ward, Author of "Rare Earth"

Substitute the word "system" for the word "species" and you have his exact 
words. His point was in regards to how complex species are more fragile to 
change because they are less adaptable, being hindered by their 
morphological complexity. My point by extension being, the more complex a 
system, the shorter its lifespan, or usefulness.

So, my thesis remains that a better system is one that keeps its options 
open by preventing it from becoming "immune to wholesale innovation" by 
unecessary complexity.

Take that as you will. Keep fighting the good fight.

- /\/

(PS: I'm also suprised you are seeing a marginal performance boost, I 
would think you would find it actually a bit slower because you make the 
VM keep track of more objects by pooling, which slows it down too.)

--
Nick Bauman 
Cortexity Development
Minneapolis, MN, 55412 
612-232-7120

RE: [FormProc-developer] Data from session Object

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

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Nicholas Sanderson
> Sent: Sunday, July 07, 2002 11:02 AM
> To: for...@li...
> Subject: RE: [FormProc-developer] Data from session Object

<snip>

> I appreciate Nick's point about home grown object pools and I 
> know it may well be a fruitless excercise but I was 
> interested in using the jakart-commons pool project code so I 
> have written a set of classes to enable one to pool 
> HttpForms. It seems to work OK and under heavy loads shows a 
> marginal performance improvement over a non pooled implementation.
> 
> I'd be happy to submit the code - and to have it ripped to 
> shreds if necessary ;-)
> 
> Where should I send the example to ? Can we add attachments 
> to the email in this mailing list.

You can send the code to me directly and I will go over it and place it
in the CVS server.  I would prefer if you either tarred and gzipped it
or zip it prior to sending it.

Sincerely,
Anthony Eden

RE: [FormProc-developer] Data from session Object

[Nicholas S. <ni...@sa...>]

Hi Anthony

You're absolutely right. Please disregard the nonsense in my last email :-)
It's impossible to add anything but Strings as keys to the session attribute
collection and you already call toString in the
converters - I'd better read the code more carefully.


I appreciate Nick's point about home grown object pools and I know it may
well be a fruitless excercise but I was interested in using the
jakart-commons pool project code so I have written a set of classes to
enable one to pool HttpForms.
It seems to work OK and under heavy loads shows a marginal performance
improvement over a non pooled implementation.

I'd be happy to submit the code - and to have it ripped to shreds if
necessary ;-)

Where should I send the example to ? Can we add attachments to the email in
this mailing list.

Regards

Nick

RE: [FormProc-developer] Data from session Object

[Nick B. <ni...@co...>]

Modern VMs perform better creating new objects for most types than you 
could do pooling them yourself. The only exceptions are objects that are 
spceifically I/O bound.

If you don't belive me, write a contrived test to prove it to yourself. 
I've done it, which was the only proof I needed.

> Hi Anthony
> 
> 
> I checked out the extended HttpForm. That's pretty much the kind of
> thing except where you cast the object
> to String from the session I think it might be safer to use
> 
> Object o = session.getAttribute(key);
> String s = o.toString();
> 
> in order to avoid class cast problems if different classes(to String)
> were stored in the session.
> 
> Of course initially this approach will still limit one to strings and
> numbers. More exciting objects would require the toString method
> overriden to return a serialised form of data that could be
> reconstructed in a converter object.
> 
> The HttpForm pooling mechanism should probably be put in an extended
> FormManager maybe PooledFormManager which could be a singleton
> containing the pool of FormObjects wrapped in a container Object to
> handle returning them to the Pool.
> It shouldn't be too difficult. Jakarta have an Object Pooling project.
> I'll have a look at the problem over the next week or so and get back
> to you when I have a working version.
> 
> Regards
> 
> Nick Sanderson
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Got root? We do.
> http://thinkgeek.com/sf
> _______________________________________________
> FormProc-developer mailing list
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer


- /\/

--
Nick Bauman 
Cortexity Development
Minneapolis, MN, 55412 
612-232-7120

RE: [FormProc-developer] Data from session Object

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

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Nicholas Sanderson
> Sent: Saturday, July 06, 2002 9:53 AM
> To: for...@li...
> Subject: RE: [FormProc-developer] Data from session Object
> 
> 
> Hi Anthony
> 
> 
> I checked out the extended HttpForm. That's pretty much the 
> kind of thing except where you cast the object to String from 
> the session I think it might be safer to use
> 
> Object o = session.getAttribute(key);
> String s = o.toString();

Actually, I only cast the attribute key to a String.  The
HttpSession.setAttribute() method only allows a String for the key, so I
figured it wasn't a problem (please feel free to correct me if I am
wrong).  The FormData class keeps the name/value pair as String/Object
so that a validator, converter or storer which is application specific
can do whatever it needs with the value object.  The default validators
tend to convert the value to a String using the toString() method.

<snip>

> The HttpForm pooling mechanism should probably be put in an 
> extended FormManager maybe PooledFormManager which could be a 
> singleton containing the pool of FormObjects wrapped in a 
> container Object to handle returning them to the Pool. It 
> shouldn't be too difficult. Jakarta have an Object Pooling 
> project. I'll have a look at the problem over the next week 
> or so and get back to you when I have a working version.

Sounds good.

-Anthony

RE: [FormProc-developer] Data from session Object

[Nicholas S. <ni...@sa...>]

Hi Anthony


I checked out the extended HttpForm. That's pretty much the kind of thing
except where you cast the object
to String from the session I think it might be safer to use

Object o = session.getAttribute(key);
String s = o.toString();

in order to avoid class cast problems if different classes(to String) were
stored in the session.

Of course initially this approach will still limit one to strings and
numbers. More exciting objects would require the toString method overriden
to return a serialised form of data that could be reconstructed in a
converter object.

The HttpForm pooling mechanism should probably be put in an extended
FormManager maybe PooledFormManager which could be a singleton containing
the pool of FormObjects wrapped in a container Object to handle returning
them to the Pool.
It shouldn't be too difficult. Jakarta have an Object Pooling project. I'll
have a look at the problem over the next week or so and get back to you when
I have a working version.

Regards

Nick Sanderson

RE: [FormProc-developer] Data from session Object

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

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Nicholas Sanderson
> Sent: Friday, July 05, 2002 8:39 PM
> To: for...@li...
> Subject: [FormProc-developer] Data from session Object
> 
> 
> Hi
> 
> I've just started using formproc and I really like it.

Glad to hear it.

> A couple of questions:
> 
> 1. I'm using formproc in a web environment where everything 
> gets reused - ejb pooling, connection pooling etc.
> 
> How much resource optimisation does formproc perform? Could 
> the HttpForm objects be allocated from a pool rather than a 
> new one being created for each new transaction.

I don't see any reason why this would be a problem.  You would just have
to make sure to configure the form properly before using it.  You could
either do this when HttpForm objects are initially put into the pool, or
you could do it at each request (although I think that this would negate
the benefits of pooling).  I don't really think this should go into the
FormProc lib though - perhaps if you put together a system for pooling
HttpForm objects you can contribute it back to the community.  I would
be happy to add it to the CVS as a contribution and make a note of it on
the FormProc web site.

> 
> 2. The object autopopulate feature is extremely useful. Could 
> the HttpForm be extended so it could find data from the user 
> session as well as from the request? After all it can get the 
> session from the request and it would be quite elegant to 
> combine the two.

I just wrote up an extension of the HttpForm class (called
org.formproc.servlet.ExtendedHttpForm) real quick and placed it in the
CVS server.  I haven't tested it but let me know if it will do the job
or if there is something I can do to make it better.

Sincerely,
Anthony Eden

[FormProc-developer] Data from session Object

[Nicholas S. <ni...@sa...>]

Hi

I've just started using formproc and I really like it.

A couple of questions:

1. I'm using formproc in a web environment where everything gets reused -
ejb pooling, connection pooling etc.

How much resource optimisation does formproc perform? Could the HttpForm
objects be allocated from a pool rather than a new one being created for
each new transaction.

2. The object autopopulate feature is extremely useful. Could the HttpForm
be extended so it could find data from the user session as well as from the
request? After all it can get the session from the request and it would be
quite elegant to combine the two.

Regards

Nick Sanderson

[FormProc-developer] FormProc 1.0 Released

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

FormProc version 1.0 is now available at http://www.formproc.org/ .

Thank you to all who have contributed to FormProc.  This release is largely due to the valuable feedback provided by
FormProc users and contributors.

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.

This release includes the following changes: Improved handling of null and empty values.  Conversion skipped if value is
null while the store mechanism will try to handle null values.  Added optional flag to FormElement.  Added
ValidationResult.getValidator() method.  Added originalData Map to FormResult.  Added getOriginalValue() and
getOriginalValueAsString() to FormResult.  Added methods for getting messages for specific fields.  Fixed NPE in
IsIntRule.  Fixed error on null in PasswordValidator.py.  Fixed potential NPE in Form class.  Added LongConverter
implementation.  Added missing JavaDoc comments.  Removed ant libraries and build scripts.  You must now have ant
installed to build FormProc from source.

For more information please visit http://www.formproc.org/ .  You can also join the FormProc mailing list at
http://lists.sourceforge.net/lists/listinfo/formproc-developer .

RE: [FormProc-developer] optional fields

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

> -----Original Message-----
> From: for...@li...
> [mailto:for...@li...]On Behalf Of Ken
> Keller
> Sent: Sunday, June 02, 2002 7:17 PM
> To: Anthony Eden; FormProc Developer List
> Subject: [FormProc-developer] optional fields
>
>
> >  1.) If field empty, return true as valid
> >  2.) If field not empty, validate using assigned validators
> >
> > If that is the case, then you would have to put that logic in the
> > validator (i.e. in a regular expression validator you would have to
> > account for empty values).  Perhaps it would be useful to be able to tag
> > a field as optional?
>
> I think so. I don't want the converter to run on an empty field either.

I have checked in changes to the CVS which implement an "optional" flag on a FormElement.  If the element is optional
then validation, conversion and storing will be skipped.  Check out the example application to see examples of the
optional flag.

>
> I also think it would be nice to have these ValidationResultMap methods:
>
> String getOriginalValue(name): Should only return null if name doesn't
> exist.
> Object getConvertedValue(name): Can return null.
> Object getConvertedOrOriginalValue(name): Return the original value if
> invalid--otherwise the converted one.
> String [] getGroupErrorMessages()
> String getErrorOrMessage(name): Return the message if valid--otherwise the
> error msg.
>
> Instead of having to deal with two ValidationResultMaps, it would be nice to
> have a wrapper object.

Right.  I will look into adding these methods.

-Anthony

[FormProc-developer] optional fields

[Ken K. <kk...@sn...>]

>  1.) If field empty, return true as valid
>  2.) If field not empty, validate using assigned validators
>
> If that is the case, then you would have to put that logic in the
> validator (i.e. in a regular expression validator you would have to
> account for empty values).  Perhaps it would be useful to be able to tag
> a field as optional?

I think so. I don't want the converter to run on an empty field either.

I also think it would be nice to have these ValidationResultMap methods:

String getOriginalValue(name): Should only return null if name doesn't
exist.
Object getConvertedValue(name): Can return null.
Object getConvertedOrOriginalValue(name): Return the original value if
invalid--otherwise the converted one.
String [] getGroupErrorMessages()
String getErrorOrMessage(name): Return the message if valid--otherwise the
error msg.

Instead of having to deal with two ValidationResultMaps, it would be nice to
have a wrapper object.

Ken

RE: [FormProc-developer] FormProcService

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

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Ken Keller
> Sent: Sunday, June 02, 2002 6:30 PM
> To: Anthony Eden; FormProc Developer List
> Subject: [FormProc-developer] FormProcService
> 
> 
> I looked at your CVS.
> 
> So the idea is to have Turbine create a 
> TurbineFormProcService instance & call init() which creates a 
> FormManager once.
> 
> You call:
> HttpForm aForm = formProcSvc.createForm(name, target);
> The service binds the FormManager for you.
> 
> Does this make the svc available to Velocity as $FormProc?

No.  I did not write the "pull" part of the service yet.  I am not
completely familiar with how Turbine works so a lot of this is new for
me.  Once I do I imagine I would like to be able to expose the Form
object as $form (or perhaps have some way to name the form, i.e.
$myForm1 or $myForm2...but perhaps that isn't necessary or even
possible).

> Even if it did, I don't think it can be used from Velocity 
> screens without either putting various collections into the 
> Context such as: $formFieldResults $formFieldGroupResults 
> $formFieldMessages or adding more methods such as:
> $form.getGroupErrorMessages()
> 
> Am I missing something? -Ken

Well, if you have a Form object and you call form.process() with the
HttpServletRequest then the results are in the FormResult object.
However none of this is exposed in the context.  Like I said up above I
still need to work out the "pull" part of the service.

Sincerely,
Anthony Eden

RE: [FormProc-developer] I'm running 1.0b2

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

I suppose it depends on which validator you are using.  I must assume
that the behavior you are looking for is:

 1.) If field empty, return true as valid
 2.) If field not empty, validate using assigned validators

If that is the case, then you would have to put that logic in the
validator (i.e. in a regular expression validator you would have to
account for empty values).  Perhaps it would be useful to be able to tag
a field as optional?

If you just wanted to have a value always ignored then you could just
not assign a validator, but somehow I doubt this is your intention.

Sincerely,
Anthony Eden

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Ken Keller
> Sent: Sunday, June 02, 2002 3:35 PM
> To: Anthony Eden; FormProc Developer List
> Subject: [FormProc-developer] I'm running 1.0b2
> 
> 
> I'm running 1.0b2.
> 
> How can I get the behavior of optional fields, i.e., empty 
> fields shouldn't be validated? -Ken
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's 
> Conference August 25-28 in Las Vegas -- 
> http://devcon.sprintpcs.com/adp/index.cfm
> 
> 
> _______________________________________________
> FormProc-developer mailing list 
> For...@li...
> https://lists.sourceforge.net/lists/listinfo/formproc-developer
> 

[FormProc-developer] FormProcService

[Ken K. <kk...@ig...>]

I looked at your CVS.

So the idea is to have Turbine create a TurbineFormProcService instance &
call init() which creates a FormManager once.

You call:
HttpForm aForm = formProcSvc.createForm(name, target);
The service binds the FormManager for you.

Does this make the svc available to Velocity as $FormProc?

Even if it did, I don't think it can be used from Velocity screens without
either putting various collections into the Context such as:
$formFieldResults
$formFieldGroupResults
$formFieldMessages
or adding more methods such as:
$form.getGroupErrorMessages()

Am I missing something? -Ken

[FormProc-developer] I'm running 1.0b2

[Ken K. <kk...@ig...>]

I'm running 1.0b2.

How can I get the behavior of optional fields, i.e., empty fields shouldn't
be validated? -Ken

RE: [FormProc-developer] I haven't tested FormProcService yet

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

> -----Original Message-----
> From: for...@li...=20
> [mailto:for...@li...] On=20
> Behalf Of Ken Keller
> Sent: Sunday, June 02, 2002 12:22 PM
> To: Anthony Eden; FormProc Developer List
> Subject: [FormProc-developer] I haven't tested FormProcService yet
>=20
>=20
> First let me say that at ign.com we're been using our own=20
> validation framework for over a year. Now I'm surveying what=20
> others have done. Your framework looks very well done.

Glad you like it.  It is good mostly because of the input I have
received from others using it.

>=20
> * * *
>=20
> If you leave the age field blank, you get:
>=20
> java.lang.NullPointerException
> 	at org.formproc.example.IsIntRule.validate(Unknown Source)
> 	at=20
> org.formproc.validation.RuleValidator.validate(Unknown Source)
> 	at=20
> org.formproc.validation.ValidatorGroup.validate(Unknown Source)
> 	at org.formproc.Form.validate(Unknown Source)
> 	at org.formproc.Form.process(Unknown Source)
> 	at org.formproc.Form.process(Unknown Source)
> 	at org.formproc.Form.process(Unknown Source)
> 	at org.formproc.servlet.HttpForm.process(Unknown Source)

Which FormProc version are you using?

>=20
>  <shared-validator name=3D"age">
>   <validator type=3D"group">
>    <validator type=3D"rule">
>     <rule>org.formproc.example.IsIntRule</rule>
>     <error>Valid number required</error>
>     <error lang=3D"fr">L'=E2ge valide a exig=E9.</error>
>    </validator>
>    <validator type=3D"expression">
>     <pattern>[1-9][0-9]*</pattern>
>     <error>Age must be 1 or greater</error>
>    </validator>
>   </validator>
>  </shared-validator>
>=20
> Should the expression validator be listed before the IsIntRule?

The IsIntRule isn't necessary, per se.  I only included it in this
context as a way to demonstrate how group validators work.

> Since the age field isn't marked required, why do the=20
> validators get applied when the field is blank?

It is required, even if the message doesn't say so.  Validators are
always applied on a field if the validator exists.  If there is no
validator for a field then a PassValidator will be used which just
passes the value through as valid.

>=20
> * * *
>=20
> In the example, you decided to hold the form's state in a=20
> User in the session. This doesn't seem correct to me. It=20
> seems preferable to redisplay the invalid form w/ the invalid=20
> strings. After all, you're validating from the HttpRequest=20
> via HttpForm. So would the code be something like this?
>=20
> Age:
> <% if (! elementResults.isValid("age")) { >%
> <input type=3D"text" name=3D"age" value=3D"<%=3D=20
> req.getParameter("age") %>"> <font color=3D"#ff0000"> <% else {=20
> %> <input type=3D"text" name=3D"age" value=3D"<%=3D user.getAge()=20
> %>"> <font> <% } %> <%=3D form.getMessage("age", locale) %> </font>

You could design it that way.  The only reason I hold it in the object
in the session is because in my systems objects in the session are only
saved when an explicit save() method (or something similar) is called.
Thus the in-memory state is only for temporary storage.  You could also
store the results in a HashMap.  Check out the
org.formproc.store.MapStorer class.  Eventually I will include another
example which will use that as an example.  You can also create a custom
Storer to function however it makes sense for you.  Another Storer which
I am working on will store the data in an XML document.

> * * *
>=20
> formManager.configure(form);
>=20
> To avoid repeated parsing of the XML, should the formManager=20
> be instantiated once per app?

Yes.

> * * *
>=20
> > BTW: Have you tried the FormProcService which is a TurbineService=20
> > implementation yet?  I haven't tested it yet so I would be=20
> interested=20
> > if anyone who does use Turbine on a regular basis would=20
> take a look at=20
> > it. It is in the CVS in the turbine-service module.
>=20
> Turbine 2.1? Did you program this service? Is there any documentation?
>=20
> Thx. -Ken

I believe I wrote it against 2.2b2 API.  It is actually in the FormProc
CVS - there is no affiliation with Turbine.  It is just something which
I threw together quickly so it may not even work.  The only
documentation is in the code (JavaDoc).  I would definitely classify it
as "experimental". :-)

Sincerely,
Anthony Eden

[FormProc-developer] I haven't tested FormProcService yet

[Ken K. <kk...@ig...>]

First let me say that at ign.com we're been using our own validation
framework for over a year. Now I'm surveying what others have done. Your
framework looks very well done.

* * *

If you leave the age field blank, you get:

java.lang.NullPointerException
	at org.formproc.example.IsIntRule.validate(Unknown Source)
	at org.formproc.validation.RuleValidator.validate(Unknown Source)
	at org.formproc.validation.ValidatorGroup.validate(Unknown Source)
	at org.formproc.Form.validate(Unknown Source)
	at org.formproc.Form.process(Unknown Source)
	at org.formproc.Form.process(Unknown Source)
	at org.formproc.Form.process(Unknown Source)
	at org.formproc.servlet.HttpForm.process(Unknown Source)

 <shared-validator name="age">
  <validator type="group">
   <validator type="rule">
    <rule>org.formproc.example.IsIntRule</rule>
    <error>Valid number required</error>
    <error lang="fr">L'âge valide a exigé.</error>
   </validator>
   <validator type="expression">
    <pattern>[1-9][0-9]*</pattern>
    <error>Age must be 1 or greater</error>
   </validator>
  </validator>
 </shared-validator>

Should the expression validator be listed before the IsIntRule?

Since the age field isn't marked required, why do the validators get applied
when the field is blank?

* * *

In the example, you decided to hold the form's state in a User in the
session. This doesn't seem correct to me. It seems preferable to redisplay
the invalid form w/ the invalid strings. After all, you're validating from
the HttpRequest via HttpForm. So would the code be something like this?

Age:
<% if (! elementResults.isValid("age")) { >%
<input type="text" name="age" value="<%= req.getParameter("age") %>">
<font color="#ff0000">
<% else { %>
<input type="text" name="age" value="<%= user.getAge() %>">
<font>
<% } %>
<%= form.getMessage("age", locale) %>
</font>

* * *

formManager.configure(form);

To avoid repeated parsing of the XML, should the formManager be instantiated
once per app?

* * *

> BTW: Have you tried the FormProcService which is a TurbineService
> implementation yet?  I haven't tested it yet so I would be interested if
> anyone who does use Turbine on a regular basis would take a look at it.
> It is in the CVS in the turbine-service module.

Turbine 2.1? Did you program this service? Is there any documentation?

Thx. -Ken

RE: [FormProc-developer] does anyone use this w/ Turbine/Velocity?

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

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Ken Keller
> Sent: Saturday, June 01, 2002 11:01 PM
> To: for...@li...
> Subject: [FormProc-developer] does anyone use this w/ 
> Turbine/Velocity?
> 
> 
> Does anyone use this w/ Turbine/Velocity?
> 
> When I open:
> localhost:8080/formproc-example
> 
> I get the index.jsp except the Age fields contains 0. Is this 
> intentional?

It is just a side-effect of the fact that User.age field does not have
an initial value.  You could probably change it to type Integer and then
check for null and display nothing if the value is null.
 
> If I fill in all fields, process.jsp presents the User object 
> just fine.
> 
> If I leave either password field blank, I get a stack trace:
> javax.servlet.ServletException: exception from JPython: 
> Traceback (innermost
> last):
>   File "", line 5, in ?
> TypeError: len() of unsized object
> 
>  at 
> org.apache.jasper.runtime.PageContextImpl.handlePageException(
> PageContextImp
> l.java:442)
>  at 
> org.apache.jsp._0002fprocess_jsp._jspService(_0002fprocess_jsp
> .java:166)
>  at 
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>  at 
> org.apache.jasper.servlet.JspServlet$JspServletWrapper.service
> (JspServlet.ja
> va:200)
>  at 
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet
> .java:379)
>  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:453)
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

This has been fixed in the CVS (it was a problem in
PasswordValidator.py).

> 
>  If I type the wrong date format, the date field is blanked 
> when the former is redisplayed. Is this intentional?

Right now the converter behavior is to throw an exception if the date is
formatted incorrectly.  If an exception is thrown then the value is
never saved to the object.

BTW: Have you tried the FormProcService which is a TurbineService
implementation yet?  I haven't tested it yet so I would be interested if
anyone who does use Turbine on a regular basis would take a look at it.
It is in the CVS in the turbine-service module.

Sincerely,
Anthony Eden

RE: [FormProc-developer] bug submission + feature request

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

> -----Original Message-----
> From: for...@li... 
> [mailto:for...@li...] On 
> Behalf Of Fabien DUMINY
> Sent: Saturday, June 01, 2002 5:40 PM
> To: for...@li...
> Subject: [FormProc-developer] bug submission + feature request
> 
> 
> I have just discovered FormProc and I find it great.

I am glad.

> 
> ______________________________________________________
> 1 - I found a bug in my tests (I use a custom components to 
> render field values) :
> 
> at line 344 of Form.java in process(FormElement ...):
> 
> replace
> if(formData == null || formData.getValue().equals("")){
> 
> by
> if(formData == null || formData.getValue()==null || 
> formData.getValue().equals("")){ 

The code in the CVS is already fixed, although slightly differently:

if(formData == null || "".equals(formData.getValue())){

> ______________________________________________________
> 2 - A great feature that I need is :
> checking constraints between fields and another dynamic value 
> (that is not in the form).
> 
> Fields are : "quantity", "unit value of article" 
> dynamic value is : "balance of an account used to buy articles"
> 
> Is there anybody working on such a feature ?

No.  This sounds a lot like business logic which means it probably
shouldn't be in FormProc directly.

However, if you do come up with something interesting and want to
contribute it, just send me the files.

Sincerely,
Anthony Eden

[FormProc-developer] does anyone use this w/ Turbine/Velocity?

[Ken K. <kk...@ig...>]

Does anyone use this w/ Turbine/Velocity?

When I open:
localhost:8080/formproc-example

I get the index.jsp except the Age fields contains 0. Is this intentional?

If I fill in all fields, process.jsp presents the User object just fine.

If I leave either password field blank, I get a stack trace:
javax.servlet.ServletException: exception from JPython: Traceback (innermost
last):
  File "", line 5, in ?
TypeError: len() of unsized object

 at
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImp
l.java:442)
 at org.apache.jsp._0002fprocess_jsp._jspService(_0002fprocess_jsp.java:166)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
 at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:200)
 at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:453)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

 If I type the wrong date format, the date field is blanked when the former
is redisplayed. Is this intentional?

Thx. -Ken

[FormProc-developer] bug submission + feature request

[Fabien D. <fab...@we...>]

I have just discovered FormProc and I find it great.

______________________________________________________
1 - I found a bug in my tests (I use a custom components to render
field values) :

at line 344 of Form.java in process(FormElement ...):

replace
if(formData == null || formData.getValue().equals("")){

by
if(formData == null || formData.getValue()==null ||
formData.getValue().equals("")){
______________________________________________________
2 - A great feature that I need is :
checking constraints between fields and another dynamic value (that is
not in the form).

Fields are : "quantity", "unit value of article" 
dynamic value is : "balance of an account used to buy articles"

Is there anybody working on such a feature ?

____________________________________________________________________
- http://www.WebMailSPro.com - >> 
VOTRE service d'email sans pub avec VOTRE nom de domaine