Mark, Jonathan (Integic) wrote:
As many of us know, BDFL Guido doesn't seem to think much of Zope. He
allegedly feels that Zope forces one to learn Zope instead of Python.
There is some truth to that. My goal is to leverage Zope's ZMI and CMS
features while doing as much work as possible in Python and Python
scripts.
I thus object philosophically to ZPT and DTML and hope to avoid them in my
product, which should be released on Zope.org to a probably indifferent
Zope world some time later this year. I can use Cheetah as an external
method with Python scripts, instead of ZPT and DTML.
Why do you object philosophically to them? DTML is nasty, I would agree, but
I've yet to find a web templating language that works as well in practice as
ZPT in terms of separating design and presentation (especially when combined
with Zope 3 views; and possibly moving in the direction of something like
Pushpage by Tres). I guess it comes down to taste. I found Cheetah
horrendously ugly, aesthetically speaking.
My attempt to use Chris's Twiddler templating tool as an external method
instead of Cheetah ran into a problem which I am sure was my fault,
although Twiddler worked great from my Zope instance's Python command
line. I didn't feel like figuring out what my mistake was. The Path of
Least Resistance was to use Cheetah, and I believe that there is great
wisdom in the Path of Least Resistance. Deviate from that path only to
travel on the Path of Greater Wisdom. Twiddler and Cheetah appear equally
wise, so PLR said go with Cheetah.
I want as much as possible of my Zope 2.10 blogging product (working name,
Aristede, for which I own the Aristede.com domain name) to be visible in
Python scripts and folder properties. External methods should be only a
wrapper to Cheetah and to other Python modules that can't be imported into
Python Scripts.
I'm not sure if this is constructive, but it seems to me that you are trying
to use Zope in a way that, at best, people are actively moving away from, or
at worst, it wasn't really designed to be used. In particular, it seems
strange to me to want to have pyscripts that explicitly call Cheetah
templates, and to make extensive use of external methods (why not just use
products and filesystem code in custom objects that represent your data
model?).
Also note that if all you really need is a blog, there are probably existing
solutions you could use and build on rather than have to create your own.
In truth, you may be interested to learn more about Zope 3 and even grok.
They are different ways of programming, but more pythonic and very
powerful. I can recommend Philipp von Weitershausen's Zope 3 book
(http://worldcookery.com) (disclaimer: I helped proof read it), if you want
to learn something new and exciting.
My paranoid nature is due to a fear of creating my own product and finding
out that I have left a security hole. By using Eval in my external method
I can avoid coupling the external method which calls Cheetah to the list
of properties which I send Cheetah, and reduce the amount of code which I
need to do it. But Eval is super dangerous to use. It is a trade-off
between code simplicity and security.
Hence my desire to make certain that no one can pass from inside a URL
parameters which are later Eval'd to my external method.
Eval sounds like a really nasty hack (isn't it always?). You'll probably
find it hell to debug as well... I would assume it's possible to write some
first-class object in Zope that could act similarly to DTML or ZPT objects
but do the rendering using Cheetah, if you really want to use that.
Martin
--
View this message in context:
http://www.nabble.com/Is-there-any-way-to-turn-off-the-publishing-of-external-methods-to-the-web-in-Zope--tf3122776.html#a8693535
Sent from the Zope - General mailing list archive at Nabble.com.
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
