You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cocoon.apache.org by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de> on 2001/06/12 18:32:27 UTC

Re: [C2] actions, forms, etc.

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 (&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>
                 };
	     </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
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Re: [C2] actions, forms, etc.

Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.

Davanum,

On 19.Jun.2001 -- 05:19 AM, Davanum Srinivas wrote:
> 1. Checked in your docs. Please take a look.

fine.

> 2. XSP should be working now.

indeed, no problem here anymore.

> 3. Did you try using "context:///" (note the extra '/') instead of context://. If this does not
> work, please let me know.

Yes, I had a problem using it from a sub sitemap. I have been
reluctant to report that problem and well, it has been fixed anyway :-)

Attached you find a sample for the form validation taglib. New files
are in the archive, changes in the patch.

In addition the patch fixes some minor glitches I caused last time and
adds a tag to xsp-formval to retrieve all validation results in a
java.util.Map.

More noteworthy is, that it also patches
AbstractComplementaryConfigurableAction in a way that configuration
files are reread when they change. This is done exactly like it was
done in XSPFormValidatorHelper by using the Source and
ConfigurationHelper Classes. I have suggested this a while back and no
one commented it, so I reckon it's OK to do so :-)

This entails a API change, since
AbstractCom....Action.getConfiguration now takes an additional
argument, whether reloads should occur or not. This is controlled by a
new parameter "<map:parameter name="reloadable" value="true"/>" for
each invocation of an action in the sitemap. Consequently, all Actions
that call getConfiguration are patched as well.

To keep compatible an additional method is there with the old
signature that calls the modified method with reloadable=true.

You might want to either remove that method or not modify the other
actions. Of course you could also apply the patch as is :-)

Chris.

--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08