cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcelo F. Ochoa" <>
Subject Re: Some Cocoon-Hacks [Was: Re: Best way to include ouitput of one page into another?]
Date Wed, 29 Mar 2000 21:36:43 GMT
Ricardo Rocha wrote:

> 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
> instance...

   This isn't complete true. SQLJ support Dynamic and Static Model of SQL.   I have
developer idea, and imagine enterprise development with Java, which exchange Java code
free from Oracle or DB2 Stored procedures written in Java with SQLJ.
   This code may be migrate from the servers to Web Servers with XSP without change.
   IMO probably with other processor put in pipeline with XSP permit write XSP with
      Ej:     XML+Java+SQLJ  ->  (XSP Processor) -> Java Code + SQLJ ->  (SQLJ
Translator)  -> Pure Java with JDBC 1.x compliant calls -> Compiled classes as producer.

> 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.

   I agree but, it's new technology and don't permit gradual migration from RDBMS model
to pure Objects model. What's happen with a lot programmers with procedural skills?

> 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
> environments.
> Regards,
> Ricardo


View raw message