cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <>
Subject Re: Some Cocoon-Hacks [Was: Re: Best way to include ouitput of one page into another?]
Date Wed, 29 Mar 2000 00:56:52 GMT
On Tue, 28 Mar 2000, Marcelo Ochoa wrote:
> Stefano or Ricardo, how about to add SQLJ processor to XSP code
> SQLJ is an standard extension to Java to write embedded SQL code inside Java.
> It's look like this:
>                SQLJ Example
>                long length; #sql length = { values(dbms_lob.getLength(:blob)) };
>                Equivalent JDBC Example
>                CallableStatement cs = conn.prepareCall( "{call ? =
> dbms_lob.getLength(?)}"
>                ); cs.registerOutParameter(1, Types.NUMERIC);
>                ((OracleCallableStatement)cs).setBLOB(2, blob); cs.executeUpdate();
> long length
>                = cs.getLong(1); cs.close();
>     SQLJ is more concise and thus easier to write than JDBC, and provides
> compile-time schema validation and syntax checking for easier debugging.
>     SQLJ takes as input either a file of SQLJ clauses or a file of Java source code
> in which SQLJ clauses are embedded. The SQLJ precompiler translates the SQLJ
> clauses into their equivalent JDBC calls. SQLJ supports static SQL.
>     Each line of SQLJ is mapped to around five lines of JDBC calls.

Hmmm... While I like SQLJ (at least for some Oracle stuff), I'd say it's not a
good idea to use it in XSP logicsheets.

It appears to me SQLJ shines for _static_ SQL. XSP logicsheets, on the other
hand, would typically serve dynamic SQL statements, an area where I find
plain JDBC more appropriate. I may be too religious on this, but I can't imagine
writing an XSP logicsheet where an application-specific tablename is used, for

For database applications, it would be preferable to use technologies like
Castor and Tyrex that provide _transparent _mapping among Java objects, XML
documents and RDBMS data.

Now, this doesn't mean there isn't a place for purely database-driven
applications like those we used to write for "traditional" client/server

For this I like Marcelo's original idea of a connection manager logicsheet,
an idea I've prototyped and can be seen at:

In prototyping Marcelo's idea, I went a step beyond simple connection
pooling to also include a general mechanism for executing arbitrary
database queries and updates.

The "connection.xsl" logicsheet provides a functionality similar to that
of Donald's "sql.xsl" logicsheet plus connection pool management and
database updates. This is probably something we might extend if someone
finds it useful (as it stands now it's kinda kludgy).



View raw message