[Zope3-dev] Re: PythonProgrammerTutorial: questions, comments, and feedback

[Jim Fulton]

Joseph Wayne Norton wrote:
> 
> Jim et al -
> 
> I had a chance to read through the tutorial and to obtain some
> understanding on the direction of Zope3.  The tutorial was very useful
> and from what I can understand so far I **like** the direction taken
> for the component architecture.

Great.

> I have compiled all of my comments and
> questions.  I would appreciate any comments or feedback that you might
> have.
> 
> regards,
> 
> - joe n.
> 
> p.s I can also send a patch for some cosmetic stuff like mispellings,
> typos, etc. if you want.  I'm just not sure if it would consider it
> to be "noise".

Things are still somewhat in flux, especially wrt naming, wording, etc.

> Step 1
> ------
> 
> a. "If instances weren't going to be stored in the Zope, we would not
> need to mix in 'Persistent'."
> 
>   - I'm sure it is not a trivial example, but I would be interested in
>     seeing the same tutorial (or portions of it) where a different
>     mechanism is used for storage ... such as an relational db (or
>     directly in a berkeley db).

Yup, however, this will come much later, just due to limited
resources.
 
> b. "Additional attributes can be used to provide additional meta data,
> however, the meta-data is infered from class meta-data."
> 
>   - It would be useful to have a specification of the standard zope3
>     meta-data.

Yup.  This will come. Suggestions are welcomed.
 
>   - CMF implemented the idea of a zope object having a "Type" and
>     "meta-type".  How does this compare with Zope3?

I'm gonna let Tres or Shane answer this one. :)
 
> c. "The configuration file must be copied (or linked) to a Zope
> 'Products" package directory ..."
> 
>   - In a manner similiar to python's environment PYTHONPATH, it would
>     be useful to have a ZPRODUCTPATH that can be searched for
>     configuration files.

Actually, this has already changed. The site manage will need to use
an 'include' in the site configuration files to reference the product
configuration. Someone may provide a tool to automate that.

 
> d. "The first argument passed to 'createObject' affects where
> 'createObject' searches for factories."
> 
>   - Please explain further the meaning of 'affects' or the search
>     rules.  I looked at the current source, but the ob parameter is
>     currently not used.

This relates somewhat to the note I just sent to Chris.

Component look ups are placeful. 

Imagine that I have a folder hierarchy with a folder /f1/f2/f3.
Suppose that the root folder  and /f1/f2 have service managers with 
factory services.  If you call createObject with /f1/f2/f3, then
a matching factory will be looked for in the factory service in /f1/f2, 
in the root folder, and in the global registry (the only one we've implemented
so far :), in that order.
 
> Step 2
> ------
> 
> a. entire last paragraph - "In this example, the view template was put
> in folder containing the content .... Mixing software and content in
> the same place makes managing both more difficult. ..."
> 
>   - I'm not quite sure about the conclusion of this paragraph.  I'm
>   also not quite sure if you mean "folder" to be a zope folder or
>   the file-system based "directory" in which you have built the product.

Mixing content and software tends to clutter things up. Content managers
shouldn't see software, which is why the CMF provides it's own folder
listing. Programmers don't like hunting through software to find their content.
This is, to some degree, a matter of taste.

I was talking about Zope folders.
 
>   - You infer that mixing both content and presentation is not a good
>   thing ... I think you mean in terms of having separate python
>   classes (or objects) for content and presentation.  I would have
>   also expected that the file-system Product "directory" be also
>   partitioned in some way to cleanly separate the "content object", the
>   "interfaces", and the "presentation objects".  This might simply be
>   a product-packaging/distribution (or personal style) issue where one
>   has separate directories for the respective items.

I was talking about object instances, not classes.
 
> Step 3
> ------
> 
> a. I'm not sure if I am doing something incorrect or not, but I cannot
> view a Contact instance using the following urls:
> 
>    ..../aContact/view/
> 
>       OR
> 
>    ..../aContact
> 
> The best hint for me to realize how to view a contact after I added
> one was to look at the examples included in the functional_tests/*
> directory of the Zope3 cvs checkout.  You might want to include a
> pointer to this in the tutorial.

The current implementation makes you always use a semicolon:

    ..../aContact/view;view/


Also note that only step 5 even sort of works at this point.
 
> Step 4
> ------
> 
> a. "One could conceivably create a component that is applicable to
> several alternative interfaces, in which case, the '__applicable__'
> attribute would not be set."

This was renamed to __used_for__.
 
>    - This last sentence was not clear to me.  Probably, you have
>    further information or know more about this particular attribute. I
>    sorted of cheated by reading all of the READMEs and then only looking
>    at the sample product in Step 5.  I think a list of all of the
>    "__**__" attributes with a brief description might help me better
>    (or maybe I will spend a little time digging in the code to see how
>    this attribute is used).

When things form up a little more we should spend a lot more time on documentaion.
As it is, it's hard to keep the existing documentation consistent with the
changes.
 
> b. "This is a "marker" interface."
> 
>    - I simply do not have a good feeling of the pros and cons of
>      having and not having a "marker" interface.  A little more explanation
>      of why this is a good thing (or necessary) would be useful.

OK.
 
> Step 5
> ------
> 
> a. "utility" and "feature" components
> 
>     - I realize the usage is implied but none of the presentation views
>       included in the example product actually use the "utility" or
>       "feature" component described in Step 5.

Yup. This would be a good enhanement.
 
> Other Comments
> --------------
> 
> a. ContactEditPresentation.py - __init__ and getContext methods
> 
>    - I'm just curious why these 2 methods are not defined in the
>      AttributePublisher class (or another class is created in the
>      Zope.Publisher.Browser.AttributePublisher file).  My guess is that
>      these "boiler plate" items often change or are are easily
>      misunderstood.

I'm sure that they will eventually be rolled up into a mix-in class.
I just thought it would be clearer to include them in the final class
for now.

> b. zmi:tabs
> 
>    - I would be interested in seeing the current or expected list of
>    standard actions available for the zmi:tabs
>    (edit,view,security,undo,etc.)

Well, he current ZMI should give you an idea.
 
> c. services and utilities
> 
>    - Likewise, I would be interested in seeing the current or expected
>    list of standard services and utilites.

There probably won't be many "standard features". Standard utilities are
generally called "services". :)
 
> d. security:protectClass and security:publicClass and security:definePermision
> 
>    - Maybe a name is just a name, but "public" is the only one that is
>      not a verb.  If "publicClass" was a verb, what would you use?

Dunno, suggestions welcome.
 
> e. security model, definition, ...
> 
>    - This is probably my biggest area of confusion at the moment and
>    I'm not able to fully explain myself at the moment ... but I will
>    try my best.  Definitely, the security aspects of zope is one of
>    its biggest strengths.  However, it can also easily be a weakness
>    if it is not used appropriately or understood clearly.
> 
>    I understand all of the assertions made in the Contact.zcml file
>    but I'm trying to grasp for a better way to accomplish the same
>    task.  I really like the interface stuff and the
>    feature/utility/service model but the security stuff smells like
>    "Zope2".

Hm, while Zope2's security model could be improved, I'm not 
unhappy with it in any fundamental way. BTW, I'm going to provide 
a fairly detailed discussion on new security interfaces and
ideas later today.

>    1. In a manner similiar to the "Interfaces" model ... wouldn't it be
>    possible (or better) to provide for a security interface mechanism
>    as well?  This would allow one to define a security interface
>    contract so-to-speak (with a possible implementation) and then
>    re-use/reference this interface with different objects.

I don't know what you mean. Could you be more specific.
 
>    2. In the CMF implementation, many different content objects shared
>    the same security model (and security permissions).  It would be
>    nice to be able to express this easily but make changes were
>    necessary or needed:
> 
>      - content objects having the same security model ... no
>        differences.
> 
>      - content objects having the same security model but with
>        different "add" permissions.
> 
>      - content objects having the same security model but the "names"
>        of each permission are unique to each content object.
> 
>      - content objects sharing only the same "zmi:management" security
>      model.
> 
>      - etc., etc.

I think that the separation of permission definitions from
software will give you the flexability to create the permission set
that's right for you. There will need to be some additional
minor refinements in the configuration language to support this.

>    3. It is convienent to directly use the string "permission" name
>    for ease of use, but mistakes can be easily made.  Maybe it is
>    better to have one location/file (or consistent location) where all
>    security permissions are defined (and categorized) then simply
>    imported via python to help eliminiate mispellings, permission name
>    changes, etc.

The configuration mechanism will address this. A permission will have
to be defined before it is used. Stay tuned.
 
>    4. I really wish the CMF DCWorkflow functionality was built-in to
>    zope's security mechanism.  The whole CMF concept of
>    published,private,show,hide etc. would be much more powerful if it
>    could be applied in a manner similiar to zope's security model.
>    For example, the "acquire permission settings" button would equally
>    apply if one had a "acquire publication settings" button.  Anyway,
>    this is just an idea.

I agree that there should be a closer connection between the security
model and the workflow model. FWIW, I published a paper at a conference
earlier this year that provided an overview of Zope's security model
and included workflow as "dynamic security".
 
> f. last and not least ... a suggested patch for Step5 example product.

Thanks. I'll look at this when I get a chance.

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