Dynpersist.so and makefile.pre.in
Hey! I know I've done this before, but for some reason it's eluding me. I'm on a brand new box with a fresh 2.4.3 zope. I am trying to get sql authentication working with loginmanager/Zpatterns I can't seem to find a "makefile.pre.in" on my system. I have python and python-devel both from RPM, and a regular install of zope. I tried using a makfile.pre.in from some other package (found on the web) but got tons of errors. Where would I find a copy of this file for my platform? Which incedentally is Mandrake 8.1. Anyone have one that might work. Do I need to build python from the source? Thanks! -ed-
On my systems it is located at somewhere like /usr/lib/python(version)/config/Makefile.pre.in or /usr/local/lib/python(version)/config/Makefile.pre.in On Wed, Jan 30, 2002 at 10:25:59AM -0800, Ed Colmar wrote:
Hey!
I know I've done this before, but for some reason it's eluding me.
I'm on a brand new box with a fresh 2.4.3 zope.
I am trying to get sql authentication working with loginmanager/Zpatterns
I can't seem to find a "makefile.pre.in" on my system. I have python and python-devel both from RPM, and a regular install of zope.
should be enough.
I tried using a makfile.pre.in from some other package (found on the web) but got tons of errors.
Where would I find a copy of this file for my platform? Which incedentally is Mandrake 8.1. Anyone have one that might work. Do I need to build python from the source?
no, just find the Makefile.pre.in for you build ;)
Thanks!
-ed-
-- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])
On Thu, 31 Jan 2002, Christian Theune wrote:
On my systems it is located at somewhere like
/usr/lib/python(version)/config/Makefile.pre.in or /usr/local/lib/python(version)/config/Makefile.pre.in
Just an FYI, Makefile.pre.in no longer exists (as far as I can tell) under python 2.2. --RDM
Huh... I found a makefile.pre.in, but I'm seeing tons of errors on "make" There was some note in the Zpatterns docs that after zope2.2 the dynpersist woudn't be neccesary anymore. Is this true? Are there any other (simple) solutions to doing authentication through a SQL DB? Jumping through hoops to get Zpatterns working seems silly when all I need is basic authentication. Though it would probably make my life easier once I figure it out. Anyways... Thanks for the assistance! -ed- ----- Original Message ----- From: "R. David Murray" <bitz@bitdance.com> To: "Christian Theune" <ct@gocept.com> Cc: "Ed Colmar" <ed@www.greengraphics.net>; <zope-dev@zope.org> Sent: Thursday, January 31, 2002 9:05 AM Subject: Re: [Zope-dev] Dynpersist.so and makefile.pre.in
On Thu, 31 Jan 2002, Christian Theune wrote:
On my systems it is located at somewhere like
/usr/lib/python(version)/config/Makefile.pre.in or /usr/local/lib/python(version)/config/Makefile.pre.in
Just an FYI, Makefile.pre.in no longer exists (as far as I can tell) under python 2.2.
--RDM
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
On 1/31/02 5:02 PM, "Ed Colmar" <ed@greengraphics.net> wrote:
Huh...
I found a makefile.pre.in, but I'm seeing tons of errors on "make"
There was some note in the Zpatterns docs that after zope2.2 the dynpersist woudn't be neccesary anymore. Is this true?
It seems like it should be true. To the best of my knowledge, DynPersist got around the issue that it wasn't all-too-safe to override __getattr__ and __setattr__ for persistent objects. I know that this issue was fixed in the ZODB, probably around the time of Zope 2.2. However, even in the most recent ZPatterns releases (as maintained in the 'TransactionAgents' package), some Python code still seems to depend on DynPersist.
Are there any other (simple) solutions to doing authentication through a SQL DB? Jumping through hoops to get Zpatterns working seems silly when all I need is basic authentication. Though it would probably make my life easier once I figure it out.
You might want to check out http://www.zope.org/Members/otto/userdb, although it looks rather old. If it's what I think it is, it's based on something done at Zope Corp back in the Principia (Zope before it was Zope) days. UserDb was a pretty simple system that might work for you if it still works. Much easier than anything ZPatterns based - especially given that ZPatterns has gone relatively unmaintained for so long. -- Jeffrey P Shell www.cuemedia.com
On Thu, 31 Jan 2002, Jeffrey P Shell wrote:
On 1/31/02 5:02 PM, "Ed Colmar" <ed@greengraphics.net> wrote:
Are there any other (simple) solutions to doing authentication through a SQL DB? Jumping through hoops to get Zpatterns working seems silly when all I need is basic authentication. Though it would probably make my life easier once I figure it out.
You might want to check out http://www.zope.org/Members/otto/userdb, although it looks rather old. If it's what I think it is, it's based on
You might also want to check out http://www.zope.org/Members/TheJester/exUserFolder --RDM
At 01.02.2002 10:44 -0500, R. David Murray wrote:
You might also want to check out
http://www.zope.org/Members/TheJester/exUserFolder
--RDM
All, Please have a look at my patch for XUF at <http://www.zope.org/Members/shh/Patches/exUserFolder-0.10.4.patch> I believe that manage_addexUserFolder() is faulty, in that it does not call the FactoryDispatcher's this() before assigning to self.__allow_groups__. My point is that 'self' is initially referring to a FactoryDispatcher (App/FactoryDispatcher.py) which does *not* define __setattr__(). I believe this to be the reason for issues surrounding XUF like "undeletable" userfolders where the __allow_groups__ attribute appears to be installed in the wrong place. Please give this a sanity check, so that either I can take down the patch or the XUF maintainers can fix their product. I am CC-ing AKM on this as I have regrettably lost our correspondence and only remember that my patch had been rejected for some reason ;-) Thanks, Stefan -- I am not posting to the XUF list as I would have to subscribe first.
+-------[ Stefan H. Holek ]---------------------- | At 01.02.2002 10:44 -0500, R. David Murray wrote: | | All, | | Please have a look at my patch for XUF at | <http://www.zope.org/Members/shh/Patches/exUserFolder-0.10.4.patch> | | I believe that manage_addexUserFolder() is faulty, in that it does not call | the FactoryDispatcher's this() before assigning to self.__allow_groups__. | | My point is that 'self' is initially referring to a FactoryDispatcher | (App/FactoryDispatcher.py) which does *not* define __setattr__(). As I explained previously I think that if you are trying to install XUF (or anything) programmatically from a ZClass, then you should call the manage_addFoo() on an instanciated object i.e. a Folder or some other container that your ZClass has created, not on your Dispatcher. If someone gives me a sane reason why this isn't correct and that calling self = self.this() in every product constructor is actually the correct behaviour I'll put it in (as opposed to catering for lazy ZClass programmers d8) Not that this seems to be in very many constructors for Zope stuff or other products I have installed. Since it seems this is going to occur repeatedly, having spent 10 seconds looking at it, it seems that the 'correct' way is to call self.Destination()._setObject() so in essence self.Destination().__allow_groups__ will also get what we want. This is actually documented (although it's not clear what versions of Zope this will work with, or whether this will do the same thing as self._setObject(), it's late, I've had no sleep, I'll look later, or someone who actually knows can fill in the blanks for us, but, I think it's 2.4 only) It doesn't seem to be used by any of the Zope objects in 2.4.3 (at least not in any python ones), so it's hard to say. The ZDG does not say that self (or dispatcher as it says), will not be usable as if it was your ObjectManager. "The add function will be passed a FactoryDispatcher as its first argument which proxies the location (usually a Folder) where your product was added." This implies nothing special is needed to use the first argument as if it was the ObjectManager to which you are being installed. So from this it seems if you are running 2.4 that self should be a proxy to an ObjectManager to which you can add things w/o calling Destination() | I believe this to be the reason for issues surrounding XUF like | "undeletable" userfolders where the __allow_groups__ attribute appears to | be installed in the wrong place. err no. That was something completely unrelated, and had to do with the manage_beforeDelete() failing (now corrected). | I am not posting to the XUF list as I would have to subscribe first. Yes, we enjoy the lower spam count over on -devel, -users is open though. If you want to discuss XUF devel issues then you should subscribe and you should post there. Your patch was rejected because it claimed to fix something it was unrelated to, namely the __allow_groups__ persisting after the acl_users was deleted. Your fix could not have possibly fixed it, because the code that actually removed the attribute was never executed, which means you didn't actually test your patch against the condition you told me it was supposed to fix. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|
Andrew Kenneth Milton <akm@theinternet.com.au> wrote:
If someone gives me a sane reason why this isn't correct and that calling self = self.this() in every product constructor is actually the correct behaviour I'll put it in (as opposed to catering for lazy ZClass programmers d8) Not that this seems to be in very many constructors for Zope stuff or other products I have installed.
Since it seems this is going to occur repeatedly, having spent 10 seconds looking at it, it seems that the 'correct' way is to call
self.Destination()._setObject()
so in essence self.Destination().__allow_groups__ will also get what we want.
This is actually documented (although it's not clear what versions of Zope this will work with, or whether this will do the same thing as self._setObject(), it's late, I've had no sleep, I'll look later, or someone who actually knows can fill in the blanks for us, but, I think it's 2.4 only)
Yes, here is the idiom I now use everywhere, according to what I read in the code and documentation: def addFoo(dispatcher, id, REQUEST=None, **kw): """ Adds a Foo. """ ob = Foo(id) container = dispatcher.Destination() container._setObject(id, ob) if REQUEST is not None: dispatcher.manage_main(dispatcher, REQUEST) In any case calling the first argument "self" is really overloading the meaning of the word, as we are nowhere near a method here. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
Hey all. I'm working ona little skinning implementation where I want to pull a folder name out of a database, then navigate to it to get dtml methods. Hardcoding it is easy, but how exactly would I insert a variable into this simple dtml-with? <dtml-with skins.default> <dtml-var standard_skin_appearance> </dtml-with> to get an idea of how the site is layed out, here's where the skins and inside data would live: www.mysite.com:8080/skins/default/standard_skin_appearance I tried variations on: <dtml-call "REQUEST.set('skinname', 'skins.default')"> <dtml-with "_.string(skinname)"> with no luck... In the docs, I'm seeingt that it shoulod be possible with the right syntax. What would that be? Thanks so much! -ed-
On Sat, 2 Feb 2002, Ed Colmar wrote:
<dtml-call "REQUEST.set('skinname', 'skins.default')"> <dtml-with "_.string(skinname)">
This is a zope@zope.org question rather than a zope-dev question, but: <dtml-with "_[skinname]"> should solve your problem. That looks the string held in skinname up in the namespace and passes it to dtml-with. --RDM
Thanks for the reply. I tried this out, and I'm getting a key error: Hmmm... Any other suggestions? Should I specify with PARENTS first? Thanks again! -e- Site Error An error was encountered while publishing this resource. KeyError Sorry, a site error occurred. Traceback (innermost last): File /usr/local/dc/zope/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/local/dc/zope/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/dc/zope/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook (Object: dev_site) File /usr/local/dc/zope/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/dc/zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: index_html) File /usr/local/dc/zope/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: index_html) File /usr/local/dc/zope/lib/python/OFS/DTMLDocument.py, line 199, in __call__ (Object: index_html) File /usr/local/dc/zope/lib/python/DocumentTemplate/DT_String.py, line 546, in __call__ (Object: index_html) File /usr/local/dc/zope/lib/python/DocumentTemplate/DT_With.py, line 133, in render (Object: _[skinname]) File /usr/local/dc/zope/lib/python/DocumentTemplate/DT_Util.py, line 231, in eval (Object: _[skinname]) (Info: _) File <string>, line 2, in f (Object: guarded_getitem) File /usr/local/dc/zope/lib/python/AccessControl/DTML.py, line 104, in guarded_getitem (Object: index_html) File /usr/local/dc/zope/lib/python/AccessControl/ZopeGuards.py, line 151, in guarded_getitem KeyError: skins.default On Mon, 4 Feb 2002, R. David Murray wrote:
On Sat, 2 Feb 2002, Ed Colmar wrote:
<dtml-call "REQUEST.set('skinname', 'skins.default')"> <dtml-with "_.string(skinname)">
This is a zope@zope.org question rather than a zope-dev question, but:
<dtml-with "_[skinname]">
should solve your problem. That looks the string held in skinname up in the namespace and passes it to dtml-with.
--RDM
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
At 02.02.2002 08:08 +1000, Andrew Kenneth Milton wrote:
Since it seems this is going to occur repeatedly, having spent 10 seconds looking at it, it seems that the 'correct' way is to call
self.Destination()._setObject()
so in essence self.Destination().__allow_groups__ will also get what we want.
The call is not needed most of the time as the dispatcher defines __getattr__(). It does however not define __setattr__(). I would still appreciate some comments on what kind of "bad things" can happen if the call to Destination() is omitted. Where will the attribute be set? Could the name __allow_groups__ be (accidentially) acquired? Thanks again, Stefan
At 04.02.2002 21:10 +0100, Stefan H. Holek wrote:
At 02.02.2002 08:08 +1000, Andrew Kenneth Milton wrote:
Since it seems this is going to occur repeatedly, having spent 10 seconds looking at it, it seems that the 'correct' way is to call
self.Destination()._setObject()
so in essence self.Destination().__allow_groups__ will also get what we want.
The call is not needed most of the time as the dispatcher defines __getattr__(). It does however not define __setattr__().
I would still appreciate some comments on what kind of "bad things" can happen if the call to Destination() is omitted. Where will the attribute be set? Could the name __allow_groups__ be (accidentially) acquired?
As nobody seems to know (care?) I suggest, Andrew, you add that one line to be on the safe side and to shut me up ;-). Zope's own UserFolder *does* have it after all. Case closed, Stefan
participants (8)
-
Andrew Kenneth Milton -
Christian Theune -
Ed Colmar -
Ed Colmar -
Florent Guillaume -
Jeffrey P Shell -
R. David Murray -
Stefan H. Holek