[Zope3-dev] PythonProgrammerTutorial: questions, comments, and feedback
Joseph Wayne Norton
norton@alum.mit.edu
Sun, 09 Dec 2001 01:06:55 +0900
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=""