[Zope3-dev] Re: [Zope-DB] Relational Databases in Zope 2 and Zope 3

[Scot Roberts]

Charlie Clark wrote:

>Well, judging by the traffic on the Zope-DB list since I've been on it 
>opinions on this are divided but I think the majority of those in the 
>relational world are *strongly* against <dtml-sqltest> and <dtml-sqlgroup>. 
>They do not add functionality as they replicate SQL and introduce obscurity 
>as a result. While SQL has lots of problems it is important that those using 
>it really understand what they are writing *and* reading. If you have to be 
>able to understand the resultant rendered SQL you should by definition be 
>able to write it in the first place. And then there is the issue of 
>maintenance - other people might have to read your code!
>
>  
>
I don't see how they introduce much obscurity. If anything, I've found 
<dtml-sqlgroup where> to make my sql code easier to read when I'm 
dealing with a variable number of where clauses. It's not a matter of 
not being able to write the rendered SQL in the first place - the whole 
point is that some of the SQL is being generated on the fly which is why 
I'm using templates. As for the issue of code maintenence, that's why I 
comment the code.

>That said - it is obvious some people will want to keep <dtml-sql> because 
>they are comfortable, happy and productive with it. So ZSQL methods will grow 
>some options to suit coding style.
>
>There remains the issue of it would be nice to have some way of controlling 
>SQL statements so that code reuse in the sense of string reuse is possible, 
>ie. mixing in conditions or joins when appropriate. A TALES/METAL approach to 
>this seems to me complimentary to current SQL but this discussion is only 
>just beginning.
>
>  
>
What I don't understand when you say a TALES/METAL approach to dynamic 
SQL statements is that TALES/METAL is very HT/XML orientated, is meant 
to be easy to use in HTML editors and is designed to seperate 
presentation from logic (and in doing so I've found it makes logic 
harder to do), none of which are needed in a dynamic SQL templating 
language (if anything, I want easy to use logic here). Or do you mean 
that the underlying machinery would be similar TAL, though it would end 
up looking similar to what we have with <dtml-sql*>?


cheers

Scot





www.five.tv
_______________________________________________________

This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. It must not be used by or its contents copied or disclosed to persons other than the intended recipient. Any liability arising from any third party acting or refraining from acting on any information contained in this e-mail is excluded. If you have received this e-mail in error please notify the sender immediately and delete it and any copies from your computer and network. This e-mail has been checked for viruses but it is the responsibility of the recipient to ensure that the opening use or onward transmission of the e-mail and any attachments will not adversely affect its systems or data and no responsibility is accepted by Five in this regard. 
_______________________________________________________