[Zope3-dev] RFC: zopeproject

[Philipp von Weitershausen]

On 19 Jul 2007, at 19:15 , Dieter Maurer wrote:
>> and toning down Zope for an easier entry.
>
> But, Zope is quite easy on entry.

To some, probably many, it is easy. At first. Then they discover the  
limits of TTW development and hit the wall of having to learn this  
completely new and different way of doing Zope development  
("products" instead of "TTW").

I also know a fair number of people who were simply so confused by  
this ZMI thing and the whole concept of TTW development (mostly  
because it's so different than *anything* else out there, and they  
couldn't use their favourite tools) that they swore never to do  
anything with Zope. They didn't even get to the good stuff  
(filesystem-based development).

> I expect that the traditional "Zope-the-application" was easier
> to install and to build applications with than your new approach
> which requires:
>
>   *  paste
>
>   *  WSGI

These two are not only used by many other web frameworks, they're  
also documented by them. That means we can share not only code and  
knowledge but also documentation efforts.

Having standards like these two is good. Look at Java. The Servlet or  
Portlet APIs are probably not the prettiest ones, but sure everybody  
who ever has to do anything with them will find tons of docs on them.  
And s/he will be able to use that knowledge, once gained, pretty much  
everywhere.

>   *  zopeproject
>
>   *  the application package
>
>   *  one instance per application
>
> True, experts can combine different Python web frameworks -- but what
> part of the Zope audience will need this?

A great consequence of WSGI are middlewares. They're general purpose  
applications that plug between a server gateway and a WSGI  
application, be it Pylons, TurboGears or Zope. These are not really  
frameworks, but more "filters" that are easy to re-use.

In my talk "Zope on a Paste" at the DZUG and EuroPython conferences,  
I've demonstrated a number of general purpose middlewares that are  
completely third-party to Zope. They include simple things like  
logging and gzipping as well as very useful things like interactive  
debugging and XSLT-based theming. And the best thing is that they can  
be plugged in by a mere 2-4 lines of configuration.

So basically they're useful and easy to use. I think *lots* of people  
in the Zope audience will find them useful. At least the audiences  
both times I've given the talk seemed to welcome the idea quite a lot.

> True, Python experts can be more economic with their knowledge.
> But, it appears the things become more difficult for non-experts.

In a blog post [1] that I wrote a while ago, I've collected my  
thoughts on why I think TTW development is a failed model,  
*especially* for beginners. Instead of posting these thoughts here,  
I'll simply link to it and invite you to read it.

In a follow up to that post [2], I was able to report "proof", so to  
speak, that the standard, down to earth Python approach (in the form  
of Grok) actually fitted people's brains much better. It fitted so  
well that we had people contributing to Grok that hadn't worked with  
Zope3 or Grok at all a few months or even weeks before that. At the  
EuroPython sprint last week, we could again observe the same happening.


[1] http://www.z3lab.org/sections/blogs/philipp-weitershausen/ 
2007_03_27_meet-grok-successor
[2] http://www.z3lab.org/sections/blogs/philipp-weitershausen/ 
2007_04_19_why-zclasses-dead-why