cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From solprovi...@apache.org
Subject Re: Cocoon database access strategy
Date Sun, 24 Jun 2007 13:57:52 GMT
On 6/24/07, Tobia Conforto <tobia.conforto@linux.it> wrote:
> 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:
>
>         SELECT ...
>         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!

I just checked the online API and the sources for 2.1.10 and
trunk/HEAD without finding @deprecated or @Deprecated.  The databases
block is marked stable for 2.1.10.  Where is the SQLTransformer
deprecated?

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message