Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
Jeffrey P Shell wrote:
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.
Yes, I think SQL methods are going to stick around. The downside is
there are some things that they SHOULD do that they dont, and that DTML
doesnt (to my knowledge) facilitate.
For example, dtml-sqltest foo type=nb ought to be able to check with
the underlying DA, and ask that DA to help it format its parameters.
Currently the render() method used by DTML seems to be presumed to be a
string, but what you want back is
(foo=:foo, ('foo',foo)) # or whatever all this foo foo sounds
like a poodle
so that any bind variables can be handled more efficiently by the DA.
Since each DA handles bind variables differently, it has to be involved
in the process to return a string with substitution text, and the value
to be substituted later. The DA's query method currently takes only a
string, but it should take a string and a concatenation of bind variables.
I remember looking at it and not wanting to get into trying to track
down where DTML would have to change to allow nonlinear results.
There may well be something in DTML processing that would make this
simple, I'm not very well versed on DTML processing internals.
--
Matt Kromer
Zope Corporation http://www.zope.com/
___
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 )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
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 )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
DTML needs to be given the same amount of attention as it always has. For some bizarre reason, DTML makes sense in my headeven complicated logic... Doctor! Do I need help? It's one of the reasons I really liked Zope three years ago when starting with it The tag structure just made sense and was similar to a tool I used to get database calls and logic on a web page... Long live DTML!! - Original Message - From: Chris McDonough [EMAIL PROTECTED] To: Tino Wildenhain [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, December 06, 2002 9:50 AM Subject: Re: [Zope] Re: [Zope-dev] Zope Book call for assistance erm... would advanced DTML not be the short sentence: avoid DTML where you can? ;) That'd be ok, except that DTML can of course do things that ZPT can't, yada yada yada. Btw. did you think of putting the whole DTML stuff at the end for reference only to help migrating old products and turn the whole thing a bit around so beginners get a clear path of Zope development? I found it a bit confusing when I edited the german translation of the 2.3 book a year ago. That's probably a good idea. But I think the rewritten chapters explain when to use ZPT and when to use DTML. And DTML still needs to be given some attention for the reason I say above... - C ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) ___ 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 )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
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) For E-Mail and Javascript templates I also find it less confusing if I can use %(var)s form. 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. Regards Tino I'd start the lessons with ZPT to only show static content and may be macros. Then the logical order would be introduction to python scripts without HTML output - only show how they are used to calculate and output simple values, lists, dictionaries and so on. Next chapter should show how one uses the scripts with ZPT to provide output into HTML. Then the usual things like Catalog, ZSQL, important API parts, etc. Don't you think this would be clearer for the beginner? Sure. I'd love to rewrite the entirety of the Zope Book. But please notice that I'm asking for help finishing the existing chapters, so I don't think this is a realistic goal. - C ___ 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 )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
On Sat, 2002-12-07 at 06:11, 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) For E-Mail and Javascript templates I also find it less confusing if I can use %(var)s form. 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. The solution then would be to write several new chapters that talk about how to do this. - C ___ 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 )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
erm... would advanced DTML not be the short sentence: avoid DTML where you can? ;) That'd be ok, except that DTML can of course do things that ZPT can't, yada yada yada. Btw. did you think of putting the whole DTML stuff at the end for reference only to help migrating old products and turn the whole thing a bit around so beginners get a clear path of Zope development? I found it a bit confusing when I edited the german translation of the 2.3 book a year ago. That's probably a good idea. But I think the rewritten chapters explain when to use ZPT and when to use DTML. And DTML still needs to be given some attention for the reason I say above... - C ___ 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 )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
Hi Chris, --On Freitag, 6. Dezember 2002 09:50 -0500 Chris McDonough [EMAIL PROTECTED] wrote: erm... would advanced DTML not be the short sentence: avoid DTML where you can? ;) That'd be ok, except that DTML can of course do things that ZPT can't, yada yada yada. These are exactly the things you shouldn't neither do in DTML nor in ZPT :-) I'd start the lessons with ZPT to only show static content and may be macros. Then the logical order would be introduction to python scripts without HTML output - only show how they are used to calculate and output simple values, lists, dictionaries and so on. Next chapter should show how one uses the scripts with ZPT to provide output into HTML. Then the usual things like Catalog, ZSQL, important API parts, etc. Don't you think this would be clearer for the beginner? Regards Tino Btw. did you think of putting the whole DTML stuff at the end for reference only to help migrating old products and turn the whole thing a bit around so beginners get a clear path of Zope development? I found it a bit confusing when I edited the german translation of the 2.3 book a year ago. That's probably a good idea. But I think the rewritten chapters explain when to use ZPT and when to use DTML. And DTML still needs to be given some attention for the reason I say above... - C ___ 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 )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
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). I'd start the lessons with ZPT to only show static content and may be macros. Then the logical order would be introduction to python scripts without HTML output - only show how they are used to calculate and output simple values, lists, dictionaries and so on. Next chapter should show how one uses the scripts with ZPT to provide output into HTML. Then the usual things like Catalog, ZSQL, important API parts, etc. Don't you think this would be clearer for the beginner? Sure. I'd love to rewrite the entirety of the Zope Book. But please notice that I'm asking for help finishing the existing chapters, so I don't think this is a realistic goal. - C ___ 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 )
