[RT] interface layer for request/session/... parameters (+ new DB actions)

[Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>]

Team,

I believe, this was lost during the pre-release frency, so I'd like to
bring it up again.


When using the current database actions, I encountered two problems:
1) auto increment columns work differently with every DBMS and only
Oracle was supported and 2) when entering data to more than on table
and the foreign key happens to be an auto increment type, it was
impossible to access that value.

Hence I decided to come up with something more generic, that would
satisfy my needs. The result, I think, should be of interest to the
core sitemap components, too.

We have observed the need to generate separate matchers, selector,
actions that operate on different parameter sources. We have selectors
on request headers, request parameters, request attributes, session
attributes and there sure will be more sources for parameters. Thus
requiring us to duplicate the code and replace the source. 

This might be feasible for simple components, but for components like
the database actions or form validation to name a few, it is not.

Therefore I suggest to put this into adaptor components and let the
other sitemap components use them. I think this is not the flexibility
syndrome but a real need.

Please have a look at the scratchpad additions I made (in
org.apache.cocoon.acting and below, example in
webapp/mount/mod-db). Since I messed up contextualization, the example
needs to be placed in mount/mod-db. Point your browser to
http://localhost:8080/mount/mod-db

Some remarks on the current implementation:

1) Currently, this implementation is pretty self-contained. Therefore,
   the adaptor components need to be configured and managed by every
   component that uses them separately. In the future this should
   change. Although these adaptors appear candidates for cocoon.xconf,
   I would like to see them configured at sitemap level. Suggestions?

2) The adapter components currently reside in the
   acting.ModularDatabaseAccess package. That should be
   changed. Perhaps only the AutoIncrementHelpers should stay there. 

3) I copied a lot code from AbstractSitemap, but I think the original
   code has changed since then and I messed it up to a large
   extent. Also, component handling is not 100% compliant with
   "Developing with Avalon", but since that has to be changed anyway,
   when the above issue is settled, please ignore it for now.

I have identified three different types of adaptors: AttributeHelper,
that allow reading of parameters; OutputHelpers, that allow writing of
parameters; and AutoIncrementHelpers, that handle the differences with
auto increment columns for databases. More on each type below.

AttributeHelper have the "usual" interface: getAttribute,
getAttributeValues, getAttributeNames. It does not support setting
attributes. All methods take a configuration object that could contain
arbitrary values. The methods should have reasonable default values so
that it'll be able to work correctly if that configuration object is
missing.

OutputHelper allow setting and reading of values. Actually, I think
that reading should not be in this interface, but
AbstractDatabaseAction requires both. Anyway, that shouldn't be a real
problem to remove this. One thing that I'm not sure about, is making
OutputHelper transaction aware. The idea was, when talking to an EJB
it might be useful to have this. Comments? Besides it follows the same
pattern as AttributeHelper above.

AutoIncrementHelpers allow all different methods to use auto increment
columns that I was able to identify. As an example implementations for
Informix, HSQLDB, and the "manual" method from current database
actions are provided.

The "new" database framework.

It's probably best to look at the extensively commented example. So,
here only the major differences:

o) table-sets similar to constraint-sets known from form validation
o) of course, support for auto increment columns
o) column values can stem from different sources (e.g. auto increment
   ID from previous INSERT needs to be read from request attributes
   while other data has to be read from request parameters)
o) no @dbcol -- @name serves for this as well
o) @alias takes precedence over table @name. Some weirdos might want
   to put complex "from" statements in @name which would lead to
   rather longish attribute names ;-)

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org