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 at http://www.dvs1.informatik.tu-darmstadt.de/~haul/misc/c2 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 OutputHelper 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 statement. 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 > 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). Indeed. > - 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 ???) Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
