October 1999 - Zope-Dev

RE: [Zope-dev] XMLWidget ldemo undeletable.
by Martijn Pieters 19 Oct '99

19 Oct '99

At 16:15 19/10/99 , Michel Pelletier wrote: >Data.fs.in is generated from the database, it does not come with the >distribution. It is safe to delete it, it is the index file into the >database that speeds up load time. If you delete it, Zope will just >take a few extra seconds at start time to rebuild it. I'm not sure if >the tranalyzer was meant to be pointed at it, it has a very different >format than Data.fs. I suspect you would get an error from tranalyzer >if you pointed it at a perfectly good index file. I love correcting DC ;) Data.fs.index is the index file. Data.fs.in is the 'default' database file that is copied to Data.fs when first installing Zope. It could be that the Tranalyzer doesn't open the file as a binairy. THis doesn't make any difference on most UNIX platforms, but it does on Win32. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------

1 0

RE: [Zope-dev] XMLWidget ldemo undeletable.
by Michel Pelletier 19 Oct '99

19 Oct '99

> -----Original Message----- > From: Robin Becker [mailto:robin@jessikat.demon.co.uk] > Sent: Tuesday, October 19, 1999 7:01 AM > To: zope-dev(a)zope.org > Subject: Re: [Zope-dev] XMLWidget ldemo undeletable. > > ... > It's a bit worrying that Data.fs.in has a problem though. Makes me > wonder if my CVS isn't bringing the file down in binary mode. Data.fs.in is generated from the database, it does not come with the distribution. It is safe to delete it, it is the index file into the database that speeds up load time. If you delete it, Zope will just take a few extra seconds at start time to rebuild it. I'm not sure if the tranalyzer was meant to be pointed at it, it has a very different format than Data.fs. I suspect you would get an error from tranalyzer if you pointed it at a perfectly good index file. -Michel > -- > Robin Becker

3 2

RE: ZDOM patches
by Amos Latteier 19 Oct '99

19 Oct '99

Anthony Pfrunder wrote: > I'll submit them again but basically this is how to patch it: > * For all creation DOM methods (clone, createXX ...) you need > to add some hidden magical methods to stop weird errors from > occuring. Here is how: > > # This makes the aquisition path point to the current containing > # document. These attributes doesn't exist after a creation > call hence, > # aquisition doesn't work properly. > > def XMLpatch(self, p): > p.aq_acquire = self.aq_acquire > p.aq_base = self.aq_base > return p > > Then, for each creation call wrap it like such: > > def createTextNode(self, data): > return self.XMLpatch(Document.createTextNode(self, data)) > > here, Document is an XML document and data is the actual > content of the > Text Node (I think). Hmm. I'd like to know more about what sort of weird errors this patch fixes. (Ideally I like to see a snippet of code which demonstrates the problem.) In general, hacking an object's 'aq_acquire' method and 'aq_base' attribute is not a good idea. In general the right thing to do is to wrap an object with an acquisition wrapper so that it has the correct acquisition context. That said, I've been talking with Martijn Faassen about some ways in which the XML Document doesn't work well with the DOM API because of acquisition. The problem is that the DOM seems to assume that arguments to methods are changed. For example, foo.removeChild(bar) # does not actually change bar's parent is assumed to change bar, not just foo. This doesn't work with XML Document since it uses acquisition to keep track of parent nodes. Since bar is an acquisition wrapper (which is immutable) we cannot change its parent. Note however, that most DOM methods like this return their arguments so you can get the changed bar as the return value of this method. bar=foo.removeChild(bar) # returns correctly wrapped bar It's fairly easy to work around these problems, but still it would be nice to have a more robust solution, since this sort of gotcha is subtle, and likely to trip up folks. It may be that using acquisition is not the right solution for XMLDocument Nodes to keep track of their parents. I'm open to suggestions (and patches). -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com

3 2

Linking to objects, or Keeping track of moving objects
by Itamar Shtull-Trauring 18 Oct '99

18 Oct '99

I'm creating a Recipe object, which will contain numerous Ingredient objects. Each Ingredient objects has to point or reference a Food object, which is stored elsewhere in the database. So, we can have different Ingredients pointing at the same Food object. The question is, how do I create a reference to the Food object? If I just store the path to the Food object as a string (e.g. a property containing "/Foods/Oil/OliveOil"), if someone moves the Food object my reference will be wrong. Likewise if someone renames the Food object. I could each Food object a unique ID, and have some sort of lookup object that gives the path of an object based on ID, but what happens when someone does a "Copy" & "Paste"? I could store Food objects in an SQL db, but I'd much rather use ZODB so I can use acquisition and to reduce overhead. Any idea on how to do this? -- Itamar - itamars(a)ibm.net ---------------------------o----------------------------------------------o Perl/Gimp Greeting Cards | Trust? Ha! The US dollar is backed by ICBMs! | http://www.sealingwax.com | --Anonymous Coward, Slashdot |

3 2

RE: [Zope-dev] pam authentication support with PyPam
by Michel Pelletier 18 Oct '99

18 Oct '99

Regardless of whether or not Zope has a PAM folder (which I think is a good idea) we need to discuss an upcomming problem with Zope user authentication: the proliferation of user folders. The problem is there are now quite a few user folders that all kinda look the same, smell the same, and share a good bit of code. This is very brittle. The 'backends' should be abstracted away from the 'frontend' and we should return to the original state of grace, one type of user folder. At the moment if we were to change an aspect of Zope authentication that would break existing user folders, we would have to go and fix every single one, the orpaned ones without maintainers (like etcUserFolder, my personal orphan) would simply remain broken until someone got frustrated enough to fix them. This is a pretty bad state of affairs. So lets fire up a discussion on what kind of model we could impliment to have a generic user folder with pluggable backends (one of which could be PAM). It might even be a good idea to look *at* PAM for some ideas, anyone here a PAM expert? Hmm.. it might also be nice to take Membership and the ZPT into consideration here, like support for extensable user objects (if the 'backend' supports it) etc. -Michel

2 1

Failing Zen, acquisition surprises or a (documentation) bug???
by Rik Hoekstra 18 Oct '99

18 Oct '99

After struggling for a long time with a denial to use manage_changeProperties in clone methods for some (in fact all but me because I'm superuser) of the developers of our Zope site, I found today that I had to set the proxy securities of the cloning method to solve these problems. The developers have manager rights from the root - that is to say right to do everything. The problems only occur from methods acquired from other folders, as follows: folder1 item_to_be_cloned cloneMethod (including changeProperties on the cloneditem) folder2 cloneForm calling cloneMethod While under the proxy tab it is stated that "Proxy Roles allow a DTML Document or Method to access restricted Zope resources. Normally a DTML Method or Document can only access resources for which the user is authorized. By adding Proxy Roles, you allow the DTML Document or Method to act with additional roles, beyond what the user may have." This either is a misleading text, or this is a bug or an unexpected feature, or once more I have to deepen my Zen. The developers _do_ have the rights to manage properties, that's obvious. So changing the proxy roles should not make any difference, or should it? Is it acquisition that is interfering here, and if so, how? Could someone who is closer to Nirvana than me explain this. Please enligten me. Rik

1 0

RE: [Zope-dev] pam authentication support with PyPam
by Ian Blenke 18 Oct '99

18 Oct '99

On Mon Oct 18, 1999, Michel Pelletier wrote: > Regardless of whether or not Zope has a PAM folder (which I think is a > good idea) we need to discuss an upcomming problem with Zope user > authentication: the proliferation of user folders. Agreed! This is something I've been waiting for. > The problem is there are now quite a few user folders that all kinda > look the same, smell the same, and share a good bit of code. This is > very brittle. The 'backends' should be abstracted away from the > 'frontend' and we should return to the original state of grace, one type > of user folder. Something akin to a SPI (Service Provider Interface) User Folder class that implements a standard set of interfaces for all User Folder classes to subclass. A standard SPI User Folder could be wedged into the current cludge of implementing the currently required methods needed for User Folder functionality. > At the moment if we were to change an aspect of Zope authentication that > would break existing user folders, we would have to go and fix every > single one, the orpaned ones without maintainers (like etcUserFolder, my > personal orphan) would simply remain broken until someone got frustrated > enough to fix them. This is a pretty bad state of affairs. Leaving compatibility with the previous User Folder method isn't a bad thing. Make a "generic User Folder Provider" class that can be subclassed for future User Folder implementations, while implementing the legacy backend that existing User Folder implementations require. > So lets fire up a discussion on what kind of model we could impliment to > have a generic user folder with pluggable backends (one of which could > be PAM). It might even be a good idea to look *at* PAM for some ideas, > anyone here a PAM expert? PAM is wonderful. I'm no PAM expert, but I'm willing to help. If we use the PyPam wrappers, we won't need to worry about the system implementation. There is at least one port of PAM to NT available on the 'net - although it is more useful as a MS GINA replacement for Kerberos support :) We use pamsmbd here. Anyone can login to their Unix account (Linux or Solaris) with their NT domain password. If I could enable a PAM module, I could effectively do the same thing as "NT User Folder" with my existing configuration. I've seen the "smb user folder" Product out there, but haven't had time to fight with it yet. > Hmm.. it might also be nice to take Membership and the ZPT into > consideration here, like support for extensable user objects (if the > 'backend' supports it) etc. PAM for authentication - cross-platform implementations exist. NSS for user information - Unix implementations only. How do you look up user information generically across all known platforms? You need a "single signon" repository. Eventually, the best user database is an LDAP directory tree. It would be great to work User Folder authentication out of the new Zope LDAP objects under construction (I can't wait! :) - Ian C. Blenke <ian(a)blenke.com> <icblenke(a)2c2.com>

1 0

cPersistence.c warning
by Robin Becker 18 Oct '99

18 Oct '99

C:\Python\devel\Zope\lib\python\ZODB\cPersistence.c(373) : warning C4715: 'Per__getstate__' : not all control paths return a value seems as though this routine has a missing 'return NULL;' -- Robin Becker

2 1

pam authentication support with PyPam
by Clarence 18 Oct '99

18 Oct '99

Hello all! I was just curious if anyone had seen PyPam (http://www.pangalactic.org/PyPAM/) which is the beginnings of python bindings for pam. I was wondering if anyone was thinking about adding pam support to zope. This would be neat because you could use any type of authentication that was available from a pam-aware OS such as RedHat. Clarence T. Pate

3 4

RE: [Zope-dev] ZCatalog and indexing DTML methods
by Jay, Dylan 18 Oct '99

18 Oct '99

> -----Original Message----- > From: Michel Pelletier [mailto:michel@digicool.com] > Sent: Monday, October 18, 1999 03:33 > To: zen(a)cs.rmit.edu.au > Cc: zope-dev(a)zope.org > Subject: Re: [Zope-dev] ZCatalog and indexing DTML methods > > > Stuart 'Zen' Bishop wrote: > > > > Greetings. > > > > I need to use ZCatalog to index computed values of my ZClass. > > It seems that ZCatalog will happily call DTML methods and index > > their output, but the DTML methods are not called with any arguments > > so cannot do very much. > > Right. > > > At the moment, I'm having to shadow the output of my DTML > methods (eg. > > return the Id of PARENTS[1] type stuff) in property sheets > to achieve > > the required functionality, but this is ugly. > > Yup. > > > Is this sort of thing possible with ZClasses, or is this where it > > is worth switching to Python classes? > > You might want to step down to Python, especially for > 'computable' like > stuff. > > > Would it be possible to modify Catalog to do this? I think the > > necessary section to modify would be recordify in Catalog.py. > > The first argument to a DTML Method call would just be the object > > passed to recordify. I'm unsure how to fake up the REQUEST attribute > > though. Is this the right way to proceed? > > The problem here is that an assumption is being made, passing > an object > in as the first argument to a bound method. The whole > argument passing > concept in general is ripe with complication, as everyone and their > brother is going to want to call a method their way, although > I do agree > that calling DTML methods with a context is useful. > > I'll have to think about this a bit to see if there is a general > solution, in the mean time you can of course modify your code > (you found > the right spot). Anyone else have any ideas? I think that some assumtion should be made in general for any call to a DTML method with no arguments. I think a call to "anInstance.aDTMLMethod()" is an intuitive thing to do as is <dtml-with myfolder> <dtml-var "myMethod()"> </dtml-with> Is there any reason (other than the fact it would prob be hard to impliment) that <dtml-var "myMethod()"> can't be equivelent to <dtml-var myMethod>? If someone wants to explicitly pass no context in they can use <dtml-var "myMethod(_.None, _.None, _.None)">. An uncommon case I would think anyway.

1 0