July 2000 - Zope-Dev

Re: [Zope-dev] Zope Add-on Installation
by Dieter Maurer 20 Jul '00

20 Jul '00

Chris Withers writes: > Hi, > > Zope currently has two ways of distributing products: > 1. Tarballs containing python products > 2. .zexps containing methods, ZClass products and the like. > > Things are now getting bad as products are emerging (PTK, Tracker, etc) > which require both of these to get a single product working which is > horrible :/ > > What is needed is a new way of installing Zope stuff for the following > categories: > 1. Python Base Products (Like ZPatterns, PTKBase and TrackerBase) > 2. Instantiatable Products (like TinyTables, Squishdot and Tracker) > 3. Interface Skins (none right now, DemoPortal is probably the closest) Tarballs are flexible enough to install both a Python Products and associated ZClasses from ZEXP's (the products "__init__" function imports the ZEXP at the appropriate place, if it is not already there). I do not say, this is optimal. Dieter

4 6

Broken instances when upgrading from 2.1.6 to 2.2
by noa＠maxnm.com 20 Jul '00

20 Jul '00

Hello, I create a ZClass which subclasses ZCatalog, in my 2.1.6 zope. Then I move the Data.fs to a 2.2 and all the instances of mt ZClass show up as broken This object is broken because the unknown product that created it is no longer installed or is installed incorrectly. (...) The ZClass itself is fine, and I have no problem creating new instances and managing them. I tried to export the instances from the 2.1.6, and importing them into 2.2 but alas: The object broken does not support this operation (traceback follows) Does anybody know why this happens? can anyone please help? Thanks, Noa Traceback (innermost last): File /hd1/zope/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /hd1/zope/lib/python/ZPublisher/Publish.py, line 187, in publish File /hd1/zope/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: ApplicationDefaultPermissions) File /hd1/zope/lib/python/ZPublisher/Publish.py, line 171, in publish File /hd1/zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_importObject) File /hd1/zope/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_importObject) File /hd1/zope/lib/python/OFS/ObjectManager.py, line 496, in manage_importObject (Object: ApplicationDefaultPermissions) File /hd1/zope/lib/python/OFS/CopySupport.py, line 402, in _verifyObjectPaste (Object: ApplicationDefaultPermissions) Copy Error: (see above)

2 1

Re: ZCallable
by Chris Withers 19 Jul '00

19 Jul '00

Yup, This looks good, as did your earlier post. However, it raises a question :( Something like a ZCatalog or a Squishdot Site (which I have a passing interest in ;-) are both folderish. However, their __call__ method does something quite different: it returns the results of searching the catalog (I think this is the ZSearchable Interface, correct me if I'm wrong ;-) I guess what's bothering me is why __call__ has this dual role and how the rendering process manages to correctly render index_html even on a Squishdot object which is actually callable? Hmm... I guess the implication of this is that a normal folder will never render itself to avoid confusion over the ZSearch interface and so if I want this behaviour I'll have to roll-my-own folder which inherits from ZCallable. Any ideas/comments? Chris PS: Shane: what's the difference between ZCallable and the ZRenderable base class that Maik Roeder mentioned on zope(a)zope.org a few days back? On Fri, 14 Jul 2000, Steve Alexander wrote: > Chris, > > Related to your question earlier, have you seen Shane Hathaways' recent > checkin into PTK? > > "Added the ZCallable product, which is a very simple base class that > makes it possible to call an class instance directly." > > -------- > > from ExtensionClass import Base > > class ZCallable (Base): > def __call__(self, *args, **kw): > '''Calls index_html, if it exists, to render this object. > ''' > base = getattr(self, 'aq_base', self) > if hasattr(base, 'index_html'): > v = self.index_html > args = (self,) + tuple(args[1:]) > return apply(v, args, kw) > else: > raise AttributeError, 'index_html' > > def initialize(context): > context.registerBaseClass(ZCallable) > > -------- > > -- > Steve Alexander > Software Engineer > Cat-Box limited > http://www.cat-box.net >

3 4

TR: - I got my answer, Tks - second step (many of You are going to laungh ;-)
by Vincent 19 Jul '00

19 Jul '00

Hi, Thanks a lot for all your answers, I just write a few examples and It is workgin well. Thanks again, and very sorry to sent my query to both lists...

1 0

ZPatterns: missing docstring in getItem()
by Steve Alexander 19 Jul '00

19 Jul '00

ZPatterns 0.4.0a4 The file "version" reports it to be "ZPatterns-0-4-0a1". That gave me a shock! I thought for a moment that I'd been working on an obsolete edition :-) Specialists.py, line 28, method getItem() needs a docstring. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net

3 4

Overriding a method in an instance.
by Chris Withers 19 Jul '00

19 Jul '00

Hi, I guess this should be a feature request for the collector but I thought I'd see what other people thought first... I'd really like to be able to override methods in an instance of an object. Examples I can think of are Squishdot and the Tracker. In Squishdot, or any ZCatalog for that matter, it'd be great to override searchResults to return what I want, formatted how I want. In Tracker, the same could be said for index_html. These may be bad examples, but hopefully you see what I mean... Anyway, if you do try to override, you get a 'This id is already in use' error. How do you get around it and how should this problem be solved? cheers, Chris

3 5

Re: [Zope-dev] Traceback
by Dieter Maurer 19 Jul '00

19 Jul '00

jpenny(a)universal-fasteners.com writes: > How hard would it be to add more of the called URL to the traceback? > > ... traceback ... > > Great, I know that I have not put product_number in as a cookie or a hidden > value, and it could not be found by acquisition. It failed in rendering > index_html. But there are 5 index_html's it could have failed in. > > How hard would it be to change the error message to say: > > Traceback (innermost last): > Exception raised while constructing > http:.... It would probably not be hard to add the URL. Try editing "standard_error_message" and add "<dtml-var URL>" at an appropriate place. You can get it, too, when you are your browser to show you the page/frame info. Dieter

1 0

Re: Acquisition (was: [Zope-dev] Overriding a method in an instance.)
by Shane Hathaway 19 Jul '00

19 Jul '00

Steve Alexander wrote: > > Shane Hathaway wrote: > > > > So it's mostly right-to-left, but sometimes left-to-right, and > > sometimes in a less than predictable order. I have an external method > > that makes it clearer, if you're interested. > > Yes please! This method, instead of showing the acquisition algebra, shows the actual graph of acquisition wrappers. It's ordered in such a way that you can search it from top to bottom to figure out exactly the behavior of Acquisition.c. Install this as an external method "showaq" at the base of your Zope installation. Then try different acquisition paths: http://localhost:8080/QuickStart/showaq http://localhost:8080/QuickStart/Outline/QuickStart/showaq http://localhost:9080/QuickStart/Outline/QuickStart/Control_Panel/showaq A vertical line refers to aq_parent, which is a "context" link. A diagonal line refers to aq_self, which is a "containment" link. Containment never changes; it refers to the physical location of an object. Context, on the other hand, can be modified easily just by changing the URL. Some objects are in parentheses because they are not actually searched. But you'll notice that objects in parentheses have both an aq_self and an aq_parent which refer to the same object. I suppose this method could be cleaned up to eliminate the redundancy, but my goal was to see the actual structure of the wrappers. So, without further ado, here is the method. def showaq(self, indent=''): rval = "" obj = self base = getattr(obj, 'aq_base', obj) try: id = base.id except: id = str(base) try: id = id() except: pass if hasattr(obj, 'aq_self'): if hasattr(obj.aq_self, 'aq_self'): rval = rval + indent + "(" + id + ")\n" rval = rval + indent + "| \\\n" rval = rval + showaq(obj.aq_self, '| ' + indent) rval = rval + indent + "|\n" if hasattr(obj, 'aq_parent'): rval = rval + indent + id + "\n" rval = rval + indent + "|\n" rval = rval + showaq(obj.aq_parent, indent) else: rval = rval + indent + id + "\n" return rval Shane P.S. I wouldn't mind if someone posted this as a HOWTO. :-)

3 2

default__class_init__
by Jeff K. Hoffman 19 Jul '00

19 Jul '00

Hello, Should I call default__class_init__ on all of my Python products that care about permissions? Or are there some times when it is not required? --Jeff --- Jeff K. Hoffman 704.849.0731 x108 Chief Technology Officer mailto:jeff.hoffman@goingv.com Going Virtual, L.L.C. http://www.goingv.com/

2 1

Re: [Zope-dev] Intializing theobjectsformerly-known-as-RackMountables
by Phillip J. Eby 19 Jul '00

19 Jul '00

At 05:54 PM 7/19/00 +0300, Itamar Shtull-Trauring wrote: >"Phillip J. Eby" wrote: > >> If what you want is default values, then just put them in a DataSkin >> property sheet in the ZClass. Or, if using a Python class, implement them >> as class attributes named "class_default_for_X". E.g.: > >I don't like ZClasses all that much, I'd rather not use them. > Okay, then override _objectAdding(). Just be sure to call the original implementation in your overridden version. _objectAdding() is always called with the invariants set up. Note, however, that if you use DataSkins outside of Racks, _objectAdding() is called when an object is moved or copied, as well as when added.

1 0