[Zope3-dev] Zope 3 web root

[Paul Winkler]

On Thu, Feb 16, 2006 at 02:16:05AM -0700, Jeff Shell wrote:
> I think that Zope 2 suffered heavily from the "too many ways to do it"
> when it came to ways of doing development, and there were gulfs
> between each style. Each style had its plusses too. ZClasses certainly
> had an appreciative audience who liked defining schemas and building
> forms automatically through the web with little programming required.
> But working with templates and scripts in  ZClasses had a bit of a
> different feel and behavior than working with those things in the
> 'content' space of the site. And it was very different than working
> with file system based products.

+1.  The killer moment for me with ZClasses was when I realized
I wanted to convert one to a filesytem Product and that meant
I had to literally throw away everything and start from scratch.
Never again.

That's also what I dislike about zope 2's "scripts".
What the hell are they?  "Script" is a misnomer, they're more like
function bodies with access to a magic set of globals (context,
container, and so forth).  If you want to convert a script into a method
of a zope 2 Product, you have to figure out what those bindings would
mean in the context of that product, maybe even change the call
signature and update all the callers.  This is tiresome.

I liked the Persistent Module proposal better, in theory, although I'm
not sure how much I would have liked it in practice given some of the
restrictions that were proposed.

So my plea is:  If we're going to have more than one way to do it,
let's please not invent lots of special magical things that
"just work" in one mode of development and have to be laboriously
rewritten in the other mode of development. It makes the border
between modes of working too hard to cross and makes Zope 2 feel
rather un-agile at times.

> environment. It's less natural for Python. If persistent code doesn't
> behave quite like regular Python code, then there's still a gulf that
> has to be crossed when one wants to "move up" from persistent code.

Right. That gulf should be very very minimal, or "special" kinds
of code (whether persistent, or somewhere in Shane's filesystem
tree) eventually becomes a pain IMO. 

<OT subject="zope2">
Lately I've been wondering whether the whole security-restricted
feature of Zope 2 TTW scripts is even a feature at all.
I've always toed the party line that it's a good thing that joe shmoe
scripter can't shoot himself in the foot by creating a regular
expression that crashes the server.  But then, I've never met joe shmoe
scripter.  I think zope.org's model of allowing barely-trusted people to
develop software on a public site through the web is rather exceptional
and dubious as the basis for framework development.  Everybody writing
scripts on all the projects I've done has been a full developer with
full filesystem access; our scripts generally lived in CMF
FilesystemDirectoryViews; the whole restricted thing was nothing to us
but a giant PITA.  Then I got to wondering: Are there any other web
frameworks that have restricted code? 

As far as I know (which isn't very far), J2EE doesn't, Rails doesn't,
DJango doesn't, Subway doesn't, and *none of them envy us for it*.
Maybe they are right not to?

I know that if a user writing a script could import and call anything,
he could elevate his permissions and get access to previously-denied
parts of the system.  What I'm finding increasingly dubious is the
idea that a person who's not allowed access to the whole zodb 
should be allowed to write code at all. 
</OT>

-- 

Paul Winkler
http://www.slinkp.com