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) :)



Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to