calling python from zope

[Duncan Booth]

spirou at carolo.net (Spirou) wrote in <8p48on$u17$1 at news.brutele.be>:

>As a Python programmer, one would like to use the "Products", I guess.
It depends on the complexity of what you want to do. If you just want to
do something that would be hard from DTML, such as a bit of text
reformatting, then an extension method may be simplest. 

>
>I played a bit with the Boring Product. Ok, I can (at least) do Python
>things there in.
>
>But how do I guess all those strange-named imports ? How do I find back
>my DB
>connections, my SQL Methods, Zope's objects, ... ? Is there at last some
>docs
>about all the black magic in Zope ?

There is some documentation on the Zope site, but not an awful lot once
you get into writing products. First, download lots of other products.
There is a pretty good chance anything you want to do has already been
done and you can copy the code. Also don't be afraid to grep the sources
of Zope itself. 

Second, try to understand at least the basics of acquisition. Your object
should support acquisition and persistence (so it can live in the object
store) as a minimum. Now you can get at any objects such as SQL methods
or DTML methods that are in the same folder as your new object, or
anywhere on the acquisition path simply by referring to self.theObject.

If you want to get at the REQUEST or RESPONSE objects the simplest way is
to declare parameters with exactly those names, and the objects will be
passed to you when your method is called via the web. 

Note that for most purposes you do not need to understand all of the
details of acquisition: I know this is true because I don't. 

Third, write absolutely everything you can get away with separately,
outside the Zope structure. Ideally the object defined in the Zope
Product should simply be a wrapper with the public interface to your
underlying object, and any data that needs to be persistent. Then you can
test the real code outside the Zope framework. 

Fourth: Persistence. Any time you re-assign to a member of your
persistent object, the changes are automatically saved to the Zope object
store. Members with names beginning '__v_' are not saved to the object
store and may therefore disappear at any time. Changing a mutable object
isn't enough, you also need to assign to the member at some point or the
change may be lost. Any sub-objects should either be persistent, or should be 
volatile '__v_' members.

Not everything needs to be persistent though. For example if you implement 
__getitem__ you can create and return subobjects which are not persistent, or 
which handle their own persistence.

It also helps to have a rough idea of the threading model that your
object will live in, although a lot of the time you can ignore it for all
practical purposes. In effect, if you create a persistent object, then
Zope might at some point create more than Python instance representing
the persistent object. Each instance will only be called by one thread at
a time, but if two threads both change their instances then one will be
saved to the object store and the changes in the other will be discarded.
The thread that had its changes discarded will then be called again. This
is all handled by the Zope's transaction model (so database changes also
roll back if there is a thread conflict), but if you were to write to a
file or make some other change outside Zope's control you may need to
hook into the transaction machinery yourself: for example queuing any
file writes until the transaction is committed.

There is also a useful base class Sync.Synchronized which will single thread 
all calls to an object: you can't use this on a persistent object, but it may 
be useful for those non-Zope objects with the real implementation (you still 
have to worry about transactions though).

>
>I know I should ask those kind of things on the Zope mailing-list, but
>there is such
>a traffic there ! (Does it tend to prove that there are lots of people
>using Zope and
>an average ratio of people having questions or not so much users, but a
>big part
>of them having lots of questions ?)
A lot of people with a lot of questions I think.

>Moreover, I would prefer a Pythonist's answer than a Zopist's one.
>
>Thanks if you could give the good pointers to start with (after the
>Boring Product).
>
If you get the structure right from the start 
(persistence+acquisition+transactions) then it should all fall into place and 
you will discover you have a very powerful environment. If you get it wrong it 
will be like climbing a mountain with your legs tied together.