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 ;-) And now: Feedback, please :-) 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]
