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

Reply via email to