- Zope-Dev - Zope lists

SkinnableAndLocalizableObjects Use Cases more or less finished.
by Martijn Pieters 04 Aug '00

04 Aug '00

Shoot holes where you find weak spots, but please read through the whole Wiki first! http://dev.zope.org/Wikis/DevSite/Projects/SkinnableAndLocalizableObjects I'll get you Architecture on Monday (I am out this weekend), when I get Object Demise^WDomain to work again on my Linux box. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | ZopeStudio: http://www.zope.org/Products/ZopeStudio -----------------------------------------------------

1 0

ZDOM backward compatibility
by Chime Thomas-Ogbuji 04 Aug '00

04 Aug '00

A decision needs to be made regarding ZDOM backward compatibility with DOM level I. We would like to know to what extent pcople use the old interfaces and if adhering to DOM II only would break a lot of prior work. The wiki describing the situation can be found here: http://www.zope.org/Wikis/zope-xml/ZDOMCompatibility Chime

1 0

DataSkin propoerty Sheets/Providers.
by Bill Anderson 04 Aug '00

04 Aug '00

I think I have a decent handle on this concept, but something seems lacking, I hope someone can clear it up :) So, let us say I have an object, call it a Member. :) And let us say I want to be able to add a property sheet to it in a customizer/specialist. AIUI, I should be able to add a persistent sheet provider, give it the name I want for the sheet, and define the sheet? Geex, the more I write what I want to do, the less I feel I grasp it. :( Basically, let me put it this way: I have DataSkins (ZClasses). I have one or two property sheets that I want most/all of the DS objects to have. I don't want to have to define the property sheet in each and every ZClass. AIUI, PersistentSheet providers can do this. I want to do it with the default ZPatterns/LoginManager includes. So, am I totally clueless, or am I just looking to hard, and missing something blatantly obvious? -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password.

2 3

Re: [Zope-dev] ZCatalog and ZSearch Interface
by Chris Withers 03 Aug '00

03 Aug '00

D'Oh! Here's the file... Chris --- ZCatalog.py.old Thu Aug 3 15:17:05 2000 +++ ZCatalog.py Thu Aug 3 15:21:25 2000 @@ -392,7 +392,7 @@ def _searchable_result_columns(self): r = [] - for name in self._catalog.indexes.keys(): + for name in self._catalog.schema.keys(): i = {} i['name'] = name i['type'] = 's'

2 1

ZCatalog and ZSearch Interface
by Chris Withers 03 Aug '00

03 Aug '00

Hi there, While playing with Squishdot to make it more ZSearch-friendly, I noticed that ZCatalog isn't actually ZSearch friendly either. I think the following patch corrects that, if peopel agree, I'll stick it in the collector. cheers, Chris

1 0

RE: [Zope-dev] permissions/authorization on non ZClass/product ob jects
by Chris McDonough 03 Aug '00

03 Aug '00

> > >First, make sure you're returning the instances in the > context of their > >container, e.g. instead of: > > > > def returnstuff(self): > > class foo: > > pass > > return foo() > > > >do > > > > def returnstuff(self): > > class foo: > > pass > > return foo().__of__(self) > > > If you want to do that, then you need to inherit the acquisition base > class too.... > > def returnstuff(self): > class foo(Acquisition.Implicit): > pass > return foo().__of__(self) Oops... yes. Thanks....

1 0

Calling parent class method when method is overridden in current class?
by Phil Harris 03 Aug '00

03 Aug '00

Hi all, I'm in the process of creating a Python based product, and have a need to call the base classes index_html method. My problem is that I need to call it from my classes index_html. My class has DTMLDocument as the base class so I want to call something like DTMLDocument.index_html(). This is my classes index_html (which by the way does not do as I want, obviously or I wouldn't be posting this 8¬)): def index_html(self,REQUEST,RESPONSE): """ this is a doc string """ xml=self.inheritedAttribute(xmlRenderer,'index_html') # this is where I want to call DTMLDocument's index_html() xsl=getattr(self,'style.xsl',None) if xsl is None: xsl=open(INSTANCE_HOME+'/lib/python/Products/xmlRenderer/style.xsl','r').rea d() else: xsl=xsl.document_src(REQUEST,RESPONSE) RESPONSE.setHeader('content-type','text/html; charset=UTF-8') return Sablot.ProcessStrings(xsl,xml) The reason for wanting to do this is so I can get any DTML rendered before I do my stuff with the results. Which by the way means that I'll stick it through a XSL processor with an associated stylesheet and get HTML back. Any ideas? tia Phil phil.harris(a)zope.co.uk

2 3

permissions/authorization on non ZClass/product objects
by Karl Anderson 03 Aug '00

03 Aug '00

I'm having trouble with permissions and Python class instances that aren't part of the Zope permission mechanism. I'm creating plain Python class instances in the Python baseclass of a ZClass, and storing them in a list on the baseclass. The baseclass instantiates these instances and appends them to its list. The class is defined in the baseclass .py file. A method on the baseclass returns this list of instances, and I'm iterating over them in DTML and looking at their attributes - or trying to. I get an authorization prompt, which always gives me an auth error, even though the user can look at the ZClass that's returning the instances. I'm able to get around this by registering the plain Python class as a base class, subclassing them with a ZClass, and instantiating ZClass instances instead of baseclass instances. It seems like overkill, though (and I always thought that instantiating ZClasses in python was confusing). I don't need to expose methods or restrict access, just open the attributes to be used as DTML variables. Are there ways to do this without making full-fledged ZClasses out of my classes? Are there guidelines in general for using non-Zopish subobjects that get used by the publishing process? -- Karl Anderson kra(a)monkey.org http://www.pobox.com/~kra/

3 2

Abstract ZClasses
by Dieter Maurer 02 Aug '00

02 Aug '00

I would find an abstract ZClass (or Meta ZClass) concept very nice (and useful). I would like to use it, e.g., for a general hieararchical view on relational databases. The view allows browsing (via the tree tag) and selection of one or more items. Most can be implemented independantly of the specific hierarchical relation inside the database. A few parameters and the SQL method are dependant on the database tables. A few others are still more specific, e.g. tree display style and single/multiple selection. Thus, I would prefer the following structure: HV: generic Hierarchical View -- abstract defines the interface and a minimal set of required properties and methods implements most of the functions HV_T1, HV_T2, ...: Hierarchical View specialized for a specific hierarchical relation this (standard) ZClasses define the SQL method and instantiate some parameters of HV i_T1_1, i_T2_2, ...: Instances of HV_T1 more specializations (parameters, presentation methods). Most can be done with the current ZClass architecture: the intermediate ZClasses HV_T1, ... are all derived from ZClass HV. The instances are instances of the intermediate ZClasses. There are 2 exceptions: * HV_T1 cannot specialize properties of HV. They can be specialized in the instances of HV_T1, but it would be nice, if it could be done in the class, if all/most instances share the same value. Workaround: do it in the HV_T1 constructor. * Instances can override property values but not methods. Trying to add a method overriding a default class behaviour results in an "Id already exists" error. Workaround: give the overriding method a different name and let the default method look whether something overriding exists. What do you think about abstract (or Meta) ZClasses? Dieter

1 0

MethodGeddon
by Chris Withers 02 Aug '00

02 Aug '00

http://www.zope.org/Wikis/zope-dev/MethodGeddon Just been reading about this and I was wondering how is coming along... Is it in the fishbowl under another name or should it be in the fishbowl? Shane, would the argument list be a management tab for methods? That sounds cool to me :-) I reckon 'self' should always be the equivalent of the python 'self' or not exist to avoid confusion. I guess that means it wouldn't get used much since it would be the actual method-object (and I thought that was an oxymoron ;-) but with the possibility opf things like __render__ and __call__, who knows... The argument list would be great, 'cos you could then be able to specify additional arguments of type 'binding' which might be any of the following from you list: (select by dropdown? ;-) > Bind to the object containing a method, > Bind to the object that acquired a method, and possibly > Bind to the object containing the method in the context of the object that acquired the method, and maybe even > When a method is defined in a ZClass, bind to the instance in such a way that attribute lookup is performed in the baseclasses of the class defining the method (aka bind to "super"). So you could get to any or all of those as you need in your method. Of course, new users wouldn't have to worry about this until they needed to do something that used it. The other option would be to have these automatically bound to certain names (like _ is now) but perhaps that would be more confusing? Thoughts and comments would be great :-) cheers, Chris

2 4