On 18 Jul 2007, at 21:13 , Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2007-7-18 01:13 +0200:
...
Imagine you're writing a GUI application. Without question you'd use
some sort of GUI toolkit (e.g. wxPython). Would you expect you would
have to hook into the the "wxPython application" as a plug-in?
Isn't it
more natural that you simply write your application and just use the
wxPython *library* wherever necessary?
Is this not the difference between a framework and a library?
An application uses a framework by hooking its components into
the framework.
A library is used directly -- only miminal hooking and callbacks
are used.
I view GUI frameworks typically as plugging my application parts into
the GUI (which triggers my application code) -- especially, if the
UI is build by an UI-builder...
Good point. In a way, we're actually doing this. For example, our
WSGI application gets called by PasteDeploy whenever the WSGI server
receives a request. That's how we hook into the "Paste framework".
Then, we don't really do our own URL dispatching. The Zope publisher
does its stuff and simply ends up calling our view code. That's how
we hook into the "Zope publisher" framework.
But then there are a bunch of things where *we* actually make the
calls: assembling forms, calling a templating engine, etc. So, we're
really doing both, using some frameworks and using some libraries.
Maybe it's just a matter of where to draw the line. If some people
(such as you) prefer to draw the line much closer to Zope-the-
application, that's fine. I simply prefer to draw them closer to the
loosely coupled libraries and frameworks.
There's a reason for that. Zope-the-application is a big hindrance
for using standard Python technologies such as eggs, WSGI, etc. It's
not that eggs are going to solve world hunger (pun intended) and WSGI/
Paste isn't the end of the line when it comes to deployment, but
betting on those and actually working towards sharing even more
technology I think is the best thing we can do to grow Zope.
I gave a lightning talk about this subject at EuroPython. I got
several positive responses from Zope and non-Zoep folks, but the best
was probably by Jacob Hallen who, if he ever has used Zope, probably
wasn't a very enthusiastic Zope user. He said something along the
lines of this: "It's good to hear that Zope is starting to be usable
in bits and pieces, without having to buy into the whole Zope world."
Now, I bet there are lots of Python developers out there who like
Jacob have turned their back on Zope over the years exactly because
of this buy-in.
Zope 3 has now been successfully split up into separate pieces:
individual libraries. I'd therefore like to propose an alternate
approach to developing web applications with Zope: the library one,
rather than the pluggable app one.
I prefer the standard approach:
I see a framework -- Zope
and a large number of application components that plug themself
into the common framework.
The application, in fact a complete collection of mini-applications
is configured via objects in the ZODB and can be extended TTW.
Right. This is what Martijn Faassen aptly calls the "Zope 2000"
development model. And it's probably about the farthest away from
working together with other Python web frameworks and toning down
Zope for an easier entry.
I'm not going to try to convince anyone to give it up, but I probably
won't spend much energy in either promoting, maintaining and
documenting it.
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
