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 Thu, 31 May 2001 09:02:25 GMT
On 30.May.2001 -- 08:12 PM, Martin Man wrote:
> actually we have previously came to another point. You are true that validator
> actions now return nothing when validation fails, this will be changed so that
> action will return special configurable param to the sitemap indicating what
> the result of validation was and which parameters where wrong (this param can
> later be used in param-selector), this way we
> just need to figure out how these wrong parameters propagate nicely back to
> the form, an XSP solution would be great but how to pass action's Map object
> to XSP efectively ??

How about using a request attribute? Those are reset after the
request, hence there's no cleaning up needed and no one is required to
use sessions. The attribute could be named
e.g. org.apache.cocoon.acting.FormValidatorAction.ValidateResults

This attribute should be a map object containing the result encoded in
an enumeration (as java does not support enumerations, probably
could be used. Licence seems compatible)

I think all parameters should be validated. But should multiple errors
for one parameter be catered for? E.g. too long and does not match

Should we integrate the XSP part into request.xsl?

 <xsp-request:param-is-valid name="request-parameter-name"/> returning boolean

 <xsp-request:param-error-code name="request-parameter-name"/> returning what?
 If it returns an enumeration, XSP needs to know about it,
 if it returns an error message, what about internationalization?

 switch(<xsp-request:param-error-code name="myparam"/>) {
    case FormValidatorResultCode.OK: break;
    case FormValidatorResultCode.MIN-LEN: <error> Too short </error> break;
    case FormValidatorResultCode.MAX-LEN: <error> Too long </error> break;

I volunteer to implement whatever we agree on this.

As I mentioned earlier, I'd like to provide some means to extract from
the descriptor.xml some data for input element creation. We might as
well combine that into a new taglib.

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

To unsubscribe, e-mail:
For additional commands, email:

View raw message