Re: [Zope] Re: [Zope-dev] Zope Book call for assistance

[Jeffrey P Shell]

On Saturday, December 7, 2002, at 04:11  AM, Tino Wildenhain wrote:

Hi Chris,

--On Freitag, 6. Dezember 2002 21:27 -0500 Chris McDonough <[EMAIL PROTECTED]> wrote:

On Fri, 2002-12-06 at 19:13, Tino Wildenhain wrote:

These are exactly the things you shouldn't neither do in DTML
nor in ZPT :-)

What do you suggest people use for a templating language for email,
JavaScript, SQL, etc?  I think it's too much to expect them to use
Python to do this (esp. wrt SQL methods).

Oh, is it? I'd rather like to write %(name)s %(value)d
then <dtml-whatever value>
Recently I read the python-dbi spec and its very nice to see
what you could do with the above form. There are even
standard ways to do multiple querys or function calls.
(Hope I can contribute a product for this as time permits)

But SQL Method DTML is very very very very nice. It has a lot of type enforcement/safety measures (ie - autoquoting SQL Strings, ensuring that a 'sqlvar type=float' operation is inserting a float); a lot of *very* nice features for generating 'where' clauses (the sqltest 'optional' flag and the smart '<dtml-and> and <dtml-or>' tags that won't render if an optional 'sqltest' preceding them was not rendered); the 'sqltest multiple' feature is especially nice:

<dtml-sqlgroup where>
<dtml-sqltest foo type=nb multiple optional>
</dtml-sqlgroup>

If foo is a blank string or empty list, that will render nothing.

If foo is a single string, that renders::

where foo = 'bar'

But if foo is a list of strings, that will render::

where foo in ('bar', 'baz')

Doing that programatically in Python is counterintuitive and awkward (just as it was before the specialized 'dtml-sql___' tags in DTML). For simple queries, doing it in the host programming language is not bad. But for complex queries, it's very awkward to generate SQL. It's almost as bad as generating HTML inside of a programming language - it becomes difficult to maintain.

For E-Mail and Javascript templates I also find it less confusing
if I can use %(var)s form.

It's worth noting that there's a little known DTML format that's of this style. Again - when doing simple insertion, %(var)s is not bad. But once anything fancy comes into play - conditional insertion, looping, etc - maintainability goes out the window when staying in the host programming language. When I was evaluating Roundup <http://roundup.sf.net>, I wanted to generate emails that looked as good as the ones generated by Tracker. I had to write lines and lines and lines of Python code to do it in order to replace a subclassed method. There was no template that I could jigger around. (To be fair to Roundup and Tracker both, I think customizing Tracker's email messages is even harder).

I wouldn't mind seeing DTML.String re-emerge, which complements the Python formatting string with DTML constructs to handle more advanced templating needs. If you took a lot of the programming-language style tags (dtml-try, dtml-return) out of DTML and normalized the expression system (ie - to use TALES), you'd have a very usable system. The core design concepts of DTML are good, it's just corrupted itself over the years by stepping out of the plain-text templating language domain and straddling the templating/programming language domains. DTML is even used to generate DTML, by using the Extended Python Format String syntax. This is how the 'Z Search Interface' custom reports are generated.

As a general solution for texts one can use "file" which has an edit
tab for several releases of zope now. Then use it like this:

context.thefile.read() % context.REQUEST.form

or whatever seems appropriate to get values from.

E-Mail even gets clearer with the solution since you can easyly
loop and do whatever instead of multiple <dtml-sendmail> tags.

Life would be so much better if odd tags like <dtml-sendmail> could just go away, and instead we had 'SMTP Methods' or something like that - mail specific templates that are bound to a mailhost, with special DTML tags (like the mime tag), similar to SQL Methods.

I love the SQL Method specific DTML tags. They make writing dynamic SQL statements so easy, especially when compared to _any_ other system that I've seen. It's a good showcase for DTML's ability to turn into a domain specific templating language.

Regards
Tino

_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )