On Tuesday 07 March 2006 12:27 pm, Shane Hathaway wrote: > Part of the problem is that Zope 3 makes too great a distinction between > developers and scripters. Successful scripters become developers, and > developers often act as scripters. I think the use cases need to see > scripters and developers as the same people. The other Python web > frameworks seem to be oriented this way and they've had a lot of success.
I would add that scripters and developers are often the same people, but with greatly different levels of commitment: For a project I care a lot about (or am well paid for), I might be perfectly willing to make the "buy in" to develop a complete app from components. For this, I want something flexible, modular, and well-engineered, which I can use as a solid foundation for my project. OTOH, for a quick project to help a local non-profit out, I might only be willing to do through-the-web scripting (so I want something quick and easy that's almost ready "out of the box" -- flexibility is good, but immediate results are better). In fact I have been in both of these situations (at the same time). The framework-based Zope 2 is probably better for the latter case (at present), though the learning curve to do anything beyond the most simple tasks is steep. That's partly because it's a framework, but also partly because of the "historical accidents" of design that make Zope 2 so inconsistent (and hence confusing to use). E.g. why the heck do I have to remember an attribute named "bobobase_modification_time"? This sort of thing is why the Zope 2 API *must die*. ;-) Zope 3 is clearly targeted for the high-buy-in case, but paradoxically, reduces the buy-in because of its modular design. Zope 3 is actually what I wanted when I found Zope 2 in the first place. OTOH, I have a lot of uses for plain scripting environments. I do program (and I'm more proud of that work), but I do *more* website "crafting" in my everyday life. A framework built *on* Zope 3 can solve the "historical accident" problems, which would make for a better scripter environment than Zope 2, but it's always going to have limitations to its flexibility. Which is okay, IMHO -- I have the choice to leap from "scripter" to "developer" if I want that flexibility. That's a small leap if I'm leaping from TTW on top of Zope 3, to Zope 3 component development. That's good, because a free software development environment thrives by maintaining a smooth "graded slope" between user and developer, rather than drawing a distinction -- somewhere along that slope you can call people "designers", "maintainers", "scripters" or whatever, but the important point is the continuity -- not just of skill, but also of interest (or time-available). Again, I'm not a core Zope developer, so this is an outsider view, but I feel like I'm in your "market" which is why I should respond. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
