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

[Paul Everitt]

Joseph Wayne Norton wrote:

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


I'm sure _we'd_ like to see that tutorial as well. :^)  Seriously, this 
area is ripe for more investigation, particularly by those in Zopeland 
that have been working on object-relational integration/mapping.

FWIW, Jim bought a WebObjects book a couple of days ago.  I'll leave the 
interpretation of this event to the reader.


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


Yes yes yes gimme gimme gimme.


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


Boy, these are good questions.


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


To be devil's advocate, why not continue to be more Pythonic and just 
use PYTHONPATH?  That is, the only relevant difference between a Python 
package and a Zope package would be the presence of a Zope configuration 
file.  (There might be other differences, such as presence of DTML 
templates, but these wouldn't be considered significant.)


[snip]


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


Agreed.


[big snip]


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

This is an intriguing idea.  I also wonder if there is any cross-over 
effect with versioning.  For instance, here's a pattern that the CMF, 
even with DCWorkflow, can't do without versioning:

   o Author creates document

   o Author requests publishing

   o Reviewer publishes

   o Author edits document and adds foul language

Since there is only one document, it is either published or not.  There 
is a workflow and security relationship to which version of a resource 
you're talking about.

I have no proposals on how to represent this without an NxNxN situation.

--Paul