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

[Paul Everitt]

Jeffrey P Shell wrote:
> 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.

I think you're missing his point, that the *idea* is good, but tainted 
by the unexpected results and management headaches.

>> 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).

I'm very interested in providing something attractive to people like you.

> 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 worried about telling people like Jon, "You must become a Python 
programmer, it's for your own good."

If, ultimately, we can't create *the idea* of ZClasses, without the 
warts, then ok.  We'll just realize it is an impossible task.

We must admit, though, that we will lose a LOT, LOT of people like Jon, 
who aren't really that interested in learning Yet Another [programming 
language, component architecture, etc.]

>> 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.

That's his point!  He is hypothesizing that these problems can be fixed, 
and the original idea -- which he liked! -- can be retained.

> 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.

Yes, once you've decided to learn the number of new and deep concepts in 
Zope 3.  From my experience trying to write skins for Zope 3 (and I 
polled the UI people in Rotterdam, I think they agreed), you have to 
know a LOT in order to do hello world in Zope 3.

In fact, Martijn did a presentation on this.

> 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.

You're arguing the "it's good for you" point.  I think all would agree 
that your position is better for people.

You know what?  McDonalds is bad for people.  But lots more people eat 
at McDonalds than at the local granola store.

I liked the Word vs. Latex analogy made earlier in this thread.  People 
like us on zope3-dev will bash Word all day long.  And it still has 95% 
market share.

It's time for us to be a little less intellectually pure, a little more 
pragmatic, and a lot more successful.

>> 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.

Me too.  If it's technically impossible to fix the problems, then we 
declare it dead.  Until then, we know that the class of user under 
discussion found them appealing, so we should learn more about it.

> It's interesting, because a lot of programmers seem to hate ZClasses.  

But are those kinds of programmers the audience under discussion?

> I've been programming Zope since before it was even Principia, and I 

You are not the kind of actor that is under discussion.

> 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).

Nobody is arguing that point.  The real question is: does this actor 
care?  I don't think so.

If you have to learn a new programming language to do hello world, many 
probably won't.

>> 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.

We'll lose some number of people, if working with Zope requires a 
commitment to being a full Python programmer.

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

Agreed.

--Paul