On Thu, 16 Feb 2006 17:16:21 -0000, Alexander Limi <[EMAIL PROTECTED]> wrote:
I have a real client application where the templates themselves *are*
the content being managed: they are *not* software. They *must* be
stored in the ZODB. You could think of these things as "active content
components," or somthing, and they are not logically the same thing as
"stock" templates used for software, but they do include ZPT.
But shouldn't this be an dedicated, custom content type with a transform
or something to handle that particular use case?
That'd be my immediate design idea, too.
I'm agreeing violently with most of the other people here that see no
use for scripting things through the ZODB. Both developer usability-wise
("you can access some modules but not others") and security-wise, it is
a nightmare. Pretty much all the security holes ever found in Zope
through the years have only worked when you allow untrusted users to
author DTML or Python Scripts residing in the ZODB.
Perhaps not violently, but I'm slightly baffled... I'm still a Z3 virgin,
but everything I've been told so far is that the whole
code-in-content-space (and ZODB == content space as far as I'm concerned)
was bad. And I totally agree. CMF tools in content space? Yuck! Page
templates deep into some user-managed folder hierarchy?
If they are needed (and I haven't yet seen a need, but probably because I
haven't written any large Z3 applications), then surely we should devise
better ways of doing things, not encourage mangling of code and content.
Additionally, working as a developer coach for people new to Zope,
explaining people the rationale behind TTW scripting becomes an exercise
in futility ("but why can't I use the set functions in a Python
Script?").
Some means of TTW customisability (primarily of page templates) is very
useful for very simple customisations and has been a good way to sell
Plone, certainly. But the line in the sand needs to be clear. I'd
personally be happy if ZPTs (with python: expressions intact) could be
overridden TTW in a similar way to how CMF's portal_skins/custom works and
that was it. No python scripts in the ZODB, no other nonsense. When you
want to program, you should program (and we should make it sufficiently
easy to set that up so that you can program).
If Zope 3 only allowed code on the FS by default, the world would be a
better place. The only thing it has going for it is TTW customization on
hosting setups that don't allow their customers SSH access, but Zope
isn't hostable in the "$5/month PHP hosting" way anyway. You pretty much
need a dedicated server or at the very least a jail to do anything
useful with Zope.
Keep it simple, and remember: "there should be one -- and preferably
only one -- obvious way to do it".
High +1. Or rather, there should be one well-thought-through,
well-documented and well-designed way. (incidentally, this is why I hate
Perl) :)
Martin
--
(muted)
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
