[Zope3-dev] RFC: zopeproject

[Philipp von Weitershausen]

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.