I do not think the SQL Transformer *is* deprecated... who has said it is? I think one of the issues is whether or not XSP is deprecated - or, otherwise, if its no longer considered "good practice", what alternatives are there? Some have said that XML, XSLT and the SQL Transformer on their own are sufficient for a complete database app; I have not found this to be the case, and am making use of flowscript - while this is clearly not a declarative approach and may not scale well for apps larger than, say, 50 tables (Hibernate would be much better in this respect), at least it avoids the compilation step and the language itself is pretty easy for most web developers to use/maintain (Cocoon-specific nuances aside).
>>> <[EMAIL PROTECTED]> 2007/06/24 03:57 PM >>> 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 -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED] This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
