August 2001 - Zope-Dev

Re: [ZODB-Dev] More CVS shifting
by Ken Manheimer 02 Aug '01

02 Aug '01

This is a followup on a message i originally posted to zope-announce and zodb-dev. I'm transferring the discussion to zope-dev and zodb-dev, since zope-announce is not for discussion, and i expect there are many repository users who subscribe to one of zodb-dev or zope-dev but not both. On Thu, 2 Aug 2001, Jim Fulton wrote: > > new scheme, it will mean having to once again do new checkouts - old > > checkouts will not update. > > Old checkouts will certainly update, but they won't reflect module > changes, because modules *only* affect checkouts. Yes - that's what i meant to say. > > - Modules enable a bit more recipe reuse. For instance, if you > > wanted two different versions of Zope, one with CMF included and > > one without, you could reuse a core Zope module in a ZopePlusCMF > > module. We will be able to compensate, perhaps better, with > > distribution front-ends. > > Please elaborate how symlinks hinder this. If we need distribution > front ends, then we might as well provide distribution front ends to > overcome the module problem. Someone else asked this question in a private conversation, and i came to realize this is an important issue, which i addressed in some detail: First off, i may have been unclear. Symlinks should enable the fundamental goal where you're able to project various elements from the repository into other directories. I know i've used them for this before, just want to verify my recollection and check the edges, as i describe above. There's a limit to how far we can go with this, relative to modules, without some elaboration. It has to do with reusing directories that are populated using symlinks. Using symlinks, the directories getting shared elements actually contain the links to the elements, so in the simplest approach they must have the same populations in any recipe where they're used. (I think we can address that with another layer of indirection using relative symlinks - see below.) The module scheme directly offers some more freedom, here - the weaving is a virtual thing, so that directories populated using modules can be populated differently in different recipes. For example: In the current setup, the Zope-specific parts of the Zope module are woven in from Releases/Zope - i'd call this the skeleton. Various products and packages are projected into that skeleton with further module elaboration. It could be that we'd have a ZopePlusCMF module that wove in the Zope module and then additionally projected the CMF products. With the symlink scheme we would have to have a separate skeleton. In describing the situation i came to realize that we can use relative symlinks to achieve this kind of reuse, with a bit of elaboration: The idea is to have relative-link stubs in the skeletons, which indirect to directories that vary across recipes. For example, the Zope skeleton would have a link for lib/python/Products that points to ../../Products. Then, a few Zope variants would look like so:: Zope/ ==> link to Zope skeleton Products/ ... various products specific to the plain Zope packaging ZopeWithCMF/ ==> link to Zope skeleton Products/ ... various products specific to the Zope + CMF packaging In both cases, the Products link in the Zope skeleton would indirect to the recipe-specific Products dir. Viola. By "distribution front-end" i was (lazily and hazily) referring to some kind of installation mechanism by which people would select the overlays they want to add to their base-line installation - eg, they'd checkout Zope and then checkout the CMF package, in the right place. I'm not sure which of these two approaches is more suitable for which occasions, but i think between them they should be sufficient to our purposes. I can't tell how difficult it is to track my descriptions here - let me know if i can clarify, and if you see pitfalls. Ken klm(a)zope.com

1 0

Fwd: Re: Probs installing Parsed XML
by m.knobloch＠iwm-kmrc.de 02 Aug '01

02 Aug '01

Hello, after unpacking and installing ParsedXML b1 on SuSe Linux / Zope 2.4 / Python 2.1 i get a warning message during restart of ZOPE Init Ambiguous name for method of products.ParsedXML.ManageableDOM.DOMManageable manage_main != manage_DOMTree. It is possible to import XML-Dokuments but the Tree-View or edit crashes. What did i do wrong? Or ist there a workaround? tia from Knobi Manfred Knobloch Institut für Wissensmedien IWM Universität Tübingen Abteilung Medientechnik Konrad Adenauer Str. 40 D-72072 Tübingen -- Karl Anderson kra(a)monkey.org http://www.monkey.org/~kra/

1 0

RE: are print statements in zdaemon.py wise?
by Chris Keyes 02 Aug '01

02 Aug '01

Should have said that it is Zope 2.4.0 :-( oops Sorry Chris K

1 0

Announce: Medusa Status HowTo
by Mario Valente 02 Aug '01

02 Aug '01

Hi For all interested I've put up a Medusa Status HowTo at http://www.zope.org/Members/mvalente/medusastatus It tells you how to make your ZServer display a Medusa status screen to help with debugging. C U! -- Mario Valente

1 0

Cut/Copy/Paste objects programatically between folders
by vmilitaru＠sympatico.ca 01 Aug '01

01 Aug '01

Hi, Could someone give me a hint or "recipe" (better!) on how to use manage_cutObjects() and such. I am developing a Product which uses the Joust package for UI: I want my Product code to add/edit/move/delete objects programmatically inside the object hierarchy (inside the Joust folder). Is there an easier way than to use Zope's routines? For example, I managed to import some pre-cooked package using Zope's manage_importObject(): --------------- from OFS.ObjectManager import ObjectManager manage_addBarForm = PageTemplateFile("www/Bar_add", globals()) def manage_addBar(self, id, title, REQUEST=None): "Create a Bar folder and add it to its parent's folder." catalogus = Bar(id, title) self._setObject(id,catalogus) base_folder = getattr(self, id) # import entire 'images/' folder in one sweep base_folder.manage_importObject('images.zexp') ------------------ This is very practical: I can edit my objects using the ZMI, then make my Product import everything in one sweep. Also, if I want to add individual objects, I do: ------------------ from my_objects import * base_folder._setObject('SomeObject', DTMLDocument(SomeObject, __name__='SomeObject')) # created an Object inside my base folder or base_folder._setObject('images2', MyFolder(id, title)) # # created a folder inside my base folder then images_folder = getattr(base_folder, 'images2') images_folder._setObject('JPGs', MyFolder(id, title)) # this creates a folder inside a folder inside a folder, a.k.a a hierarchy. ----------------- But now I want to cut/copy/paste/delete objects between my different folders. My guess is that I need to import CopyContainer: ------------------- from OFS.CopySupport import CopyContainer ------------------- But then what? How do I use manage_cutObjects() for example? Let's say, using the previous example, that I want to cut&paste 'SomeObject' from 'base_folder' and paste it into the 'JPGs' folder. Regards - Vio

2 1