August 2002 - Zope-Dev

WebDAV access for DTML Methods and Documents
by brian.r.brinegar.1 15 Aug '02

15 Aug '02

Hello, This may be something that cannot easily be fixed, but the permission "FTP Access" is required for a user to have "WebDAV Access" to an object. Since the method is shared by FTP and WebDAV a more general permission name should be used. Thanks, -Brian

1 0

Shared lexicons for ZCTextIndex (was: Re: [Zope-Checkins] CVS: Zope/lib/python/Products/ZCTextIndex - ZCTextIndex.py:1.32)
by Casey Duncan 15 Aug '02

15 Aug '02

On Wednesday 14 August 2002 06:03 pm, Guido van Rossum wrote: > > Fix for issue #505 > > ZCTextIndex is now associated by path to its lexicon. After replacing a lexicon used by an index, clear the index to make it use the new lexicon. > > So the semantics are that when you replace the lexicon, the index is > reset to empty, right? Why not create a new index instead? Then the > lexicon could be internal to the index. Sharing lexicons doesn't > sound like a probable use case, the more I think about it. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > I don't disagree. This was a conceptual holdover from the previous generation TextIndex. I'm switching this over to zope-dev for wider discussion: The current implementation of ZCTextIndex is like the old TextIndex in that you can create one Lexicon (the sucessor to Vocabularies) shared by multiple ZCTextIndexes. I imagine the thought was that there are only a finite number of words and that sharing the lexicon would save space and possibly index time, since a given word would only need to be inserted once into the lexicon regardless of the number of indexes it occurred in. More significant might be the (cache) memory savings of only having to keep one copy of the words in memory across several indexes. Plus fewer loads and stores to the database overall by sharing the word list. On the other hand I think query speeds may be compromised since one large lexicon would take longer to search for a given word (or words) then several smaller ones. This would be especially true for small indexes sharing a lexicon with a much larger one. The other downside (as illustrated by issue #505) is the complication of linking index to lexicon and making the link manageable so that you can tweak the indexing system easily. My fix is not entirely complete because a hard ref to the lexicon is still stored in the low-level index (to which the ZCTextIndex class delegates). In order to fix this effectively without introducing Zope dependancies at the low level (which we have looked to avoid) I would need to create some sort of Lexicon proxy that can access the correct lexicon on demand by a path efficiently. This proxy would be referenced by the low level index in place of the actual lexicon. Of course the other solution, which is much simpler is to dispense with this notion of sharing lexicons entirely and as Guido suggests, just make the lexicon part of the index. Without hard use cases to the contrary, I lean toward that simpler design. However I would like to perform some additional testing on large corpuses with many indexes to assess the memory/performance differences between these two approaches. We have already ascertained that with the new ZODB cache code in 2.6, the cache setting can have a profound affect on query performance (like a factor of 10), so I think testing would be helpful. Anyone care to weigh in with use cases for shared lexicons? -Casey

4 6

OT: folding editors
by Jean Jordaan 15 Aug '02

15 Aug '02

> > # {{{ ... #}}} crutches ;^) > > I use a folding editor (jed) and these are the folding marks. Use Vim, it folds based on indentation (or anything else you care to teach it)! ;> -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za

2 1

PythonWin/Textpad, external import of Zope module and Persistence
by Johan Carlsson [Torped] 15 Aug '02

15 Aug '02

Hi, I'm trying to setup to run with either TextPad, which can run external program like python scripts and then parse the result and making Traceback lines linked to the line/file where the error occurred. Or try using Python which has an build in debugger which I like to be able to use. The first problem I encounter in both scenarios is that when a file "import Globals" which in its turn "from Persistence import Persistent", this fails. Mostly because Persistence is "hot patched" by ZODB. Is there any smart way to setup a "virtual Zope" environment without importing Zope (which mounts the Data.fs) or by importing Zope by in a light way without mounting a storage or just mounting a lights storage. The only thing I want to do in this first phase is to be able to make syntax/sanity checks. Regards, Johan Carlsson -- Torped Strategi och Kommunikation AB Johan Carlsson johanc(a)torped.se Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Visit: Västmannagatan 67, Stockholm, Sweden Phone +46-(0)8-32 31 23 Fax +46-(0)8-32 31 83 Mobil +46-(0)70-558 25 24 http://www.torped.se http://www.easypublisher.com

3 3

Re: [Zope-dev] to __of__ or not to __of__ ?
by Johan Carlsson [Torped] 15 Aug '02

15 Aug '02

>At 23:38 2002-08-14 -0400, Casey Duncan said: >>The Item class mixes in Traversable, which is probably responsible for >>making >>this work TTW. It also gives you a bunch of other stuff that many Zope >>classes need, like DAV support, copy support, ZMI tab support and security. >>It doen't mix-in acquisition tho. >> >>If you need support for acquistion machinery (including __of__ which creates >>wrappers), then you need to mix-in Acquisition.Implicit. The SimpleItem >>class >>mixes this and Persistence in for you (along with Item), so many Zope >>classes >>derive form SimpleItem. You need Persistence to store instances of your >>class >>in the ZODB, and implicit acquisition is the standard for Zope objects. >> >>In short I would recommend mixing in SimpleItem or you may find that your >>objects are not stored properly in the ZODB. >> >>-Casey You also might want to wrap the object before returning them, because the are stored in _item and not in the AixtraTableProduct. def getItem(self,key): #{{{ "returns item" data = self._items if data.has_key(key): item = self._items[key] if not hasattr(item,'key'): setattr(item,'key',key) return item.__of__(self) <--- wrap the item before returned Regards, Johan Carlsson -- Torped Strategi och Kommunikation AB Johan Carlsson johanc(a)torped.se Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Visit: Västmannagatan 67, Stockholm, Sweden Phone +46-(0)8-32 31 23 Fax +46-(0)8-32 31 83 Mobil +46-(0)70-558 25 24 http://www.torped.se http://www.easypublisher.com

1 0

to __of__ or not to __of__ ?
by Joachim Schmitz 15 Aug '02

15 Aug '02

Hi, in my AixtraTable product the newItem method is defined like this: def newItem(self,key): #{{{ "returns item" data = self._items if data.has_key(key): return None else: item = makeItem(key,self.FieldList) data[key] = item self.catalog_object(item) return data[key] #}}} where self._items is: self._items = OOBTree() and the makeItem-Class is: class makeItem(Item): #{{{ """ AixtraTable Item class """ def __init__(self, key, fieldlist): self.id = key for f in fieldlist: setattr(self,f,"") #}}} it only worked, when I inherited from Item, otherwise I could not access the items from the web, my guess is, cause they had no acquisition wrappers. Can I achieve the same with the __of__ magic and how ? you can download the product from http://www.zope.org/Members/perry/AixtraTable Mit freundlichen Grüßen Joachim Schmitz -------------------------------------------------------------------- AixtraWare Ingenieurbüro für Internetanwendungen Hüsgenstr. 33a, D-52457 Aldenhoven Telefon: +49-2464-8851, FAX: +49-2464-905163 -------------------------------------------------------------------- Key fingerprint = DA10 CC82 62F8 1DBB 39A1 1EDC 725B 3317 A8D7 C3A6 Keyserver: http://www.keyserver.net/en/

2 2

Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches
by Adrian Hungate 14 Aug '02

14 Aug '02

Hmm... that is not good. I can't see you getting an API to change a DTML file. The only option would be to create the ObjectManager's contents page from python, and people seem not to like doing that, but it would allow a little more engineering to take place. Hmmm... It looks as though what is needed is fish-bowl proposal to redesign the way ObjectManager handles and displays rows for specific object types - the requirement being that this be third-party-pluggable (For want of a better term). (No that was not me volunteering - too much on at the moment, sorry). One question about zshell though, what is the box that is added "left of the add product pulldown"? Is it something that ABSOLUTELY has to be on the contents listing (i.e. something to do with creating or maintaining the objects listed?). Could it be backdoor'd into all_meta_types so that it, itself is listed in the pulldown, or could it have a ZMI tab of it's own (Both of these are easier than live patching the DTML)? Adrian... -- Adrian Hungate EMail: adrian(a)haqa.co.uk Web: http://www.haqa.co.uk ----- Original Message ----- From: "Jim Penny" <jpenny(a)universal-fasteners.com> To: "Adrian Hungate" <adrian(a)haqa.co.uk> Sent: Wednesday, August 14, 2002 4:26 PM Subject: Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches > On Wed, Aug 14, 2002 at 03:48:51PM +0100, Adrian Hungate wrote: > > Hmm... ok, now I see what you are talking about, however, you are talking > > about modifying a DTMLFile object - I am not sure of any reliable API (Or > > even magic) that will allow that to happen in a "play nice with others" way. > > > > Just for clarity's sake (For me if no-one else), what object type are you > > wanting to change manage_main for? > > > > I have to admit to not knowing zshell or external_editor well, but I have > > seen mentions of ee making changes to the ZMI - I had assumed this was the > > addition of tabs (And DTMLFiles), not the replacement of them. I take it I > > was wrong in this assumption? > > yeah, externaleditor inserts icons into many rows of the name column. > zshell want an extra text box to the left of the "add product" pulldown. > There are other products that do similar things. I think the Photo > product modifies things in a similar manner to externaleditor. > These are, I suspect, not even at the object stage. You have to modify > rows in a table. > > Jim

2 2

Re: [Zope-dev] A Modest Proposal Concerning Monkey Patches
by Adrian Hungate 14 Aug '02

14 Aug '02

On Wed, 14 Aug 2002, Jim Penny wrote: [Snip] > > It looks as though what is needed is fish-bowl proposal to redesign the way > > ObjectManager handles and displays rows for specific object types - the > > requirement being that this be third-party-pluggable (For want of a better > > term). (No that was not me volunteering - too much on at the moment, sorry). > > > > One question about zshell though, what is the box that is added "left of the > > add product pulldown"? Is it something that ABSOLUTELY has to be on the > > contents listing (i.e. something to do with creating or maintaining the > > objects listed?). Could it be backdoor'd into all_meta_types so that it, > > itself is listed in the pulldown, or could it have a ZMI tab of it's own > > (Both of these are easier than live patching the DTML)? > > > > Adrian... > > It needs a place to type a command, that is, it is a free form text box. > That is, zshell gives zope a CLI. Historically, you have had to click > on something to get to the CLI. If it is made part of the ZMI, then the > CLI is part of every management window, with no extra work needed to use > it. > > What is needed is to insert a form with a single textbox as element. > > This seems to be a hard problem. Introducing monkeypatches, has, in my > opinion made it harder, before people would have simply given up. Hmm, the more you describe this, the less the ObjectManager's contents view seems quite the right place for it. If the relationship to the current ObjectManager is required, then what is the problem with a ZMI tab (Titled "zShell" or "Command Line" or whatever). This could easily be implimented, would survive upgrades, and (To me at least) would be a more logical interface. > Jim > > > > > -- > > Adrian Hungate > > EMail: adrian(a)haqa.co.uk > > Web: http://www.haqa.co.uk > -- Adrian Hungate EMail: adrian(a)haqa.co.uk Web: http://www.haqa.co.uk

1 0

Refresh trashes acquisition
by Gary Speer 14 Aug '02

14 Aug '02

Dear Ross - I strongly encourage you to switch to the zope(a)zope.org mailing list as this one is dedicated to next-generation product enhancement as opposed to peer user assistance. The approach you are taking seems a bit convoluted and I, for one, do not understand the business/project objectives reason to construct the objects as you do and create the acquisition cvhallenge you hope to solve. Perhaps you can elaborate on the goal you hope to accomplish so others can suggest the better tools and object containment structure to use. It seems earlier design decisions have taken you to solving issues that might not exist with an alternative, more-naturally-zope-like approach. Gary Message: 2 Date: Wed, 24 Jul 2002 13:05:59 -0700 To: "Matthew T. Kromer" <matt(a)zope.com> Cc: Ross Boylan <RossBoylan(a)stanfordalumni.org>, zope-dev(a)zope.org Subject: Re: [Zope-dev] Refresh trashes acquisition From: Ross Boylan <RossBoylan(a)stanfordalumni.org> On Wed, Jul 24, 2002 at 10:38:44AM -0400, Matthew T. Kromer wrote: > Ross Boylan wrote: > > >I find that when I refresh my product it destroys some of the > >containment relationships. Things start failing, and as far as I can > >tell the only recovery is to completely rebuild the object. > > > >This is a big problem, and if anyone could explain what is going on > >and how to avoid it I would appreciate it. > > > >Here is the result of aq_chain before the refresh: > >[<RankQuestion instance at 8dd5620>, > ><OriginalSuborder instance at 8c9f8d8>, <EMailBallot instance at > >8dfc870>, <__FactoryDispatcher__ instance at 8e73770>, > ><ProductDispatcher instance at 83f0618>, <Folder instance at 8d5733 > > > >and after > >[<RankQuestion instance at 8dee2d0>] > > > > > [...] > > > > > > > Hmm, while what you're referring to is "refresh" in the sense of a > product reload, it's important to first state that *no* acquisition is > expected to survive between transactions. > > Each transaction must separately acquire its objects; if you try to pass > wrapped objects between transactions or threads you're going to end up > in trouble. > > Secondly, when a product is refreshed, the extensionclass module will > probably create new base classes for any ExtensionClass derived class > file. I dont *think* you can get much mileage out of knowing the id > (address) of a class now, but be aware that a refresh will likely cause > that address to change. I have seen some bizarre errors where module > "constants" changed because of a reload, and "is" tests broke because > "is" tests the object address. > > None of this is explicitly what you're asking about -- but I think what > you're trying to do is in violation of the "no wrapped objects should be > stored past a transaction boundary" rule. > > However, I may be misreading your question too -- which is why I mention > those two rules above so YOU can see if they make sense in your context. > The first point is definitely relevant, and explains why I am having problems. It's surprising what I'm doing is workign at all! The class redefinition in the second point might explain some of the timing of the problems, but it's the instances, not the classes that I am interested in. The acquisition I want to do is in the object containment hierarchy, but URL of the request will also have this hieararchy. Is there some way I can grab it at the appropriate time? Your comments also clarify a point that was unclear to me from the documentation on acquisition. The documents refers to the object containment hierarchy and the request path hierarchy, and recommend keeping them consistent. But I didn't understand which hierarchy it used if they weren't. Apparently only the request path matters. It may be helpful to say more about the exact relations in my case: [indentation indicates containment in this diagram; capital letters are for objects] B ballot Q1 question R1a response R1b response SR suborder of responses see below for suborders R1a R1b (same objects as the R1's above) Q2 question ... NQ "namestyle" of questions (determines labeling) NR namestyle of responses SQ suborder of questions (sequential, random, ...) this suborder contains a list of the same questions Q1, Q2, etc that the ballot B holds. It also the name of the namestyle, to be acquired from the container. Generally, B and maybe Q will be in my request path, and the other items are not. I ask the suborders for list of items, so they give me back a list of Q's or R's. The items in those lists were the ones I was trying to wrap. At the most extreme case, I get a response R from the suborder list of a question Q, and I get the Q from the suborder of the ballot. So I't two levels removed from my original context, the ballot B, that has the namestyle I'm trying to acquire. The suborder on the Question needs to acquire the namestyle from the Ballot. Finally, I may be making an overly conservative assumption about ObjectManagers. Without it, the suborders would not need to hold onto object references. It's easiest to explain this with a specific example. I want to be able to recover the original order questions were entered into the ballot. Ballot is a subclass of ObjectManager. I believe I am not allowed to make any assumptions about the order its items will be returned by objectItems(), so I am using the suborder to track that. P.S. I also assume that objectItems('type') gets only objects of that type, not subtypes. Does anyone know if that's so? --__--__-- _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org http://lists.zope.org/mailman/listinfo/zope-dev (To receive general Zope announcements, see: http://lists.zope.org/mailman/listinfo/zope-announce For non-developer, user-level issues, zope(a)zope.org, http://lists.zope.org/mailman/listinfo/zope ) End of Zope-Dev Digest

9 21

The DevXML Project
by chrisw_88 14 Aug '02

14 Aug '02

XML is just a file format used to store information. DevXML is a way of sharing information about an interface and eventually a class definition amongst many languages and platforms. Its just data. I wrote one utility in vb to parse the DevXML and generate the interface in vb, but you can use the parsers that already exist on different platforms to parse the file and generate the source in whatever language you work with. This comes in handy if you have development teams working on the same product but for different platforms, eg c++ or vb on nt and java on linux. You wish for the interfaces to be the same and eventually you would wish to share the same basic logic, the only difference is the parts that are specific to c++ or java. This helps resolve problems of inconsistant functionality between the product on one platform vs the other. It also helps resolve the problem of the c++ and java versions having drastically different behavior. That is a developer who is working on the c++ side can more easily transfer his knowledge of the interface and class design to a java developer without either developer having to understand both languages. It could potentially save you some time when porting from one platform to another as you can generate a shell on the new platform by parsing the DevXML files. Then you just need to fill in the platform specific stuff. So far I have a little group that is reviewing my research and providing feedback if you or anyone in your group would like to take part please let me know. The more feedback the more likely it is that we will be successful. My research is being posted at http://www.clinch.netfirms.com/subpages/projects/devxml/index.htm If you have any feedback or wish to be updated when this site is updated please email me at chrisw_new(a)hotmail.com thanks chris williams

1 0