Paul Browning wrote:
OK, this is true of most things (computer languages, foreign languages, mental arithmetic, parenthood, etc) - if you don't use it, you lose it. But there is something about DTML that distinguishes it (for me) from other languages - it's the rate at which it decays on you. Python's decay constant is much more favourable.
I think this would be a very useful metric to measure how effective any improvements to DTML are, can you stick it in the relevent wiki somewhere?
So I've learned a rule of thumb - if I'm writing DTML and it isn't flowing then I really ought to be using Python.
This isn't always true IMHO...
PythonMethods are nice but, as they stand, you only have access to built-in functions. So if you want to import modules you have to resort to External Methods. [Am I talking nonsense here? My empirical experience is that I can use string functions in a PythonMethod but not, say, stuff from the time module. Neither string nor time are built-in though ..... so why one and not the other?]
I hope you're talking nonsense ;-)
The point of these reflections: * PythonMethods ought to be a high priority IMHO.
Very much so...
* DTML is holding Zope back for the rest of us (and is arguably a "proprietary" component of Zope (in that you can't use it anywhere else) - this is a disincentive to many power-Perl,JSP,<name-your-scripting-poison> users I suspect.
I think all these scripting poisions are proprietery and will remain so in that sense. The sad fact is that DTML ranks amoung the worst of them right now, IMVHO...
* Please can we import Python modules from PythonMethods (or can we already and I don't about it, or does this break the sandbox that PythonMethods is meant to provide)?
Would be nice, if not, reasons why not... :-)
* Don't worry about changing DTML syntax. It's an excellent marketing ploy to ensure good sales of the 2nd edition of The Zope Book ;-)
heh :-) Well, thanks for your views, I guess you started when it was still <!-- --> ? ;-) cheers, Chris