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

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

Reply via email to