[Zope-dev] Why use apply(foo.__call__, ..)?
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.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] strange ZopeTime-behavior
The following dtml-snipplet:
dtml-var vonjahr
dtml-var vonmonat
dtml-var vontagbr
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))"
brdtml-var vondatum
dtml-var bisdatum
brdtml-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
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compatibility issues: ZPatterns 0.4.2
Steve Alexander wrote: Phillip J. Eby wrote: Now, I can provide *unfiltered* linkage by direct delegation, but this would mean dropping the ability to selectively take only certain attributes or sheets from the parent. But I suppose that, compared to dropping the capability to acquire altogether, this might be preferable. This sounds fine for my use of Triggers that apply across everything that a Specialist manages. I've got ZPatterns 0.4.2a1 now. I see that Folders w/ customizer support now have their own Data-plug-ins tab (they didn't before), and that it does direct delegation, rather than filtered forwarding. Does this mean that your suggestion above has become a design decision for ZPatterns? Data plug-ins directly in Customizers and Specialists aren't due to be deprecated? I'm guessing that this is the case. Also, it is a bit of a pain to refresh each of the DataManager instances on each upgrade. How about an external method in ZPatterns to walk the object tree and update instances as required? Perhaps it could use ZopeFind. Or, seeing as Specialists and Customizer folders contain other DataManagers, could you add a button to a tab in Specialists and Customizer folders that refreshes them, and recursively all the DataManagers they contain? Then I'd just have to go to each top-level datamanager and refresh them when I upgrade. Oh also, FYI, we're using ZPatterns for a couple of medium sized projects, one of which is functionally complete. SkinScript has proved extremely useful. I've been able to evolve an application in a very clean way using propertysheets and SkinScript, whereas before I'd have had to retrofit a custom base class. Phillip and Ty, thanks for your sharing your work and sharing your ideas. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] MailHost, 2.2.1, and tracebacks
Bill Anderson wrote: OK, I've bee trailing this bug for quite some time, and haven't found a solution other than not use 2.2.1 :( (snip) File /local/ZopeSites/TestBed/lib/python/OFS/DTMLMethod.py, line 172, in __call__ (Object: mailPasswordTemplate) File /local/ZopeSites/TestBed/lib/python/DocumentTemplate/DT_String.py, line 528, in __call__ (Object: mailPasswordTemplate) File /local/ZopeSites/TestBed/lib/python/Products/MailHost/SendMailTag.py, line 182, in render (Object: MailHost) File /local/ZopeSites/TestBed/lib/python/OFS/DTMLMethod.py, line 194, in validate (Object: mailPasswordTemplate) File /local/ZopeSites/TestBed/lib/python/AccessControl/SecurityManager.py, line 139, in validate File /local/ZopeSites/TestBed/lib/python/AccessControl/ZopeSecurityPolicy.py, line 178, in validate File /local/ZopeSites/TestBed/lib/python/AccessControl/Owned.py, line 152, in getOwner (Object: mailPasswordTemplate) ValueError: (see above) By any chance does it say something to the effect of "Unpack tuple of incorrect size"? If so, I suggest you add a "print owner" statement just before line 152 of Owner.py and tell us what it says. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Not Globals.default__class_init__(Article) :-(
Chris McDonough wrote: Did you run the Article class through Globals.default__class_init__()? E.g. (at the module level), e.g.: Globals.default__class_init__(Article) Yup, all the possible related classes have been run through this... cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Acquisiton, wrapping and persistence...
Brian Lloyd wrote: (I'm coming to this late, so ignore me if this is covered ground...) It isn't :S 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... This may be a stupid question, but why does the object need to be wrapped for security to work anyway? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Acquisiton, wrapping and persistence...
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[EMAIL PROTECTED]
Software Engineer 540.371.6909
Digital Creations http://www.digicool.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compatibility issues: ZPatterns 0.4.2
"Phillip J. Eby" wrote: I see that Folders w/ customizer support now have their own Data-plug-ins tab (they didn't before), and that it does direct delegation, rather than filtered forwarding. Direct delegation? I've lost you here. If it's doing that, then something's broken. sorry -- I didn't really mean that. Check and see if you have any "Link to Parent Data Plug-ins" in your customizers (they're added by default now on new customizers). You can filter the parent providers by selecting the ones you want to leave out on the "exclude" property. That's what I meant. Great. Does this mean that your suggestion above has become a design decision for ZPatterns? Data plug-ins directly in Customizers and Specialists aren't due to be deprecated? I'm guessing that this is the case. Argh. I knew there was something (else) I was forgetting to document in the CHANGES file. I had better go fix that now. I'll take that as a "yes" then. :-) Also, it is a bit of a pain to refresh each of the DataManager instances on each upgrade. How about an external method in ZPatterns to walk the object tree and update instances as required? Perhaps it could use ZopeFind. Or, seeing as Specialists and Customizer folders contain other DataManagers, could you add a button to a tab in Specialists and Customizer folders that refreshes them, and recursively all the DataManagers they contain? Then I'd just have to go to each top-level datamanager and refresh them when I upgrade. It isn't actually be necessary to refresh on every upgrade. IIRC, that note about refreshing is in reference to pre-0.4.x versions. I guess I need to fix that too... I had a bit of oddness with a Folder with Customizer Support on upgrading from 0-4-1snap1 to 0-4-2a1. Until I added then removed a datamanager, there was some attribute error occuring. Unfortunately, I didn't look into it before I accidentally fixed it. I'll be upgrading another zope instance with ZPatterns later on, so I'll watch out for the same behaviour then. do you think you could perhaps be persuaded to write a short reference and/or tutorial for us to include (perhaps as a help screen from the SkinScript method object's management screens)? Thanks. I have a DataSkins how-to / short introduction that is about half complete. I was hoping to get this out by today, but then I discovered SkinScript, and also real work got in the way :-) I'll try and get it finished this weekend. Perhaps some of that can be reused as help in the management screens. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] But I used __ac_permissions__! :S
Brian Lloyd wrote:
Here's a quick thing to try- if 'subject' is an attribute
of your Article class, try adding:
class Article(...):
subject__roles__=None
then restart and see if you still get unauthorized...
yup, I do :-(
And besides, 'subject' is already in __ac_permissions__, as you can see:
(a lot of stuff snipped out though ;-)
__ac_permissions__ = (
('View', ['subject','getThread'], ('Anonymous', 'Manager')),
)
and I do appropriate Globals.default__class_init__'s...
Man, I really have no idea, and not even any clue where to look.
The big factor seems to be that 'subject' is a string. I had a similar
problem with the SquishFile class with the 'icon' attribute.
When it was a string:
# protected by 'View' permission
icon = 'misc_/Squishdot/squishfile_img'
...even though it was a class variable and protected in
__ac_permissions__, I was getting very similar errors to the above...
I was lucky, in that case, because it was a class variable, I could turn
it into a method:
# protected by 'View' permission
def icon(self):
return 'misc_/Squishdot/squishfile_img'
...and, lo and behold, no more security errors from there... :S
Unfortunately, the string attributes in the Article class are instance
attributes, not class attributes, so I can't do the same thing :-(
Any ideas?
cheers,
Chris
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] _setObject error - urgent!
Sorry for the cross post and so on, panicked with a deadline approaching. The error was caused my a cataloguing error after intialisation. Thanks. - Original Message - From: "Andy McKay" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, August 31, 2000 10:00 AM Subject: [Zope-dev] _setObject error - urgent! Hi, I think I have traced my error with cut and paste, I am getting an error on _setObject. If the object is not registered with Zope properly this will be a problem. Basic synopsis: Im importing an object from a script so Im getting a handle to the folder I would like the object to be in: this is obj. Then I call add and set object: obj._setObject(id, globals()[doctype](id, m)) This rather unusual syntax allows me to use a constructor for man different objects. The type is specified in 'doctype', I then get this error: 2000-08-31T16:56:57 PROBLEM(100) ASPNDoc Error: [exceptions.NameError: cat] Any ideas? Thanks in advance ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZCatalog: text searches fail with sort_on + patch
I'm getting an error in Catalog when I specify sort_on on a field-index, and also search on a text index. Zope 2.2.1, Python 1.5.2 Error Type: TypeError Error Value: loop over non-sequence Traceback (innermost last): File lib/python/ZPublisher/Publish.py, line 222, in publish_module File lib/python/ZPublisher/Publish.py, line 187, in publish File lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: ProviderContainer) File lib/python/ZPublisher/Publish.py, line 171, in publish File lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: search) File lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: search) File lib/python/OFS/DTMLDocument.py, line 177, in __call__ (Object: search) File lib/python/DocumentTemplate/DT_String.py, line 528, in __call__ (Object: search) File lib/python/DocumentTemplate/DT_In.py, line 630, in renderwob (Object: SiteIndex) File lib/python/Products/ZCatalog/ZCatalog.py, line 463, in searchResults (Object: Traversable) File lib/python/Products/ZCatalog/Catalog.py, line 602, in searchResults File lib/python/Products/ZCatalog/Catalog.py, line 555, in _indexedSearch TypeError: (see above) This seems to be a simple type incompatibility error. Attached is a patch that fixes this. In Collector, http://classic.zope.org:8080/Collector/1586/view -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net *** Catalog.py.orig --- Catalog.py *** *** 552,558 if intset: append((k,LazyMap(self.__getitem__, intset))) else: ! for r in rs: append((sort_index._unindex[r], LazyMap(self.__getitem__,[r]))) --- 552,558 if intset: append((k,LazyMap(self.__getitem__, intset))) else: ! for r,x in rs.items(): append((sort_index._unindex[r], LazyMap(self.__getitem__,[r])))
Re: [Zope-dev] But I used __ac_permissions__! :S
This is just a SWAG (Strategic Wild-Ass Guess), but Ty and I have been
having a problem with the search feature in Squishdot 0.7.0 that seems
possibly to be related. Our trace of the problem shows that catalog
searches from the SquishSite return objects which are wrapped with a
*different* acquisition hiearchy than the SquishSite itself or from the
User object it's trying to check roles on. Thus, *even though* the user
has the right roles, user.allowed() disallows the roles as invalid because
they're being granted from a (seemingly) different hiearchy.
What we found is that ZCatalog uses the older REQUEST.resolve_url() method
to access the "true" objects, which has this side effect. If it used the
new 2.2 traverse methods, the acquisition hierarchy would be the same. As
it stands, the objects returned by ZCatalog.getobject (by way of
SquishSite.__call__) even have different REQUEST objects than the original
REQUEST object for the web hit.
Does this sound like it's anything related to the problems you're having?
At 05:00 PM 9/1/00 +0100, Chris Withers wrote:
Brian Lloyd wrote:
Here's a quick thing to try- if 'subject' is an attribute
of your Article class, try adding:
class Article(...):
subject__roles__=None
then restart and see if you still get unauthorized...
yup, I do :-(
And besides, 'subject' is already in __ac_permissions__, as you can see:
(a lot of stuff snipped out though ;-)
__ac_permissions__ = (
('View', ['subject','getThread'], ('Anonymous', 'Manager')),
)
and I do appropriate Globals.default__class_init__'s...
Man, I really have no idea, and not even any clue where to look.
The big factor seems to be that 'subject' is a string. I had a similar
problem with the SquishFile class with the 'icon' attribute.
When it was a string:
# protected by 'View' permission
icon = 'misc_/Squishdot/squishfile_img'
..even though it was a class variable and protected in
__ac_permissions__, I was getting very similar errors to the above...
I was lucky, in that case, because it was a class variable, I could turn
it into a method:
# protected by 'View' permission
def icon(self):
return 'misc_/Squishdot/squishfile_img'
..and, lo and behold, no more security errors from there... :S
Unfortunately, the string attributes in the Article class are instance
attributes, not class attributes, so I can't do the same thing :-(
Any ideas?
cheers,
Chris
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Converters.field2date, allow empty string to return None?
One thing that has been bothering me is that I can't easily test my ZSQL Methods if they accept a date type unless I completely fill all the date arg types. For example, if the sqlmethod has argument type startdate:date='' and in the body I have dtml-if startdate ... When i use the test form, I can't leave the date field empty, otherwise I get a conversion error from Converters.field2date() I also have this problem with any form that has type date, if the end-user doesn't put a date in the form, I get a conversion error. Its okay with me to receive an empty string, which gets converted to None .. I just put NULL in the sql database. So .. what's the correct fix to allow empty fields to return either '' or None from field2date? I can alter Converters.py... I see that converters required: exists, but does that imply that all other converters allow an empty string to return None? Or do we need to add an explicit "optional" type? Either way, I'd like to fix this, but what's the best way? Brad Clements,[EMAIL PROTECTED] (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
