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