cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject [Announce] mod-db moved from scratchpad to trunk
Date Thu, 23 May 2002 17:39:34 GMT
Hi.

I have almost finished moving the mod-db stuff (including of course
the component/modules hierarchie and the demo matchers) from
scratchpad to trunk. Almost, because the sample system seems to be
broken, thus I have not included the sample with the sitemap and
sample-apps.xml Currently, the easiest way to have a look at the
example is to use a checkout of cocoon_2_0_3_branch, build with
scratchpad and go to the scratchpad examples -> mount -> mod-db

Please note that I have effectively copied all files from scratchpad
to trunk and then removed the branch tags for cocoon_2_0_3_branch or
HEAD where applicable. Thus it is still available for
cocoon_2_0_3_branch in scratchpad and moved to the final destination
in HEAD. OTOH this means that bugs need fixing in both places.

What is it?

*  First, it adds low-level, simple components called "module" to Cocoon
   for basic in-/output like reading / setting request parameters,
   request attributes and so on. Think of them as small cousins to
   sources. While sources are used to obtain large blocks of data,
   modules operate on simple values. 

   In addition their use is very similar to operation e.g. on request
   attributes and so it is very easy to switch a component to use modules
   instead of accessing these values directly. That allows e.g. the
   separation of a matcher (wildcard) and the value it works on (request
   parameter). An example is located in the matching.modular package.


*  Second, it adds brand new, shiny database actions that make heavy use
   of the above modules for obtaining values. Besides the interface
   (i.e. values propagated to sitemap and request attributes) is now
   consistent and operating on multiple rows and tables is _much_
   improved. 

   Also, a special type of modules is introduced just for database:
   modules that read values of autoincrement columns from the DBMS after
   an insert operation.

   With the use of input meta modules (modules that themselves use other
   modules to obtain the actual values), operations on collection data
   types is made easy. 

Please note that there is a usage document for both in the documentation package.

Have fun.

	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


Mime
View raw message