On 6/24/07, Tobia Conforto <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
