cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobia Conforto <>
Subject Re: Cocoon database access strategy
Date Sun, 24 Jun 2007 09:14:38 GMT
Rob Frohwein wrote:
> - query1.xml    using SqlTransformer on table1
> - cleansql.xsl  rename <sql:dbfield>
> - process1.xsl  reorganize
> - query2.xsl    query different table
> - cleansql.xsl  rename <sql:dbfield>
> - process2.xsl  reorganize
> ...
> It works, but is this the "right" approach?

I'm also using this approach here and there.
It's not without its virtues, namely:

  1. you're only using declarative languages

  2. it's a mix of interpreted and JIT technologies, so you don't need to
     explicitly compile anything -> faster development cycles

  3. the steps (query > transform > query > ...) are naturally decoupled
     by the XML stream between them (decoupling = good)

  4. you can easily see what every step is producing with Cocoon's views

It works well, but it has some security and performance problems (more
on that in a minute) so I'd like to know if there's a better approach.

One of the problems with the SQL Transformer, when used with XSLT in
this fashion, is that it lacks support for prepared statements and
parameters.  Without parameters (<esql:parameter> in XSP) you have the
same security problems you would have in badly written PHP:

	FROM ...
	WHERE name = '<xsl:value-of select="my:addslashes($name)"/>'

You did think of this problem, didn't you? :) I can post my:addslashes()
if you want.  In any case you will agree that composing queries this way
is... "antiquated" at best.

The compiled query cannot be cached (as a prepared statement would),
because it changes with every request, and I fear the SQL Transformer
doesn't even try to cache it.

All this makes me think that this approach, although having some
advantages, is not what the SQL Transformer was made for.

Therefore I reiterate Rob's question to more expert Cocoon users: is
there an alternative, secure, caching way of generating XML from DB
queries using only declarative languages?

If not, why is the SQL Transformer deprecated?  I would sooner add
support for caching prepared statements, with parameters and all, than
deprecate it!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message