cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: [RT] New validator and propagator infrastructure
Date Mon, 22 Oct 2001 09:43:28 GMT
On 19.Oct.2001 -- 07:44 PM, Martin Man wrote:
> hi all,
> 	in response to well-known action flood we have seen over past
> days(weeks) I'd like to propose rewrite of validator actions. The result
> should be one "validator" action which will do the work of all existing
> validator actions and maybe even more. I think we should do this before
> 2.0final, because it's not more than cleanup work... and I'm volunteering to
> do it actually but first to hear some comments...

Hi Martin,

I've been sitting here with some similar work regarding database
actions but haven't come around finishing them. The idea with them is
to put things that are DBMS dependant into components and specify them
as needed. Actually, after a while I started to put input and output
into components as well. Since it's still rather unpolished code and
not finished yet, I have not put it into CVS but you can find a copy
There you'll find the following archives as well as the unpacked code
under extracted

      modular_db.tar.gz            the code
      build.xml.diff.gz            necessary to skip the informix
				   module when no informix jdbc driver
				   is present.
      modular_db_example.tar.gz    an example to mount at
				   cocoon/ch/mod-db. I had some
				   problems with relative context:
				   URLs here, so you might need to
				   change the sitemap.
				   The example uses a db connection
				   "test" which is currently an
				   informix db over here and I haven't
				   had the time to merge it into the
				   supplied db this morning.
      test.sql.gz		   aforementioned db schema

Currently, ModularDatabaseAddAction uses code from AbstractSitemap to
load and configure the components but I think it would be better to
have them at least on sitemap level available.

The input / output work is delegated to three different kinds of
helper components:

    -------- AccessHelper ----
    |                         |
AttributeHelper       KeyAttributeHelper


AttributeHelper obtain values for non-key columns, e.g. from request
parameters or session attributes etc.

KeyAttributeHelpers obtain values for key columns. Since this involves
quite often autoincrements which are handled quite differently by each
DBMS it allows to get the value before or after the operation, even by
executing a query, and whether the value should be present in the sql

OutputHelpers store the query results somewhere, e.g. in request
attributes. They are also informed whether the transaction completed
successfully or was aborted.

The interface AttributeHelper is probably too complex. The idea was to
have a modified descriptor file that has three configuration options
for every column: a table configuration, a column configuration and a
mode configuration. Here the mode configurations contains the
important infos like the name of a request attribute.

I think this is not necessary and could be trimmed down to one
configuration and that way those helper components could be of use for
other actions, matchers and selectors as well.

I would be very glad to have some feed back on this. The next step
would be to add update, delete, and select actions as well. Then I
would have thought about making the helper components available to
other sitemap components. I might change that order now, though :-)

> 1. Validator
> ============
> 1.1. What to validate
>  - request-attributes 	[java.lang.object]
>  - request-parameters 	[java.lang.string]
>  - session-attributes 	[java.lang.object]
>  - cookies      		[java.lang.string]

There will always be some other place to look for the values as
well. E.g. we might want to obtain the values from some bean.

> 1.2. Supported types and validation criterias
>  - long		[min, max, equals]
>  - double	[min, max, equals]
>  - string	[max-len, matches-regexp, equals, equals-ignore-case]
>  - date		[valid] (probably (min|max)-(day|month|year) ???)
>  - xml		[well-formed, valid]
>     additionaly all datatypes will have attribute `nullable' and `default'
> with obvious functionality.


> 1.3. Validation descriptor
> 	will look as it is now with some additions,
> <validate check="request, session, cookies">
>     <parameter name="xxx" type="section 2." optional criterias from 3. 
>         check="cookies, session"/>
>     <constraint-set name="is-administrator" check="session">
>         <validate name="xxx" optional criterias from 3. check="cookies"/>
>     </constraint-set>
> </validate>
>     note that attribute `check' will specify where to look for parameter,
> request-attributes will be checked before request-parameters.
>     iner-most attributes take always precedence, so that easy overriding
> mechanism is available

I don't see why it would be necessary to have a sequence of places
where to obtain the values from, but I have no objections either.

> 1.5. Issues
>  - Should we try to validate parameter from next storage (according to `check'
>    attribute) if the first value fails or we should stop immediately...

Rather if it is not present. Failure -> stop, not present -> next storage

>  - after given set (or parameters) are validated they're all available under
>    their respective names to sitemap via {name} expression. Here I think we
>    should try to extend the descriptor syntax and allow automatic propagation
>    of validated parameters into one of the following storages (see 2.1)

I think it should be pluggable like the input.

>  - because common use of validators is with database actions we *should* also
>    at least share the same descriptor for both types of actions, database
>    actions typicaly need only `name', `type' and table/collumn mapping... I can
>    see posibility to map given constraint-set to database table and <validate>
>    statements to provide mapping between parameters-columns (with additional
>    key/mode information).


>  - simple database authenticator can then also authenticate users against
>    given set because it will know which columns to fetch from which table and
>    to which parameters to compare them.
>  - how to extend descriptor syntax that would allow us to validate session
>    itself (as SessionIsValidAction and others)

Good point. One could write an input helper component that returns a
boolean value depending on this.

> 2. Propagator (creator)
>     propagators were initialiy intended to ease the creation of various
> parameters from sitemap, e.g.
>     <map:act type="propagator">
>         <parameter name="store-to" value="session"/> <!-- request, cookies -->
>         <parameter name="value" value="{1}"/>
>     </map:act>
> 2.1. Where to store (propagate)
>  - to session attributes
>  - to request attributes
>  - to cookies
>     note that we can store arbitraty objects to session/request attributes and
> strings to cookies. because brace expressions {name} are actualy objects taken
> from map, we have to convert them to strings before storing into cookies, I
> think we anyway use it for strings...
> I'd like to see your comments and suggestions as well as existing experience
> with validator/authenticator/propagator actions that we now have for almost 4
> months. All those changes I'd like to do as soon as RequestContext will be
> available (and I'm sure it will be ;-)
> P.S. note that I left aside formval logischeet which surely will need the
> appropriate changes as well, please attach comments/experience to this 
> topic as well (some new ideas Christian ???)


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