cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: [C2] actions, forms, etc.
Date Tue, 12 Jun 2001 16:32:27 GMT
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 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

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=""
   b) if only interested in validation results, just 

		 if (<xsp-formval:is-ok name="input"/>) {
		      <xsp:content> (OK) </xsp:content>
	         } else {
		      <xsp:content> (ERROR) </xsp:content>

      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
	  <xsp-formval:descriptor name="descriptor.xml" constraint-set="user-input">
	     this parameter must be at least <xsp-formval:get-attribute parameter="input" name="min"/>
   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

		  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">
		 if (<xsp-formval:is-ok/>) {
		      <xsp:content> (OK) </xsp:content>
		 } else if ( <xsp-formval:is-toosmall/> ) {
		      <xsp:content> (zu klein (&lt; <xsp-formval:get-attribute name="min"/>))</xsp:content>
	         } else if ( <xsp-formval:is-toolarge/> ) {
		      <xsp:content> (zu groƟ (&gt; <xsp-formval:get-attribute name="max"/>))</xsp:content>
	         } else {
		      <xsp:content> (ERROR) </xsp:content>

I'd be delighted if this could make it into the CVS.

Enjoy. Feedback welcome.


C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

View raw message