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