cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Man <>
Subject [RT] New validator and propagator infrastructure
Date Fri, 19 Oct 2001 17:44:47 GMT
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...

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]

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"/>

    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

1.4. Invocation from sitemap
    <map:act type="validator">
        <parameter name="descriptor" value="...."/>
        <!-- either whole set -->
        <parameter name="validate-set" value="is-administrator"/>
        <!-- or only enumerated parameters -->
        <parameter name="validate" value="xxx, yyy, zzz"/>

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...
 - 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)
 - 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)
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}"/>

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 ???)

thanx for reading so far,
2CC0 4AF6 92DA 5CBF 5F09  7BCB 6202 7024 6E06 0223

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

View raw message