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

[Shane Hathaway]

Jon Whitener wrote:
 > 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.

I think you misunderstand Python.  Python is easier to write than DTML. 
  You could be a "full-fledged Python programmer" before you know it. 
:-)  Python's ease has made Zope successful in spite of mistakes.

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

Here is a simple module.


class Document:

   def setText(self, text):
     self.text = text


There's really nothing more to it.  The setText method corresponds to a 
setText Python script.  The only thing you have to know that you didn't 
when using Python scripts is the "class" statement.  Modules can be even 
simpler than this.

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

I think that assumption is worth reconsidering.  The point and click UI 
of ZClasses only facilitates the creation of classes and methods.  It 
doesn't help create the body of the methods.  It's harder to write 
method bodies than to name methods.  So the ZClass UI tries to 
facilitate something that's not difficult in the first place.

Now, I could imagine a module wizard or even a TTW module editing 
interface.  It would not replace modules, but it would help you 
create/edit the text of a module.  It would provide nearly all of the 
features that the ZClass UI gives you today.  It might be a nice way to 
get started with Python.

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

You already have to be a Python programmer to create ZClasses--even if 
you only use DTML.  That hasn't changed.  The difference is that you 
have to know *less* when writing a module than when you write a ZClass. 
  Attributes are simpler than Zope properties, Python methods are 
simpler than Python scripts, security is configured in a simpler way, 
views are managed independently, and you don't need "product factories" 
and "permission" objects.

What was bad about writing a module for Zope 2 is the number of things 
you had to deal with in addition to methods and attributes: security, 
properties, templates, HTML responses, and a large base class hierarchy. 
  Zope 3 eliminates all of those things from ordinary Python modules, 
reducing modules back to the clean, simple things that Guido intended 
them to be.

Shane