September 2000 - Zope-Dev

RE: [Zope-dev] Re: Better encapsulation is good...
by Brian Lloyd 01 Sep '00

01 Sep '00

> > Did you run the Article class through > Globals.default__class_init__()? > > E.g. (at the module level), e.g.: > > > > Globals.default__class_init__(Article) > > > > Yes, I tried this too, (saw it in the mailing list archive). (I'm coming to this late, so ignore me if this is covered ground...) Are you certain that you are not losing the acquistion context on your Articles somehow? For example, if you are not doing a getattr on the container to get an article, you may need to maintain the acquistion chain yourself: class Article(Acquistion.Implicit): ... class Articles: """The container for articles. Note that I dont really contain them though - I get them from a database or something (or create them on the fly)""" def getArticle(self, id): # we create an Article on the fly, so we have to # "wrap" the object in the context of its container # to preserve the acquisition chain (and security # depends on an intact acquisition chain) item=Article(id) # this is the wrapping! return item.__of__(self) Hope this helps... Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

2 2

Re: [Zope-dev] Compatibility issues: ZPatterns 0.4.2,LoginManager 0.9.0
by Steve Alexander 01 Sep '00

01 Sep '00

Phillip Eby wrote: > > * We would like to drop support for Specialists directly containing data > plug-ins. This feature was intended to allow for acquiring shared data > plug-ins from within Racks, so that common attribute or sheet providers > could be shared among Racks without copying. In practice, Ty and I have > never once used this capability, and it could be easily replaced with the > ability to "include" a SkinScript within another SkinScript, if we take > advantage of 2.2.x-isms. I have been putting CatalogTriggers as DataManagers directly in Specialists. This seems to me the obvious place to do some triggering action that applies over all the Specialist's racks, but which has nothing to do with storage. I don't yet use SkinScript. However, I imagine there are a number of uses for Triggers that apply at the level of abstraction of a Specialist. Please think about keeping the feature, if it doesn't make things too complicated. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net

2 5

RE: [Zope-dev] Acquisiton, wrapping and persistence...
by Brian Lloyd 01 Sep '00

01 Sep '00

> > Are you certain that you are not losing the acquistion context > > on your Articles somehow? > > There's a good chance that's right :S > Is there anything bad about storing wrapped attributes in a persistent > object? > Butch seemed pretty religious about unwrapping objects before > he stored > them, and maybe he ain't quite wrapping them up right on the > way out... At one time (Jim would know if this is still the case), the ZODB didn't want to store wrapped objects. Wrapping (or "context") is a run-time, in-memory thing while "containment" is a persistent thing. Wrapping really shouldn't be persistent, since context changes based on the way you _access_ things and isn't really meaningful to the persistent state of an object hierarchy. When you access a subobject via getattr, the Acquisition machinery will ensure that the returned object is correctly wrapped. If you store objects under the hood in a way that does not go through getattr, you always need to ensure wrapping yourself: class Things(Implicit): # Things contains individual Thing objects. They are # stored as direct attributes. def getThing(self, id): # dont need to wrap, since we're going through getattr return getattr(self, id) class TrickyThings: # TrickyThings stores its Things internally in a dict # and thus we don't go through getattr. So we have to # do wrapping manually def __init__(self): self.things={} def getThing(self, id): # need to wrap object before returning it object=self.things[id] return object.__of__(self) ...so I'd be looking for some of this sort of trickiness in the code where the result is not being wrapped. > This may be a stupid question, but why does the object need to be > wrapped for security to work anyway? Because security is predicated on acquisition - that is why you can set a permission high in the tree and allow objects lower in the tree to "acquire permission settings" from that original setting. It lets you aggregate permission settings down the heirarchy. So - technically if _all_ of your permission settings were made directly on the object in question (i.e. all of the "acquire permission settings" checkboxes were unchecked and all appropriate permission settings were checked directly on that object), then it would work. But (as in most cases) you are using acquired settings then the object will have to be wrapped and have an intact acquisition chain at the time permissions are checked in order to get the result you expect. Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

RE: [Zope-dev] Re: Better encapsulation is good...
by Chris McDonough 01 Sep '00

01 Sep '00

> Well, I'm at a loss. I tried a bunch things myself, and I've > found out that > instances of the Article class are not inheriting > __ac_permissions__ from > the Posting class. In fact, even if you override > __ac_permissions__ in the > Article class, the validate() method is reporting there's > nothing there. What > I don't understand is, SquishSite works, and SquishFile > works, what's so > different about the Posting/Article classes? > I thought all one had to do was inherit RoleManager, and set > everything > properly in __ac_permissions__ ? Or am I totally not getting > the 2.2 Security > model? Do you know what's going on here? Did you run the Article class through Globals.default__class_init__()? E.g. (at the module level), e.g.: Globals.default__class_init__(Article)

3 2

strange ZopeTime-behavior
by Joachim Schmitz 01 Sep '00

01 Sep '00

The following dtml-snipplet: <dtml-var vonjahr> <dtml-var vonmonat> <dtml-var vontag><br> <dtml-var bisjahr> <dtml-var bismonat> <dtml-var bistag> <dtml-call "REQUEST.set('vondatum',ZopeTime(vonjahr+'-'+vonmonat+'-'+vontag))"> <dtml-call "REQUEST.set('bisdatum',ZopeTime(bisjahr+'-'+bismonat+'-'+bistag))"> <br><dtml-var vondatum> <dtml-var bisdatum> <br><dtml-var vondatum fmt="%d.%m.%Y"> bis: <dtml-var bisdatum fmt="%d.%m.%Y"> produces the following output: 2000 8 1 2000 8 2 2000/08/01 2000/08/02 <--- correct 31.07.2000 bis: 01.08.2000 <--- one day less if used with fmt Bug or feature ? there is no TZ enviromentvariable set. Server is Zope-2.2.0 on RH 6.2 behind Apache with PCGI. Mit freundlichen Grüßen Joachim Schmitz AixtraWare, Ing. Büro für Internetanwendungen Hüsgenstr. 33a, D-52457 Aldenhoven Telefon: +49-2464-8851, FAX: +49-2464-905163

1 0

Why use apply(foo.__call__, ..)?
by Ross Boylan 01 Sep '00

01 Sep '00

In looking over the code for ZWiki/ZC, I see a lot of places with the following construct: apply(foo.__call__, some, arguments) Why not just say foo(some, arguments)? Examples of the construct from ZWikiPage.py: apply(self.aq_parent.standard_wiki_page.__call__, (None, REQUEST, REQUEST.RESPONSE)) or apply(DTMLDocument.__call__,(self, self.aq_parent, REQUEST, REQUEST.RESPONSE)) [OK, in this case the question technically is why use apply(foo.__call__, (a, b, c)) instead of foo(a,b,c)? Hmmm... x.foo(a, b, c) -> foo.__call__(x, a, b, c).] These requests are mostly, if not entirely, directed at WikiPages/Headers/etc, whose definition is, in part, class ZWikiPage(DTMLDocument): #, CatalogAware): def __call__(self, client=None, REQUEST={}, RESPONSE=None, **kw): """Render a zwiki page, with standard header & footer """ I thought the use of keyword argument dictionaries in apply might explain this, but, as the two opening examples show, not all cases have keywords. Second, even if they do one could say aDocument(self, REQUEST, REQUEST.RESPONSE, kw). I understand from Johan that this is "inherited" code (in the non OO sense), so I thought I'd throw this out as a general question. Is there some subtlety of the interaction of Zope (acquisition, perhaps, or extension classes in general) and python that makes foo(x) and foo.__call__(x) have different meanings? Is it something about standard_zwiki_page, which I notice is not a regular python variable? I don't need the answer to this to do something; I'm just trying to understand how things work. Thanks.

1 0

2.2.1, Membership, and a __hash__ error.
by Bill Anderson 01 Sep '00

01 Sep '00

When trying out the mailPassword function (which creates a new encrypted password, and sends the raw password to the user), I get this error (I swear it worked in 2.2.0): Traceback (innermost last): File /local/ZopeSites/TestBed/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /local/ZopeSites/TestBed/lib/python/ZPublisher/Publish.py, line 187, in publish File /local/ZopeSites/TestBed/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Transactional) File /local/ZopeSites/TestBed/lib/python/ZPublisher/Publish.py, line 171, in publish File /local/ZopeSites/TestBed/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: mailPassword) File /local/ZopeSites/TestBed/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: mailPassword) File /local/ZopeSites/TestBed/lib/python/Products/PythonMethod/PythonMethod.py, line 168, in __call__ (Object: mailPassword) (Info: ((<LoginManager instance at 8641768>, (note: snipped form contents) File <string>, line 7, in mailPassword (Object: Transactional) File /local/ZopeSites/TestBed/lib/python/Products/PythonMethod/PythonMethod.py, line 173, in __call__ (Object: mailPassword) (Info: ((<LoginManager instance at 8641768>, (note: snipped form contents), {}, None)) File <string>, line 2, in mailPassword (Object: billT) File /local/ZopeSites/TestBed/lib/python/Products/LoginManager/LoginManager.py, line 65, in getItem (Object: Transactional) File /local/ZopeSites/TestBed/lib/python/Products/ZPatterns/Rack.py, line 57, in getItem (Object: Transactional) File /local/ZopeSites/TestBed/lib/python/Products/ZPatterns/DataManagers.py, line 49, in _canonicalForm (Object: Transactional) AttributeError: (see above) This is the last error I am concerned about for a new release, btw. -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password.

1 0