[Zope3-dev] IMPORTANT RFS: Through the Web Site Development

[Jeffrey P Shell]

On Monday, January 13, 2003, at 02:49  PM, Jon Whitener wrote:

> Jim:
>
> Your responses seem to describe a Zope 3 world where either users 
> restrict themselves to content-space scripts and pages, or they are 
> full-fledged Python programmers who can hack out a module for every 
> purpose.  I think this neglects a large audience of Zope users, and 
> further, ignores one of Zope's most attractive features.

But it's also one of its most hated features.  A lot of people will 
avoid ZClasses and any product built with them because of the 
configuration management headaches and unexpected results.

> Joachim Werner nailed it directly on the head when he said:
>
>> If there are TTW ways of writing or adapting custom (real) Python 
>> classes,
>> nobody will miss ZClasses.
>
> Forgive me my ignorance: despite working in Zope nearly full-time for 
> several months now, I have never created a full Python module, let 
> alone a Zope persistent Python module.  I don't even know what they 
> look like (I've written a handful of Script (Python)s).

This is because such work has been rather hard for many people to get 
their heads around until now.  But there are many many many many many 
Python books out there.  It's easier to explain how inheritance in 
Python works, how to use elements of your superclass(es), etc, in 
Python than it is in ZClasses.

> I'm going ahead, however, and assuming that (for any 
> non-Python-programmer) a Python module is less easy to create than 
> that point-and-click thing everyone wishes worked better, the ZClass.

It's less easy to create because it requires file system access and 
deep knowledge of how product initialization works.  Also, ZClasses 
have helper functions to automatically build forms that Zope 2 
"products" lack.  So with ZClasses, most of the time people just define 
a schema and generate a form that automatically saves the values.  
Beyond that, however, their usage starts to get tricky, and I never 
know what to expect the moment I really try to make them do anything 
further.

Zope 3 already has some similar functionality with the ability to 
generate an editform off of Schema objects defined in an interface.  
I'd like to see that reused in such a way that defining a schema 
through the web and seeing the Python code that it either creates or 
impacts is not too different.  This is why modules are important - the 
ability to grow from defining a schema through a point and click 
interface to being able to write one by hand should be easy.  Already 
in Zope 3, the Schema stuff and writing code to handle it is soooo much 
easier (and generally more pythonic) than it is in Zope 2.  There are 
no weird methods like "manage_updateProperties()".

Don't confuse the oddities of Zope 2 with the behaviors of Zope 3.  
It's already much easier to write clear and readable Python modules for 
Zope 3 than it has ever been since the days of Bobo.

So we can continue to try to make something weird and different that we 
then have to explain to people, or we can use means of development that 
are already well documented and teachable like basic Python programming 
and say "if you read through the Python tutorial, you'll be able to 
write custom components for Zope in no time" and by no time, really 
mean it.


> Dider Georgieff makes a strong point I wish to second:
>> I've used ZClasses with great success in this area (popoto), and now
>> that the new developments (CPS) are done (by a Zope company) in the
>> "right" way (python products, fs,...) i loose some great advantages i
>> had.
>>
>> Having best of both words in Z3 will make my IT manager day without 
>> any
>> doubt, and bring me back in control.
>
> I propose that the exciting and compelling *idea* of ZClasses should 
> be revisited and reimplemented in a way that allows Zope users to 
> create Python modules with the ease and speed of current ZClasses.

It's interesting, because a lot of programmers seem to hate ZClasses.  
I've been programming Zope since before it was even Principia, and I 
still can't make ZClasses work for me.  Compare that with Python 
itself, which is a language where you can program small and fast (even 
as small and fast as firing up the Python interpreter to do simple 
arithmetic), or large and complex as you want (as is evidenced by the 
source code of Zope 3, or other Python systems like docutils).

> If I understand correctly, persistent modules would replace ZClasses, 
> but you need to be a Python programmer to create them.  ZClasses are 
> easy and fast to create even for the beginner, and allow people to 
> simply create Zope objects that model their business realities, but 
> are buggy and fragile.

There's nothing wrong with having to be a Python programmer to make 
stuff for Zope, any more than there's anything wrong with being a 
Visual Basic programmer to do most ASP work.  We should just ensure 
that we don't make the leap from simple schema definitions (object 
modeling) to Python so large that people fear it.  This is especially 
true with Zope 2, because it's not only a large leap to Python, but a 
large leap to the Zope 2 API's and inheritance model.  You can be 
extremely confident in Python but still have it take a long time to 
grok how to write a usable content object for Zope.  I wager even the 
Python Labs crew can testify to that.

When you do know the Zope 2 API's, you can do a lot of powerful things. 
  But the road there is steep.

> Is there no middle-ground, or hybrid, between these two things?