Re[2]: [Zope] converting Python ap to Zope

Jerry McRae Jerry McRae <1jerry@usd1.com>
Mon, 3 Dec 2001 13:25:30 -0800


Hi Joachim,    -

Thanks for your response.  Apologize for the obtuseness.  I [attempt to]
clarify some of my questions herein.

re: what you <JW> wrote Jerry on Saturday, December 01, 2001 at 7:50 AM:

JW> If you configure your Zope right and actually make it use your standalone
JW> Python instead of its own one, all the stuff in your Python path is fully
JW> available. E.g., if you have installed PIL (Python Imaging Library), it is
JW> available from your Zope Products via "import PIL" as usual.

I must have thought that would mess with Zope.  Works fine to replace
the path to Zope's Python with just 'python' in the START.BAT.  I do get
an error when Zope starts now (my localhost version in win98):

2001-12-03T19:24:47 PROBLEM(100) Init Ambiguous name for method of Products.Site
Access.SiteRoot.SiteRoot: "manage" != "manage_main"

I was not getting this when I used the python from the zope directories.
I have the SiteAccess Product installed, but cannot find any SiteRoot or
VHM objects used anywhere.
Question 1: is this important?  What do I do about it?
--
JW> This irritates me most. If you have the ZODB, why would you want to do
JW> pickling on your own? I guess some refactoring of the code and doing it the
JW> Zope way would help a lot here. Even if you used Python standalone, using
JW> the ZODB as a storage would be much more comfortable than pickling to files.

I *don't* want to pickle on my own.  That is just the way the
application is currently saving the tables.  I would like to un-pickle
the existing files using the modified ZODB persistent classes but since
pickle loads the classes from the original modules, I don't see how this
is possible.  (Q2: is it?)  I suppose I could write a conversion program
copies each class (and attributes) and data structure manually over to a
Zope instance.

JW> Basically, to move from a "normal" class to a persistent class, you'd just
JW> have to import a few base classes (mainly "Persistent"). You won't have to
JW> convert the data structures. Just rewrite the code a bit. Look at
JW> http://www.zope.org/Documentation/ZDG/Persistence.stx for the details, if
JW> you haven't already.

I have read that chapter.  Part of the problem is that I have read
*everything* I could find, and I think my brain is full. ;) I will write
wrapper classes for ZODB with the same names, so that I can use the same
code, and see if that will work for me.

JW> Why would you want to pickle a .DLL file? Or did I get that wrong? Your
JW> problem sounds a bit as if you wanted to store a full version of Word 2000
JW> with every .doc file you create because you might need it the next time you
JW> work with the document. But maybe I just don't get the point ...

I don't want to pickle the .dll.  I just want to be able to call the
.dll from anywhere in Zope.  I was thinking something like the following
(invalid) code in my __init__ for the Product:

import Mk4py
root['mk'] = Mk4py

So all methods could access code like "mk.open(...)" using the same
object.  I might be thinking down the wrong path.  (I have been know to
do that on occasion).

My app requires speed and flexibility. 20-200k records. add/remove
fields quickly on request. some fields need to be nested and/or
multi-valued. Chose MetaKit. MetaKit requires only one .dll to operate.
I need two things I have yet done successfully: 1) load a class or
function into Zope that imports this dll that I can call (Q3), and 2)
once an object is set up, I need the file pointers not pickled (using
_v_ attributes I guess), *and* the files & tables pointers re-opened if
Zope re-starts, so the user doesn't have to do it manually (Q3).

please lead me to [in]sight!

-- 
 /\_/\    Jerry McRae       \|||/       mail safely: The Bat! 1.53d
(~o o~)  (stuck in win98)   (. .)       Zope v2.4.1  - dryer than golf
 )'Y'(   _______________-o00-(_)-00o-____________________________________
(     ) / I used to be undecided, now I'm not sure!

========== your original message below ==========
From: Joachim Werner
To:   Jerry McRae
on:   7:50:20 AM
re:   [Zope] converting Python ap to Zope

wise words from Joachim:

JW> Hi!

JW> I am a bit confused by your problems. Let's see what I can comment on ...

>> I have tried loading the whole app as an external method, which didn't
>> work, but I learned to make a copy of ALL modules and place them in a
>> Zope sub-folder.  The python path from my stand-alone python 2.1 didn't
>> get searched.

JW> I'd definitely go with a Zope Product, not an External Method ...

JW> If you configure your Zope right and actually make it use your standalone
JW> Python instead of its own one, all the stuff in your Python path is fully
JW> available. E.g., if you have installed PIL (Python Imaging Library), it is
JW> available from your Zope Products via "import PIL" as usual.

>> 1) There are a lot of classes and tables.  Each user can create multiple
>> sets of the application classes and tables.  Each set of instances and
>> attributes is pickled as a file.  The application is basically just a
>> wrapper for the pickled instances.  I can think of no way to convert the
>> pickle file into classes and attributes that Zope can see and/or modify.
>> It seems I will have to re-factor each and every python class as a Zope
>> class.

JW> This irritates me most. If you have the ZODB, why would you want to do
JW> pickling on your own? I guess some refactoring of the code and doing it the
JW> Zope way would help a lot here. Even if you used Python standalone, using
JW> the ZODB as a storage would be much more comfortable than pickling to files.

JW> Basically, to move from a "normal" class to a persistent class, you'd just
JW> have to import a few base classes (mainly "Persistent"). You won't have to
JW> convert the data structures. Just rewrite the code a bit. Look at
JW> http://www.zope.org/Documentation/ZDG/Persistence.stx for the details, if
JW> you haven't already.

JW> Another question: Are you talking about pickling instances of classes (which
JW> is trivial in Zope) or classes themselves (which is currently impossible)?
JW> In Zope, classes (except for ZClasses) are filesystem-based code, and
JW> instances are in the ZODB (though instances are classes, too, if we want to
JW> be syntactically correct).

>> 2) several specialized data files are involved, which are opened and
>> positioned based on the classes and parameters.  The files are needed
>> for all aspects of the application.  Since Zope cannot pickle open file
>> handles, I could store file names, positions, and other attributes, but
>> I don't know how to re-open the files any time Zope restarts so that the
>> user just references my object name (and methods) to access the data.



>> 3) the key to accessing these specialized files is a windows .DLL file
>> that works great in Python, but is unpickleable (is that a word?) in
>> Zope.  I think I want to create a function that gets loaded when the
>> Product does, but I cannot find any examples of Products that do this:
>> allow instanciated objects to call custom functions created from
JW> __init__.py in
>> a Product.  There must be someplace to add globally available functions
>> to Zope outside of ZODB, yes?

JW> ALL the functions and methods defined in filesystem-based class definitions
JW> are outside the ZODB. Let's take an example: If you have a user folder
JW> implementation in Zope, the ZODB will only store the user info. All the
JW> actual code, like the password validation, encryption etc. is outside the
JW> ZODB of course.

JW> Why would you want to pickle a .DLL file? Or did I get that wrong? Your
JW> problem sounds a bit as if you wanted to store a full version of Word 2000
JW> with every .doc file you create because you might need it the next time you
JW> work with the document. But maybe I just don't get the point ...

JW> Make sure that you really understand the concept of Persistence before you
JW> go on. It is mainly about programming code as if it was running forever
JW> (i.e. stateful), but actually Zope can store the state between the
JW> (stateless) web requests.

JW> Cheers

JW> Joachim