[Zope3-dev] Zope3 comments and questions.

[Jim Fulton]

Lennart Regebro wrote:
> 
> This is the comments and questions I have after going through the
> PythonProgrammerTutorial/Chapter1. Excellent tutorial by the way, and Zope3
> looks and feels mostly excellent too!
> 
> 1. Zope.Products.foo.foo.foo = .foo
> Having "smarts" that remove an amount of typing can make things more
> confusing. Saying not having to specify Zope.Products is good, but not
> specifying repeating elements is a bit too much magic. A new user will have
> trouble understanding why ".Contact" works but ".People" doesn't, when they
> are both specified in the same module, or both modules in the same
> directory, since you mostly learn what to do and how to write things by
> mimicking others, instead of RTFT as you should.
> 
> "Smarts" should be rather obvious. Like that you don't have to care if a
> form used POST or GET. That a dot in the beginning may expand to three
> repeats is not that obvious.

I came up with this scheme based on feedback that it was too cumbersome
to do configuration and that this was exacerbated by long names.  I also
find the common repeats I encounter to be annoying, as I think
others do.

Also, In many cases, I, as a programmer really would like to hide
some of the internal package structure that the repeated names
expose.

How's this for a compromise and hopefully a clarification. We don't
repeat by default. If the name ends in a dot, we repeat the last name
as many tmes as we need until we find an object that isn't a module.
Then we'd have ".foo.". The dots on either end indicate that the name 
is being extended.

> 2. Clearer structure
> lib/python/Zope/Products is not the most place to put a product for
> newbies. It's no problem having products that are a part of the Zope
> distribution there, but new additional products, both downloaded and
> self-developed, should probably go into a Products folder in the root
> installation. That will make it MUCH easier for Zope newbies to
> understand whats going on.

I don't see how this really impacts understandability. Some general
comments:

- We want to get away from adding a lot of names to the Python path.
  This makes integration with other things harder. One way to avoid this
  would be to add a ZopeProducts, which is less likely to conflict with
  other modules.

- We probably will enourage people not to put custom products in the
  Zope software area. Of course, this is consistent with your suggestion. :)

- It really doesn't matter where people put their software as Zope will
  no longer automatically configure products (except for legacy products).
  Configuration is done by configuration file. Configuration files can point
  anywhere.  Of course, it does affect the meaning of the leading dot.

Let me think about this.


> 3. Protection of interfaces.
> I dont understand why extended interfaces can't be protected (step 4):
>   "Note that we protect the 'update' method by name, rather than by
>   interface. We can't protect the 'IContactEdit' interface because
>   'IContactEdit' extends 'IContactInfo', which is protected by a
>   different permission."

We can't use different protection for the extended interface and the
interface it extends as that would lead to inconsistent assertions.
IContactEdit includes all the methods of IContactInfo. If we say that 
IContactEdit is protected by ManageContacts, then we're saying that, 
for exampe, the email method is protected by ManageContacts, but
we also say that email is protected by View. We can't have it both ways.
 
> 4. Assertions in the interface definitions
> Why assert in the interface definition in the Tutorial? It's not intuitive
> to me. Shouldn't the class specify the interface it implements with
> __implements__ ?

It depends. If you don't have the ability to change the class, for example
if you got the class from someone else, then making the assertion in the
interface is better.
 
> 5. container vs here
> How come the edit presentation uses "container" where the view
> presentation uses "here"?

That's a bug. They should both use 'here'.
 
> 6. Marker interfaces
> Why create "marker interfaces?

Interfaces can be used for classification. A marker
interface classifies all the objects that implement it
together.

> Couldn't you just specify the class directly
> instead of creating and essentially empty and rather useless interface?

No, for two reasons:

- A class is not an interface. :)

- We might concievably want to mark multiple classes
  with the same marker interface. Marker interfaces keep
  that option open while allowing us to be more specific
  is we want to.

>   "The tabs are defined using a new 'IContact' interface, defined in
>   the 'IContact' module. This is a "marker" interface. It doesn't
>   actually specify any contacts but provides a way of very
>   specifically tagging certain classes (usually one).  We do this for
>   tabs because we usually want very specific control over the tabs
>   that a content object displays."

It might be cleaner if IContact extended all the other interfaces.
This is an area that probably needs more refinement.
 
> So, now I'm ready to start trying to make my first Zope3 product I guess.
> Any suggestions?
> I was thinking about redoing my EasyImage object, since I'm familiar with
> that code...

Cool. I suggest you wait a little longer, both to let us put some
more infrastructure in place and to let the dust settle from the many 
good suggestions.

Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org