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 _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
