Re: [Zope-dev] Re: [Zope3-dev] Need help with http://dev.zope.org/Subversion
On Sun, Apr 25, 2004 at 12:48:30PM -0400, Fred Drake wrote: On Sunday 25 April 2004 12:29 pm, Jim Fulton wrote: cvs co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3 That should be: svn co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3 cvs co http://svn.zope.org/repos/Zope3/trunk Zope3 and this would be: svn co http://svn.zope.org/repos/Zope3/trunk Zope3 Does that mean, that Zope will use svn with cleartext passowords for write access? Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Product directory?
On Tue, Mar 09, 2004 at 01:58:17PM -0500, Ian Beatty wrote: Greetings again. This has to be an easy one. From within my Python-based product's code, how do I get access to the product's directory on the filesystem? os.getcwd() seems to provide the working directory of the shell used to launch Zope, at least when running in debug mode. Try os.path.dirname(mymodule.__file__)? Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __before_publishing_traverse__problem
On Fri, Nov 21, 2003 at 11:41:53AM -0500, Casey Duncan wrote: On Fri, 21 Nov 2003 17:33:43 +0100 lukasz [EMAIL PROTECTED] wrote: I have a problem.When I import my plone site from one server to other I got : AttributeError: __before_publishing_traverse__ What should I do with that? Post it to the *Plone* mailing list? And when you are at it, post the whole stack trace (to the plone list), because the error as such doesn't say anything useful ;) Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope - Document Management Integration
Am Mittwoch, 8. Januar 2003 02:51 schrieb Sameer Maggon: Hi all, We have our own proprietary Document Management Product. Lot of our clients have their valuable data (images, web-pages, other documents) in our repository (powered by our DM product). Now is there a way we can incorporate CMS facilities using Zope where the users can make web-sites using the content from our DMS. If anybody has some idea, please discuss it. I can mail other relavant details. Well, that depends how you can access the DMS data. (proprietary protocol, xml-rpc, corba, etc.) Depending upon intend you can then build proxy objects for Zope. The question remains why you want to do this. Zope seems quite capable to do custom document management (when setup rightly). And if you go the proprietary way with the document management, you should be also capable to do some proprietary CMS solution :) Andreas ___ 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] allowable object ids
Am Sam, 2002-11-23 um 18.30 schrieb Jamie Heilman: Turns out you can create objects with an id of . or .. although you Well, you can access these properties/objects from DTML/Python. Not from ZPublisher (the URL-Object Request Broker). can't access them. (which is to say I couldn't figure out how, though I didn't try ZServer standalone and I suppose apache might be doing something to the URI) You can't create objects with ids containing + or % or a host of other characters though (and btw the error message you get when you try is horrid, those characters are not illegal in URLs, illegal in the zope object model perhaps, but not URLs). I'm currious, why aren't arbitrary characters allowed in object ids? Well, because of the implementation details, it is not possible to allow certain ids (things that start with '_' or 'aq_', etc.). Why % is not allowed I can only guess at, but I'd assume that the authors tried to get sane ids. It's a bit like the Unix Filesystem. By definition it allows all characters except '\0' and '/'. Still it's rather stupid and inconvienent to use exotic characters. By the way, you can look Zope/lib/python/OFS/ObjectManager.py:checkValidId (line 49) to see what is allowed and what not. Andreas ___ 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] __before_publishing_traverse__calls RESPONSE.redirect(): is there another way to change the browser URL?
Am Sam, 2002-09-28 um 05.35 schrieb Craeg K Strong: Sorry for the non-sequitur.. I do not really know if Zope uses the urllib2 machinery or not. Somewhere, however, there must be some code that catches raise 'Redirect', myurl Well, it's just send a response to the browser. You thing it's like this: client - server obj - server obj2 - client In fact it's: client - server obj - client client - server obj2 - client and does the appropriate thing (creates a new request, etc.). My find-grep caught class HTTPRedirectHandler(BaseHandler): (line 427 of urllib2.py) But I have not looked into it enough to understand whether it is what I am guessing it is, and-- even if so-- whether Zope uses it or not. Nope it is not what you guess. in any event, there are other, better solutions on the table, so at this point it is no longer important... Today, that code creates a new REQUEST object, throwing away the old request. I could cause it to insert some value that I would then test for, to distinguish the two cases. REQUEST.redirect sends a status code to the browser which then requests the new URL by itself, ... That would be the king of all hacks, but it might work :-} Probably not. The only thing you can do with redirect is to urlencode your parameters, ... You're probably right. The browser is getting back a status code in the HTTP header that makes it generate a new request. The question I had was: would there be a way to stuff something in the HTTP header that the browser would somehow copy over to the new HTTP header it sends back in response to the redirect status code...? Cookies (if enabled). GET style parameters appended to the URL. Problem with GET and actions is, that the HTTP spec allow the client to request it more than once. That's way at least netscape asks before rePOSTing an URL while it reloads a GET URL without user interference. Actually the HTTP spec allow an browser to get an url repeatedly for any reasons. This is the HUGE semantic difference between GET/POST. (And not that the parameters are passed via the url or stdin, ...) Andreas -- Andreas Kostyrka [EMAIL PROTECTED] ___ 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] [ZOPE 2.6 B1] Unicode/locale problems withOFS/dtml/properties.dtml
Am Don, 2002-09-26 um 18.47 schrieb Arnar Lundesgaard: what do you mean by inserted into the form? Put there by the dtml-method in a dtml-var statement. I can second this. With CVS-Zope (did the last cvs up this moment) I'm getting a very curios thing: Displaying .../index_html is ok. But return context.index_html(context,request) creates broken characters instead is isolatin1 Umlaute. In my case (Konqueror on Linux) it seems that the text/html;charset=UTF-8 breaks the page because the byte values are correct for the Umlaute. This is further confirmed by the fact that forcing Konq to display iso8859-1 fixes the display. So how are these Unicode changes supposed to work? Are non-ascii characters forbidden now? And how do I get UTF-8 text into Zope? While I'm quite sure that this will help Zope in the Asiatic region, it seems quite inconvienent for isolatin1 world :( That the response contains a single byte where you properties contain character whose unicode value is greater than 127 ? Yes how have you checked this? if so, thats a bug. In a Hex editor... The character 'æ' for instance is inserted as '0xE6' in the returned HTML. The same here with Umlaute, ... I've used wget and less result to verify that the umlaute display correctly. Andreas -- Andreas Kostyrka [EMAIL PROTECTED] ___ 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] how to change to another authenticated userprogrammatically?
Am Mit, 2002-09-25 um 09.27 schrieb Chris Withers: Craeg K Strong wrote: I am working on an application where users register themselves. That is, there will be a registrar username and password that is sent out to all prospective users via email. The only thing the registrar can do is add a user. Not sure why you can't just mail out actual user details if the first and only thing a registrar does is register themselves... Or even better: Do not authenticate the users, instead provide a method that has the Proxy rules set, and check the password inside the method. Andreas -- Andreas Kostyrka [EMAIL PROTECTED] ___ 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] __getattr__ and Acquisition
Am Mit, 2002-09-25 um 10.06 schrieb Lennart Regebro: From: Andreas Kostyrka [EMAIL PROTECTED] And how do I return an attribute that is acquired (but not down th main acquisition path, but on a side line?) You shouldn't, really. Why not? I assume that I could probably play some silly games with __of__ to make my additional Acquisition objects to come just before my object in the acquisition path, ... Yup, much better idea. Done. Only thing I've noticed that the Catalog shows this additional path elements, ... See also www.zope.org/Members/yacc/FlexData ;), I've left the old __getattr__ hack commented in the source, ... Andreas -- Andreas Kostyrka [EMAIL PROTECTED] ___ 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] __getattr__ and Acquisition
Am Mit, 2002-09-25 um 12.44 schrieb Lennart Regebro: From: Andreas Kostyrka [EMAIL PROTECTED] To: Lennart Regebro [EMAIL PROTECTED] You shouldn't, really. Why not? Because that's not how it's supposed to work. You can override __getattr__ to have special magick attributes. Acquisition is not a special magick attribute. __getattr__ is only called when an attribute aren't found in a normal way, and in the context of Zope, Acquicistion would be regarded as normal. :-) But my attributes are not normal. So I should generate them by __getattr__. Only by noticing that I could get the same effect by putting my attribute source in front of my object in the acquisition chain. The question is still, how does one a __getattr__ that needs (as a client) acquisition to calculate the attribute. (Basically __of__ works only if I do not need to know the attribute name and do not mind a changed acquisition chain, __getattr__ works only if I do not need Acquisition, ...) Done. Only thing I've noticed that the Catalog shows this additional path elements, ... I guess that depends on when you patch in the extra object in the acquisition. If you do it in __of__() then I guess it's visible all the Well, where else can I patch it in? Andreas -- Andreas Kostyrka [EMAIL PROTECTED] ___ 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] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 00.18 schrieb Lennart Regebro: From: Andreas Kostyrka [EMAIL PROTECTED] I've just discovered, that Acquisition does not work with __getattr__, right? That depends on what you mean with does not work. :-) (I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.) Anyway to get around that? (To basically get a wrapped self from somewhere?) That's what self usually is... :-) Nope it is not. In a normal method you can access something acquired like this: self.acquired_value. Even more, this works for __bobo_traverse__. It just works for the publishing not accessing my attributes later on during publication. The problem is, that __getattr__ does not have access to the acquisition chain. Now I storing the acquisition chain in the object is not a sound proposition, because it is not thread safe. Worse the object might be accessed in some way that makes the acquisition chain not be updated. I think you need to answer a couple of questions: 1. What is it you want to do? 2. How are you trying to do it? 3. What is happening when you try to do it? It's actually trivial ;) I want to acquire some things in __getattr__. Basically I want to insert an additional access step like this: 1.) a.b.c.o - o if o exists in c 2.) a.b.c.o - Folder.o (where Folder is acquired from a.b.c) if it's exist. 3.) a.b.c.o - tries to acquire o from a.b.c. Basically I want Transparent Folders which get their transparent values from the Acquisition path. Well, I just had an idea for an implementation: Third idea: I return some callable object the was generated specifically for the access from the __getattr__. This is than executed with Acquisition enabled, so it can try to get the real one, Problem: What if the attribute does not exist? I do not thing that Zope reacts to well when instead of a AttributeError exception it gets some object that raises AttributeError when accessed, Andreas ___ 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] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 10.35 schrieb Lennart Regebro:
From: Andreas Kostyrka [EMAIL PROTECTED]
Nope it is not. In a normal method you can access something acquired
like this:
self.acquired_value.
I often do just that. :-) I'm not 100% sure what you need to include for
that to work, but I would expect that it is Aqcuisition.Implicit.
Well, Acquisition does not work in __getattr__. This seems trivially
because the self is unwrapped in the case of __getattr__, while it's
wrapped when called on a normal method.
The problem is, that __getattr__ does not have access to the acquisition
chain.
Well, it does, but it typically causes infinite recursion if you aren't
Well, it would perhaps make sense for Acquisition to use the
equivalent of getattr(self.aq_explicit,name) instead of
getattr(aq_base(self),name)
This way you have no infinite recursion, but still can acquire things
explicitly with aq_acquire :)
careful. Something like this might work (this is untested code, adapted from
something that is a bit more complex that we are doing):
def __getattr__(self, name, marker=None):
if not name.startswith('_') and not name.startswith('aq_'):
if not name in self._v_ignore_attrib:
subob = getattr(self,name,_marker)
Well, where do you intenden your getattr to get the attribute from?
self._v_ignore_attrib=[]
# Return it in context of self, forgetting
# its location and acting as if it were located
# in self.
return aq_base(subob)
else:
self._v_ignore_attrib.append(name)
raise AttributeError, name
Basically I want Transparent Folders which get their transparent
values from the Acquisition path.
Aha. Well, I wouldn't call it trivial, but it is definitely doable.
Difficult. Because __getattr__ does not have access to the acquisition
chain. (Just looking at Acquisition.c makes my head go all jelly ;) )
1.) Change Acquisition to call getattr not on self but on an explicit
wrapper of self. see above.
Problem: Compability with Zope? Should probably work. But perhaps there
are things that rely on self being the object and not an explicit
Wrapper.
Problem: The idea of patching Acquisition.c makes my head spin.
Problem: Not possible to fix it up as an Product - needs a patch to
Zope.
2.) Fetch my a wrapped copy of self from the Python call stack.
Problem: It's an example of code that would be labelled Do not copy
this style!
Problem: Can break at the most curious moments.
3.) Store the wrapped self in some attribute during traversal.
Problem: This is plain wrong. It's not safe in a number of ways, ...
(threads, multiple acquisition paths, etc.)
I've implemented solution 2) because
- it's packable as a product
- I'm not sure a core change to Acquisition.c is something that has ANY
chance of getting into Zope.
- I'm not 100% sure that changing Acquisition.c will not break Zope in
some subtle ways.
- I'm already past the delivery deadline for my small application of
this. Hacking the Python stack seems something that I can predict much
better than any try to hack Acquisition.c :(
Andreas
___
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] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 13.10 schrieb Chris Withers: Andreas Kostyrka wrote: The problem is, that __getattr__ does not have access to the acquisition chain. I think it does, but I may be corrected. Well, it's definitly not wrapped. I know because I had to work around that. And it's definitly quite sick how I do this :) Some things to check for: 1. Do the classes of you object (and containing objects) inherit for Acquisition.Implicit? I inherit from OFS.Folder.Folder, this should be enough, wouldn't it? Especially Acquisition works quite well in all other methods, just not __getattr__. 2. Are you getting hold of the object in such a way that it is acquisition wrapped? Well, I'm not getting hold of anything. It's more like Zope is getting hold of my objects to publish. As I've solved my problem (well, it works, I understand the problem, and I know the correct solution, but I shying away of hacking Acquisition. It's easier (for me) to get my wrapper from the Python frame stack than to patch Acquisition.c.) Andreas ___ 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] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume: Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :( Basically __getattr__ when called does not know it's containment anymore. :( Andreas ___ 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] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 18.29 schrieb Florent Guillaume: Andreas Kostyrka [EMAIL PROTECTED] wrote: Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume: Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :( Yes it does. __of__ is non-intuitive but it can work. So how do I call it? return myitem.__of__(self) Doesn't make sense, as self is not wrapped and as such DOES not contain any knowledge how it was accessed, ... /site1/shared/a/b/c/x /site2/shared/a/b/c/x might be quite different things? My problem especially is not generating a wrapper, but to acquire some object from up my acquisition chain, ... Basically __getattr__ when called does not know it's containment anymore. :( You didn't look a the code I pointed to you. Look at CMFCore/Skinnable to be precise (not everything is to be used of course). * In __of__ you store the parent in a volatile attribute, * in __getattr__ you lookup the volatile attribute This works as long as your object is not used in several different acquisition contexts. But exactly THIS I want to support. How should I know if the object will not be used sometime in the future with different contexts. How can I know that my content objects will not be recycled in a second Virtual Host? etc. Andreas ___ 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] small patch to cDocumentTemplate.c to ease debugging
Hi!
As pDocumentTemplate.py is out-of-order at the moment, here is a small
patch to make cDocumentTemplate show more attributes (to help
debugging).
Andreas
Index: lib/python/DocumentTemplate/cDocumentTemplate.c
===
RCS file:
/cvs-repository/Zope/lib/python/DocumentTemplate/cDocumentTemplate.c,v
retrieving revision 1.48
diff -u -u -r1.48 cDocumentTemplate.c
--- lib/python/DocumentTemplate/cDocumentTemplate.c 5 Aug 2002
20:51:14 - 1.48
+++ lib/python/DocumentTemplate/cDocumentTemplate.c 23 Sep 2002
18:41:55 -
@@ -447,6 +447,11 @@
{
if (strcmp(PyString_AsString(name),level)==0)
return PyInt_FromLong(self-level);
+ if (strcmp(PyString_AsString(name),dicts)==0)
+{
+ Py_INCREF(self-data);
+ return self-data;
+ }
}
if (self-dict)
___
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] __getattr__ and Acquisition
Hi! I've just discovered, that Acquisition does not work with __getattr__, right? (I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.) Anyway to get around that? (To basically get a wrapped self from somewhere?) I see two solutions: -) I let some method (like pretraversal) acquire my object and store a reference in my object. This might work if the object is changed seldom and the method is called regularly enough, ... -) I walk the frame stack and extract the wrapped self from it. Not really nice, but then Zope does a number of black magic things :) Andreas ___ 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] Namespaces, ZPublisher, DocumentTemplate question
Hi! I've got a product that inherits from Folder, and creates some magic content by overriding __bobo_traverse__. Now I've got the problem that I cannot access the magic items from within a DocumentTemplate like in dtml-var special. The interesting thing is, that I've overloaded __getattr__ and __getitem__, and it seems both are never called. (Actual code snippets at the end) So I'm wondering how DocumentTemplates (and say Page Templates) access the items and properties? Andreas code snippet: def __getattr__(self,k,*args): r=Folder.Folder.__getattr__(self,k,*args) print __getattr__(%r,%r)==%r % (self,key,r) return r def has_key(self,key): r=Folder.Folder.has_key(self,key) print %r.has_key(%r)==%r % (self,key,r) return r def __getitem__(self,key): print __getitem__(%r,%r) % (self,key) try: return Folder.Folder.__getitem__(self,key) except KeyError: try: return self.__bobo_traverse__(self,None,key) except AttributeError: raise KeyError,key ___ 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 )
