cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject [ESQL/PATCH] proposed changes
Date Wed, 11 Jul 2001 12:28:31 GMT

I'm currently considering ORDBMS support in esql, well, actually, I
do have a version here that does it for C2. Davanum asked me to post
any patches to esql.xsl to this list before applying them. So please
comment the attached diff.

This mail is largely based on my posting from jul-04 on ordbms support
for esql with few modifications and comments what is already in
The simplest ORDBMS support would be to allow the user to get an
object from the query and to leave it to her/him how to deal with it.

In addition one could extend get-columns to extract advanced datatypes
as well. Over here on Informix IUS 9.21 these are mostly of
java.sql.Types.STRUCT for row types and java.sql.Types.OTHER for
everything else like sets, lists, bags. One way to determine the
correct type would be to try to cast the object to an appropriate
interface, say java.util.Set.
(done -- C2 only) 

How should the structure of an attribute be represented? Nesting alone
wouldn't do since it wouldn't be possible to distinguish sets from
structs. So we should introduce something like "sql-list", "sql-row",
"sql-set", plus some "sql-item" elements to capture e.g. the list
members. So far I didn't find a way e.g. to name the components of a
(done -- C2 only)

Another issue arises: encoding. "First class" attributes can be read
through getBytes() and converted afterwards. But nested attributes
only offer a toString() method, right? Would it be right to disable
the encoding parameter on nested attributes?
(currently no encoding for complex attributes)

Another feature could be, to manipulate the type mapping table for a
jdbc connection and allow to map advanced or user defined types to
map to a user provided java class. Jdbc drivers sometimes come with a
utility to create such a class from a db schema.
(not done -- should this be done? should this be done in cocoon.xconf
per connection pool?)

Other features I'd like to see in esql:

<esql:row-results> &c. "swallow" nested text which is not what users
expect (see cocoon-users list). Therefore it would be nice if the text
would be automtically enclosed in <xsp:content>.
(done --  example query is "select count(*) from mytable":
	      Currently <esql:get-int column="1"/> rows are present.

Supplying column names / numbers from a XSP variable (esql differs
from other taglibs in that it doesn't use the
"<esql:param name="column">1</esql:param>" notation, instead it uses
"<esql:column></esql:column>". I would like to change that.)
(done, you can now <esql:get-column>
		      <esql:param name="column">

Offer some direct paths to the esql code, like "get-metadata",
"get-column-type", "get-object", or even "get-resultset"

Make "get-xml" more powerful so that the db needs only to store
fragments of an xml document. Currently, only a root element without
any attributes is allowed here. Thus it is not possible e.g. to
specify a namespace for the fragment. 
(not done yet -- why doesn't it inherit the namespaces from the
original xsp? Is there a way to figure them out?)

BTW since it is possible to include other logicsheets, would it be
wise to put all utility tags (copy-all, get-nested-content,
get-parameter and the like) to a common logicsheet so that they could
easily be used by new logicsheets?


C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

View raw message