This might be a bit impatient but then I think this might have been
slipped through as the original mail didn't contain the word "Patch"
in the subject and belongs to a thread several days old.
Enclosed is a patch that enables more verbose form input validation
plus a taglib that makes access to validation results easy.
Feedback welcome. Enjoy.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Well, it's been a while since this thread came up....
Sorry for not CCing this mail to all involved authors but this is
rather long and it touches several classes.
I. Introduction
II. Contents of the attached archive
III. Notes on the patch
IV. Usage
I. Introduction
Currently FormValidatiorAction only returns null if validation fails
leaving it for the application (xsp) to figure out what went wrong.
This is where this patch comes in.
This patch enables FormValidatorAction to communicate to the
application a more verbose error status through an request
attribute. In addition a new taglib allows easy access to the
results. On top of that this taglib gives access to the attributes for
parameters declared in those section in descriptor.xml relevant to the
validation process.
II. Contents of the attached archive
The attached archive contains a patch plus a number of new classes, a
new taglib, and a new jar-File.
This new jar -- enumeration.jar was created from a compiled version of
an enumeration factory class available at
http://home.t-online.de/home/Christ-Usch.Grein/Java/EnumFact.html I
think the licence is compatible so it can be included.
III. Notes on the patch
The patch is done against 2.1-dev.
Since this adds a number of new classes I wasn't sure where to put
them. I think most are placed suitably right, one class
"org.apache.cocoon.acting.ConfigurationHelper" however might need to
be moved. This class was introduced because I feel descriptor files
should be reloaded when they change. Because I borrowed code from
org.apache.cocoon.acting.AbstractComplimentaryConfigurableAction to
load and cache configurations and modified it so that reloads can
occur I placed it where it is currently.
I think AbstractComplimentaryConfigurableAction should be modified
accordingly to facilitate reloading as well. (Haven't done that
yet. Comments?)
I used the enumeration factory mentioned above because I strongly
believe that enumerations are superior to coding the values to ints
bearing implicit semantics. I hope it's OK.
Another thing might be that AbstractValidatorAction and
FormValidatorAction could communicate the error code by exceptions. As
I believe the error code is part of the result I coded it as return
value rather than an exception. In addition this return code is also
needed for communication with the XSP thus adding to this impression.
In AbstractValidatorAction I needed to introduce some methods that I
believe would be better suited within the Avalon API. These are
getAttributeAsLong returning java.lang.Long and getAttributeAsDouble
returning java.lang.Double. Avalon provides only getAttributeAsFloat
but not Double. Unfortunately AbstractFormValidator is designed to
handle Doubles. In addition I found that returning and taking as
arguments Objects is more convinient as it is easier to figure out if
the attribute is present. (OK could have used the one without default
and cought the exception. I believe the code is cleaner this way
though.)
IV. Usage
1) Modified FormValidatorAction
Behaves as before. Only change is that it used to bail out on the
first invalid parameter while now it validates all.
2) xsp-formval Taglib
a) declare its name space
xmls:xsp-formval="http://apache.org/xsp/form-validator/2.0";
b) if only interested in validation results, just
<xsp:logic>
if (<xsp-formval:is-ok name="input"/>) {
<xsp:content> (OK) </xsp:content>
} else {
<xsp:content> (ERROR) </xsp:content>
};
</xsp:logic>
Bear in mind though, that the result is communicated through
request attributes. These are discarded whenever a new request
object is created. This happens for example when using
redirections within the sitemap....
c) if you'd like to be more specific what went wrong, you could
query the descriptor file for attributes
<!-- first set the url of the file or resource that contains
the parameter descriptions and constraint sets.
This needs to be an ancestor to all other tags (of this
taglib). Multiple use of this tag is allowed (although
probably not necessary).
You need to do this only if you plan to query the
descriptor file or if you'd like to use the shorthand
below.
-->
<xsp-formval:descriptor name="descriptor.xml" constraint-set="user-input">
this parameter must be at least <xsp-formval:get-attribute
parameter="input" name="min"/>
</xsp-formval:descriptor>
d) if you need to use one parameter a lot, there's a short hand
<xsp-formval:descriptor name="descriptor.xml" constraint-set="user-input">
<!-- work on parameter named "input2". Use this e.g. if
you'd like to set up the properties of an input tag
according to the information from the descriptor
file or if you'd like to give detailed error
messages.
Note that you can specify additional attributes in
the description file that are not understood (and
therefore ignored) by the FormValidatorAction but
that could be queried here. This might be e.g. the
size of the input field which might be different
from the max-len a parameter can take.
-->
<xsp-formval:validate name="input2">
<xsp:logic>
if (<xsp-formval:is-ok/>) {
<xsp:content> (OK) </xsp:content>
} else if ( <xsp-formval:is-toosmall/> ) {
<xsp:content> (zu klein (< <xsp-formval:get-attribute
name="min"/>))</xsp:content>
} else if ( <xsp-formval:is-toolarge/> ) {
<xsp:content> (zu groß (> <xsp-formval:get-attribute
name="max"/>))</xsp:content>
} else {
<xsp:content> (ERROR) </xsp:content>
};
</xsp:logic>
</xsp-formval:validate>
</xsp-formval:descriptor>
I'd be delighted if this could make it into the CVS.
Enjoy. Feedback welcome.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
formvalidation-patch.tar.gz
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
