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] componentized input and new database actions
Date Fri, 15 Mar 2002 16:20:36 GMT

New Componentized Input / Output 
 ModularDatabaseActions gone


Now, that the race condition with HSQLDB is sorted out I have finally
committed the reworked "new" database actions in scratchpad. As
announced such a long time ago that probably no-one will remember they
come with new input, output, and database autoincrement components
that are open to be used by other sitemap components as well.


Why do we need to componentize input and output?

There are so many different sources of data to work with, request
parameters, request headers, request attributes, session attributes,
cookies to name a few. Currently, we need to have e.g. a
WildcardMatcher for every one of the above inputs. With a
componentized structure we need to combine only a WildcardMatcher with
the input we would like to use. 

Two example matchers are included to illustrate how it works.  But
it's not only matchers: actions and selectors can make use of it as
well.


Why don't we use Java generics instead?

Good question. Perhaps because they're scheduled for JDK 1.5 but since
we bundle pizza javac with cocoon we could use them now. With the
database actions I have made the experience that I needed input from
many different sources at the same time. Generics wouldn't help here.


ModularDatabaseActions are gone?

Not really, they've moved to a new home in their own package. And as
the packages name is org.apache.cocoon.acting.modular the "modular" part
was dropped from the name. Thus they are just called "DatabaseAddAction"
for example.


What is so great about the "new" DatabaseActions that I should switch
to them?

First of all, they know about autoincrement columns in HSQLDB, MySQL,
and Informix. And it is really easy to extent it to your DBMS if you
use a different one.

Second, you can put your complete database schema in one file and
refer to selected tables at will.

Third, all database operations can span multiple rows and tables.

Fourth, input for columns is very flexible.


Is there a reason why I shouldn't switch?

Yes, the descriptor file syntax has changed in incompatible ways to
allow the new features.


I want to have a look at it. Is there a demo?

Yes! Build CVS with "-Dinclude.scratchpad.libs=yes" and copy the
directory $COCOON_CVS/src/scratchpad/webapps/mount/mod-db to
$COCOON/mount with $COCOON_CVS being the location where your CVS
checkout resides and $COCOON being the location where the expanded
cocoon.war file is located. Point your browser to "mount/mod-db/"
relative to cocoon and enjoy. Usually, this would be
http://localhost:8080/cocoon/mount/mod-db/ 


What is next?

Two "meta" modules are in the works for SQL99 complex types like row
types and collections. They will obtain their input from any other
input module and produce Objects that can be inserted into such
columns.

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