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"/>
</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
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"/>
</map:act>
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}"/>
</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 ???)
thanx for reading so far,
martin
--
2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
