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

[Joseph Wayne Norton]

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



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

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.

  - CMF implemented the idea of a zope object having a "Type" and
    "meta-type".  How does this compare with Zope3?

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.

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.

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.

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

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.

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

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.

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.

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.

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

c. services and utilities

   - Likewise, I would be interested in seeing the current or expected
   list of standard services and utilites.

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?

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

   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.

   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.

   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.

   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.

f. last and not least ... a suggested patch for Step5 example product.


Index: ZopeComponentArchitecture/PythonProgrammerTutorial/Chapter1/Step5/ContactEditPresentation.py
===================================================================
RCS file: /cvs-repository/Docs/ZopeComponentArchitecture/PythonProgrammerTutorial/Chapter1/Step5/ContactEditPresentation.py,v
retrieving revision 1.4
diff -c -r1.4 ContactEditPresentation.py
*** ZopeComponentArchitecture/PythonProgrammerTutorial/Chapter1/Step5/ContactEditPresentation.py        3 Dec 2001 23:31:30 -0000       1.4
--- ZopeComponentArchitecture/PythonProgrammerTutorial/Chapter1/Step5/ContactEditPresentation.py        8 Dec 2001 13:16:10 -0000
***************
*** 23,26 ****
--- 23,27 ----
      def action(self, first, last, email, address, pc):
          "Edit a contact"
          self.getContext().update(first, last, email, address, pc)
+         # should set response.redirect to self.index().absolute_url() ?
          return self.index()
Index: ZopeComponentArchitecture/PythonProgrammerTutorial/Chapter1/Step5/edit.pt
===================================================================
RCS file: /cvs-repository/Docs/ZopeComponentArchitecture/PythonProgrammerTutorial/Chapter1/Step5/edit.pt,v
retrieving revision 1.3
diff -c -r1.3 edit.pt
*** ZopeComponentArchitecture/PythonProgrammerTutorial/Chapter1/Step5/edit.pt   3 Dec 2001 23:28:08 -0000       1.3
--- ZopeComponentArchitecture/PythonProgrammerTutorial/Chapter1/Step5/edit.pt   8 Dec 2001 13:16:10 -0000
***************
*** 3,9 ****
  <body>
  <div>
  Enter the information about the contact.
! <form action="action.html" method="post">
  <table cellspacing="0" cellpadding="2" border="0">
    <tr><td> First name</td>
        <td><input type="text" name="first" size="40" value=""
--- 3,9 ----
  <body>
  <div>
  Enter the information about the contact.
! <form action="action" method="post">
  <table cellspacing="0" cellpadding="2" border="0">
    <tr><td> First name</td>
        <td><input type="text" name="first" size="40" value=""