[Zope3-dev] Question and maybe enhancement of the HomeFolderManager
Hello, when I want to use my own Folder implementation as a homefolder I have two possibilities at the moment: 1) Disable autoCreate and create the homefolder myself. 2) Write a completely own implementation of IHomeFolderManager, use the existing code, only change the line self.homeFolderBase[name] = Folder() in assignHomeFolder(..) to something which creates my own IContainer implementation Is this correct? My enhancement idea: Make it possible in the utility management site to select the object type to create. Just display a list of all classes (or all classes derived from IContained) and let the user select one. Is this possible to implement? ATM my knowledge is not sufficient to implement this, so for now I'll go the way number 2 and file a collector issue. Maybe I'll be able to do this later. Ok? Florian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] release numbering
Martijn Faassen [EMAIL PROTECTED] wrote: The only non-standard part left in the release name if we drop the double 3 is the X. The X is a bit of a bother and will get us into trouble anyway eventually if a Zope 3 proper is ever released, as I can't see how we'd avoid situations where we'd have to say: Zope 3.1 is actually Zope X3.4 + Zope 2 compatibility extensions 0.7, which sounds less than ideal. I personally wouldn't mind if we just dropped the X. Yes, IMHO it'd be simpler to rename Zope X3.4 to Zope 3.4, and when the real Zope-3-with-Zope-2-compatibility arrives, either call it 3.6 or whatever is the current numbering, if it makes sense to have it in the same branch (which I understand may not be the case), or simply go to Zope 4. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: Dominik Huber wrote: Excuse me late response I was busy that weekend... Jim Fulton wrote: I fixed that issue within the branch 'Zope3/branches/dominik-locatableadapters' Jim, could you take a look at that please. Thank you very much in advance! [...] We should *only* add the location if the adapter requires a permission other than zope public. Key rereferences don't require a permission and should not be location proxied. Doing so makes them unpicklable. We're going to need to fix the trusted adapter factory to do this correctly. I suggest we create a new kind of trusted adapter factory, perhaps LocatingTrustedAdapter factory that adds the location. This should only be used when the adapter directive specified a permission other than zope.Public. Otherwise, the original trusted adapter factory should be used. May be I do not understand the problem correctly: IMO the permission declaration within the adapter directive has nothing to do with the permission declaration wihtin the class directive that mus be used if trusted adapters are invoked. Example KeyReference Adapter: adapter for=persistent.interfaces.IPersistent provides=.interfaces.IKeyReference factory=.persistent.KeyReferenceToPersistent trusted=y / class class=.persistent.KeyReferenceToPersistent require permission=zope.Public interface=.interfaces.IKeyReference / /class That's odd. I didn't notice the class directive. I don't know why the class directive is being used here. This is one of those rare cases where we have to make the security declaration on the adapter class. (In this case, it's because the adapters are pickled, which is also unusual.) It is not generally the case that you need to use separate security declarations with trusted adapters. I declare those additional class directive all the time if I'm using trusted adapters. IMO this kind of registration is the common pattern For example stephan richter uses this pattern within the wiki: adapter factory=.wikipage.WikiPageHierarchyAdapter provides=.interfaces.IWikiPageHierarchy for=.interfaces.IWikiPage trusted=true / class class=.wikipage.WikiPageHierarchyAdapter require permission=zwiki.ViewWikiPage attributes=parents path findChildren / require permission=zwiki.ReparentWikiPage attributes=reparent set_attributes=parents / /class permission declaration of the possible adapter instances (class ...). Therefore we can't switch the adapter factories within the adapter directive processing.. So, during the registration of an trusted adapter factory (adapter...) I can't do any prediction about the No, you can't do so implicitly. You can know about the permission used if a non-public permission was supplied. If a non-public permission is supplied, then it is reasonable to add the location. Otherwise, you should not try to guess. But the permission declaration within the adapter directive defines the permission that is nessecary to invoke the adapter factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. - How should we handle NullAdapters correctly? All the same I implemented your sugestion. The following question appears: What do you mean by NullAdapters? Are you talking about factories that return None? Id so, then, obviously, you should not proxy None. No, 'NullAdapter' are parameterless factories, for example x = IX() IMO this solution is pretty implicit and I do not like it at all. What solution? If you are talking about my suggestion to add a location to any adapter for whoch a non-public permission is specified, then I consider this far less impleicit than what you had before. It doesn't guess. If it knows a permission is required, it adds a location. Yes, the current solution in the branch. We should find a way to check the permission of the adapter instances inside a single trusted adapter factory: class IntelligentTrustedAdapterFactory(TrustedAdapterFactoryMixin): def _customize(self, adapter, context): p = ProxyFactory(adapter) checker = getChecker(p) if checker is CheckerPublic: return adapter else: return assertLocation(adapter, context) Questions: - performance - in the key refernce example it would be an dedicated checker. how could I guess if such an checker is Public? This is just too much magic. It has too many rules and is too slow. BTW, we are not just taking about trusted adapters. We are talking about *any* adapter for which a non-public permission is required. Yes, thats clear. We have two cases: 1. untrusted 2. trusted 1. if we register an untrusted adapter using the adapter directive we can make an correlation between adapter factory permission and adapter instance: if I have no permission to invoke the factory, I should not be able to use its instances. 2. if we
Re: [Zope3-dev] release numbering
IIRC, it was supposed to go: 2.7 - 2.8 - 2.9 - 3.0 (merge) X3.0 - X3.1 - 3.0 (merge) And that was the whole point of putting X in front of the 3, so you would know it was not really Zope 3.0, but X3. Jake -- http://www.ZopeZone.com Stephan Richter said: On Wednesday 20 April 2005 08:18, Florent Guillaume wrote: Martijn Faassen [EMAIL PROTECTED] wrote: The only non-standard part left in the release name if we drop the double 3 is the X. The X is a bit of a bother and will get us into trouble anyway eventually if a Zope 3 proper is ever released, as I can't see how we'd avoid situations where we'd have to say: Zope 3.1 is actually Zope X3.4 + Zope 2 compatibility extensions 0.7, which sounds less than ideal. I personally wouldn't mind if we just dropped the X. Yes, IMHO it'd be simpler to rename Zope X3.4 to Zope 3.4, and when the real Zope-3-with-Zope-2-compatibility arrives, either call it 3.6 or whatever is the current numbering, if it makes sense to have it in the same branch (which I understand may not be the case), or simply go to Zope 4. My suspicion is that the Zope 2 code base will eventually become the Zope 3 code base as all Zope X3 pieces get merged into it via Five. Once we completely fade out the Zope 2 code, we can call it Zope 4. Here is why I am saying this: - I do not believe that there will be ever a Zope 2 compatibility layer in Zope X3. The other way around seems more pragmatic and is currently done in Five. - I do not want Zope X3 cluttered with old Zope 2 code plus glue. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jake%40zopezone.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] release numbering
On Wednesday 20 April 2005 09:07, Jake wrote: 2.7 - 2.8 - 2.9 - 3.0 (merge) I think this will probably still happen. X3.0 - X3.1 - 3.0 (merge) I do not think this will happen. In fact, I am getting a strange feeling that we will have both, 3.x and X3.x, around for a long time, since some people want Zope 2 compatibility and others don't. I think that Zope 2 products just use too much of the internal Zope 2 API that they could ever work in a Zope 3 environment. And that was the whole point of putting X in front of the 3, so you would know it was not really Zope 3.0, but X3. Right, and I think this still holds. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/doc/security/SecurityTarget.txt - removed rst document in favor of latex
Gh Why oh why ? The document is now totally unreadable, except by reading a generated .ps or .pdf. That's not the way to go for documentation :( Florent PS: also the add/remove should be in the same svn changeset. Christian Theune [EMAIL PROTECTED] wrote: Log message for revision 30036: - removed rst document in favor of latex Changed: D Zope3/trunk/doc/security/SecurityTarget.txt -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] release numbering
Stephan Richter wrote: My suspicion is that the Zope 2 code base will eventually become the Zope 3 code base as all Zope X3 pieces get merged into it via Five. Once we completely fade out the Zope 2 code, we can call it Zope 4. +1 from me... So lets just call it Zope 3 for now... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/doc/security/SecurityTarget.txt - removed rst document in favor of latex
On Wednesday 20 April 2005 09:42, Florent Guillaume wrote: Gh Why oh why ? The document is now totally unreadable, except by reading a generated .ps or .pdf. That's not the way to go for documentation :( Remember that this document has to be read by an independent third party and they want nicely layouted pages, which I think they have a right to demand. ReST can just not provide that, but LaTeX can. Also, for simple (in terms of layout) documents like this, they are still readable in LaTeX source form. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] release numbering
Well, that sounds like a nightmare. So we might have X3.1, 3.0 being released at the same time? Talk about confusing to the outside world. This needs some rethinking. Jake -- http://www.ZopeZone.com Stephan Richter said: On Wednesday 20 April 2005 09:07, Jake wrote: 2.7 - 2.8 - 2.9 - 3.0 (merge) I think this will probably still happen. X3.0 - X3.1 - 3.0 (merge) I do not think this will happen. In fact, I am getting a strange feeling that we will have both, 3.x and X3.x, around for a long time, since some people want Zope 2 compatibility and others don't. I think that Zope 2 products just use too much of the internal Zope 2 API that they could ever work in a Zope 3 environment. And that was the whole point of putting X in front of the 3, so you would know it was not really Zope 3.0, but X3. Right, and I think this still holds. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] release numbering
On Wednesday 20 April 2005 10:36, Jake wrote: I agree. Drop the X when X3 has 2X support in it. Something you and Chris do not address is how to call the version of Zope 3 that will not have Zope 2 support. I, for one, and probably many others still want to have *pure* Zope 3 releases without Zope 2 mixed in. So for that time period (until Zope 2 coded is gone) we need two names for Zope 3 anyways. Maybe the X will eventually evolve to represent pure (like X - no Zope 2 here). :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/doc/security/SecurityTarget.txt - removed rst document in favor of latex
Hi, * Stephan Richter [EMAIL PROTECTED] [050420 15:59]: On Wednesday 20 April 2005 09:42, Florent Guillaume wrote: Gh Why oh why ? The document is now totally unreadable, except by reading a generated .ps or .pdf. That's not the way to go for documentation :( Ok. I should have made the change set come together. But I don't consider LaTeX to be unreadable. Remember that this document has to be read by an independent third party and they want nicely layouted pages, which I think they have a right to demand. ReST can just not provide that, but LaTeX can. Also, for simple (in terms of layout) documents like this, they are still readable in LaTeX source form. Right. Additionally we have a couple of large and complex tables around that ReST simply can't handle. It's less for having nice stuff than having a system that can actually handle it. Also, very likely the document is going to be split in multiple files because it's pretty large right now. Cheers, Christian -- Christian Theune - gocept gmbh co. kg - http://www.gocept.com [EMAIL PROTECTED] - phon: +49 3496 30 99 112 - fax: +49 3496 30 99 118 schalaunische strasse 6 - 06366 koethen - germany pgpa0TuUHW280.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Form framework, adapters and pau
Dominik Huber wrote: Jim Fulton wrote: Dominik Huber wrote: Excuse me late response I was busy that weekend... Jim Fulton wrote: I fixed that issue within the branch 'Zope3/branches/dominik-locatableadapters' Jim, could you take a look at that please. Thank you very much in advance! [...] We should *only* add the location if the adapter requires a permission other than zope public. Key rereferences don't require a permission and should not be location proxied. Doing so makes them unpicklable. We're going to need to fix the trusted adapter factory to do this correctly. I suggest we create a new kind of trusted adapter factory, perhaps LocatingTrustedAdapter factory that adds the location. This should only be used when the adapter directive specified a permission other than zope.Public. Otherwise, the original trusted adapter factory should be used. May be I do not understand the problem correctly: IMO the permission declaration within the adapter directive has nothing to do with the permission declaration wihtin the class directive that mus be used if trusted adapters are invoked. Example KeyReference Adapter: adapter for=persistent.interfaces.IPersistent provides=.interfaces.IKeyReference factory=.persistent.KeyReferenceToPersistent trusted=y / class class=.persistent.KeyReferenceToPersistent require permission=zope.Public interface=.interfaces.IKeyReference / /class That's odd. I didn't notice the class directive. I don't know why the class directive is being used here. This is one of those rare cases where we have to make the security declaration on the adapter class. (In this case, it's because the adapters are pickled, which is also unusual.) It is not generally the case that you need to use separate security declarations with trusted adapters. I declare those additional class directive all the time if I'm using trusted adapters. IMO this kind of registration is the common pattern For example stephan richter uses this pattern within the wiki: adapter factory=.wikipage.WikiPageHierarchyAdapter provides=.interfaces.IWikiPageHierarchy for=.interfaces.IWikiPage trusted=true / class class=.wikipage.WikiPageHierarchyAdapter require permission=zwiki.ViewWikiPage attributes=parents path findChildren / require permission=zwiki.ReparentWikiPage attributes=reparent set_attributes=parents / /class This isn't a pattern I've used. I think that there are lots of other, and perhaps better ways to do things. permission declaration of the possible adapter instances (class ...). Therefore we can't switch the adapter factories within the adapter directive processing.. So, during the registration of an trusted adapter factory (adapter...) I can't do any prediction about the No, you can't do so implicitly. You can know about the permission used if a non-public permission was supplied. If a non-public permission is supplied, then it is reasonable to add the location. Otherwise, you should not try to guess. But the permission declaration within the adapter directive defines the permission that is nessecary to invoke the adapter factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. Ah. You missunderstand. The permission is not the permission to to create the adapter. It's the permission necessary to use the provided interface on the adapter. - How should we handle NullAdapters correctly? All the same I implemented your sugestion. The following question appears: What do you mean by NullAdapters? Are you talking about factories that return None? Id so, then, obviously, you should not proxy None. No, 'NullAdapter' are parameterless factories, for example x = IX() OK, so these cannot be locations. IMO this solution is pretty implicit and I do not like it at all. What solution? If you are talking about my suggestion to add a location to any adapter for whoch a non-public permission is specified, then I consider this far less impleicit than what you had before. It doesn't guess. If it knows a permission is required, it adds a location. Yes, the current solution in the branch. OK, I'll take a look at that. ... BTW, we are not just taking about trusted adapters. We are talking about *any* adapter for which a non-public permission is required. Yes, thats clear. We have two cases: 1. untrusted 2. trusted 1. if we register an untrusted adapter using the adapter directive we can make an correlation between adapter factory permission and adapter instance: if I have no permission to invoke the factory, I should not be able to use its instances. Again, you are missunderstanding what the permission in the adapter directive is about. 2. if we register a trusted adapter
[Zope3-dev] Release numbering
I was hoping to stay out of this discussion, but ... 1. There will be many more releases of Zope 2, including 2-digit releases like 2.10, 2.11, etc. 2. The X in Zope 3X means that there is not yet support for Zope 2 transition. It's about setting expectations. I'm OK with dropping the X is someone else wants to manage this communication another way, but I'd rather not drop it. When we do finally have a story for transitioning Zope 2 apps to Zope 3: a) we will not renumber b) We don't know the nature of that transition support, so we should not worry now about whether it will clutter anything. 3. If I have anything to say about it, there will never be a Zope 4. :) 4. I'm OK with dropping the extra 3 in the release names. IMO either Zope X3.1.0 or Zope 3.0.1 are fine. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] release numbering
Hey, I think the most sane would be: Zope 2.8 - Zope 2.9 - Zope 2.x, for however many iterations it's necessary. Zope 2 will grow some Zope 3 forward compatibility with Five, but this depends on Five contributors. Right now, we're doing fairly well and we hope this keeps up. Zope X3.0 - Zope 3.1 - Zope 3.2 and so on, until we feel we want to declare a Zope 4.0. If you want to drop the X after 3.1 that's fine too, but I don't see a reason not to drop it now. The whole X3-3.0 is rather bizarre and confuses -- X3 is not a release name but a product name, but we have no real plans for a non-X 3 anyway..., but the mythical Zope 3 proper *is* the reason for having the 3 duplicated, as far as I can see. You need to communicate that the strategy changed, and that we won't have a Zope 3 ever that will offer Zope 2 backwards compatibility. We may want to supply some of that, but that should be a separate project, with its own release numbers. I'll call that project Six for now, as that's 2 times 3. :) It's probably better to correct this impression now than to wait indefinitely as: * people can prepare their migration strategy better, either by porting to Zope 3 straight or porting to Five first, and then later to Zope 3. Nobody will be waiting for magical components which will be offered by Six then, as that's complete vaporware now; there are no resources for it, nobody seems to really want to do it, etc. * we can drop the X and have a more sensible release naming pattern for Zope 3. * we have at least another strategy now and can point people to Five/Zope 2.8. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/doc/security/SecurityTarget.txt - removed rst document in favor of latex
Christian Theune wrote: Hi, * Stephan Richter [EMAIL PROTECTED] [050420 15:59]: On Wednesday 20 April 2005 09:42, Florent Guillaume wrote: Gh Why oh why ? The document is now totally unreadable, except by reading a generated .ps or .pdf. That's not the way to go for documentation :( Ok. I should have made the change set come together. But I don't consider LaTeX to be unreadable. That's because you're a LaTeX crack. :) Remember that this document has to be read by an independent third party and they want nicely layouted pages, which I think they have a right to demand. ReST can just not provide that, but LaTeX can. Also, for simple (in terms of layout) documents like this, they are still readable in LaTeX source form. Right. Additionally we have a couple of large and complex tables around that ReST simply can't handle. It's less for having nice stuff than having a system that can actually handle it. Also, very likely the document is going to be split in multiple files because it's pretty large right now. I admire LaTeX's typesetting capabilities. I despise of LaTeX because of its missing content model. Nearly all semantic value of a document's contents is lost into some cryptic language that isn't even about semantics but about layout. Having said that, I fully understand that people who work on complicated things (and the CC spec demands a certain layout from this document, so even layouting this *is* a complicated task) chose the tools that help them and that they can work with best. Btw, for my book I used DocBook XML which is not about layout at all but provides a sane and easily parsable (it's XML!) content model. Using XLST you can go anywhere, for example PDF (first to xslt-fo and then with FOP or similar to PDF) or even to LaTeX (which is what I did for the book). But, again, it's a matter of taste, too. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: release numbering
Tres, I get every mail from you twice. One header says: Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])by mail.zope.org (Postfix) with ESMTP id 0513920334D the other: Received: from smtp.zope.com (smtp.zope.com [206.16.200.4]) by mail.zope.org (Postfix) with ESMTP id A382520334D Is this necessary? Egon Am 20 Apr 2005 um 12:17 hat Tres Seaver geschrieben: Jake wrote: Ok... So let me get this right. 2.7.x - 2.8.x - 2.9.x - 2.10.x - 2.11.x ? I am sorry, but that is really confusing, but not as confusing throwing in X3.0 and 3.0 and maybe 4.0 (way too early in my opinion). I mean, I am just a simple guy, building simple sites with Zope, but all of that just seems to confuse the issue (think SNL Caveman Lawyer) Now, add to that CMF 1.4.8 and CMF 1.5.1 (both new releases) and Plone 2 and what you have is a nightmare for any new users or someone who doesn't want to use a chart to figure out what to install. Oh, and Python as well. 2.3.4 - 2.4, etc. Independently released components *have* to follow this pattern; otherwise you cannot manage people's expectations, including backward and forward compatibility. People who run applications in production need support releases (the third-dots) in order to get bugfixes without introducing disruptive / buggy new features. People who don't want to think about such issues need to use distributions which explicitly call out the versions of the subpackages they use. The Plone installer does this; the various Debian packages try to as well. Tres. - -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCZoCEGqWXf00rNCgRAn2YAKCUKVcV03gX2S8+XtL+sHGYSskwcgCeMJRP +KZNzMcBizW1QI81AsSKWjA= =krY4 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/e.frerich%40nord-com.ne t ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Form framework, adapters and pau
Jim Fulton wrote: It is not generally the case that you need to use separate security declarations with trusted adapters. I declare those additional class directive all the time if I'm using trusted adapters. IMO this kind of registration is the common pattern For example stephan richter uses this pattern within the wiki: adapter factory=.wikipage.WikiPageHierarchyAdapter provides=.interfaces.IWikiPageHierarchy for=.interfaces.IWikiPage trusted=true / class class=.wikipage.WikiPageHierarchyAdapter require permission=zwiki.ViewWikiPage attributes=parents path findChildren / require permission=zwiki.ReparentWikiPage attributes=reparent set_attributes=parents / /class This isn't a pattern I've used. I think that there are lots of other, and perhaps better ways to do things. We have the use case that we adapt a lot of additional functionalities to a pretty stupid content. Each additional functionality has differentiated permission-sets comparable to regular content objects. For example different permissions for reading and setting attributes of the provided interface. So at the moment I do not see any another possibility to set those permissions than using an additional class.. directive. All 'bugs' related to this issue (that I'm aware of) including the zwiki-bug that was reported uses the above pattern and breaks. The reason for my branch was to solve this kind problem :) But the permission declaration within the adapter directive defines the permission that is nessecary to invoke the adapter factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. It's implict to asume that the instance by a certain factory desires the same permissions like the invocationg of the factory. Ah. You missunderstand. The permission is not the permission to to create the adapter. It's the permission necessary to use the provided interface on the adapter. Ok, missleading naming _protectedFactory within the adapter handler ;) But what happens in the following case? 1. the resulting adapter requires any.Permission 2. the resulting adapter requires the permission defined by class.. adapter factory=.wikipage.MailSubscriptions provides=.interfaces.IMailSubscriptions for=.interfaces.IWiki *permission=any.Permission* trusted=true / class class=.wikipage.MailSubscriptions require permission=zwiki.EditWikiPage attributes=getSubscriptions / require permission=zwiki.EditWikiPage attributes=addSubscriptions removeSubscriptions / /class IMO case 2. happens (experimental verification only, I do not understand all magics within _protectedFactory). The status-quo is pretty implicit too. I looking forward to explain such stuff to newbies ;) - How should we handle NullAdapters correctly? All the same I implemented your sugestion. The following question appears: What do you mean by NullAdapters? Are you talking about factories that return None? Id so, then, obviously, you should not proxy None. No, 'NullAdapter' are parameterless factories, for example x = IX() OK, so these cannot be locations. Yup, that my interpretation too. So those null adapters are global object with or without dedicated permission that can't be invoke by any local principal. What's the use cases for such object? IMO this solution is pretty implicit and I do not like it at all. What solution? If you are talking about my suggestion to add a location to any adapter for whoch a non-public permission is specified, then I consider this far less impleicit than what you had before. It doesn't guess. If it knows a permission is required, it adds a location. Yes, the current solution in the branch. OK, I'll take a look at that. Excuse me, but under those circumstances I have to retract my solution. IMO it will be not that what you are looking for... :( 2. if we register a trusted adapter this correlation breaks because the adapter instance itself might have highly differented security-permission (compare class...) In a complex situation like this, I suggest it's better to have people make their adapters locations in Python. It might more complex than a single permission, but its every day life. I only try to simplify independently if its complex or not :) So 1 is easy to handle in the adapter directive, but 2 not. The suggestion above tries to respect your requirments, but also allow to use. the registration pattern adapter... and class.. which is failry common and explicit. The current solution in the branch is not able to handle 2. correctly. Stephan's zwiki example: - The adapter directive has no permission (which is ok, because he doesn't need to protect the invocation of the adapter factory itself). - In that case the locating trusted adapter factory is not invoked within the registration. -
Re: [Zope3-dev] Form framework, adapters and pau
addendum... I tried to implement your solution [Revision 30053], but then I noticed the following problems: 1. no permission (None) and zope.Public within a trusted adapter registration provokes different behavior (example below KeyReferenceToPersistent) 2. the zwiki bug and my related implementations bugs still exists, because regularly folks that registering trusted adapters using adapter... and class...do not set any permission within adapter.., but only within class (That kind of permission declaration causes the invocation of the regular-trusted-adapter-factory.) Therefore I reverted 'your' solution back to the first implementation [Revision 30059, 30060]. I assumed that it will be less evil to do without two different trusted adapters factories (regular (zope.Public and None) and the locating one (other permission)). + we can fix the zwiki bug and related implementations bugs easily + we can omit the unclear permission-precedence if the adapter... class... pattern is used for trusted adapters o the untrusted adapters with no location get only location-proxied if permission is not None or zope.Public - we have to derive the KeyReferenceToPersistent adapter from Location to omit the pickle error Just now I added some optimization [30067]: Trusted adapters get regularly only protected if the adapted object is protected. Therefore we can omit the location proxy in cases where the trusted adapters get not protected. I wrote an other adapter factory (PartiallyLocatingTrustedAdapterFactory) which is only using location proxies if the adapter is protected and does not provide ILocation. If ILocation is provided the parent is still set if None. And this that solves the KeyRefernceToPersistent problem too. [revison 30068] Within the current branch there are the three adapter factories: - PartiallyLocatingTrustedAdapterFactory - LocatingTrustedAdapterFactory - TrustedAdapterFactory You can easily switch them within adapter() directive handler and look for the optimum. After all I would prefer the current solution. But I know the decision is up to you. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Building standalone ZPT from Zope 3 using zpkgtools
Hi, Does anyone know how to build a standalone ZPT package from Zope 3 using zpkgtools? To make matters more fun, it's on Windows ;-) I got this far: C:\LocalSVN\zpkgtoolsbin\zpkg.py --resource-map=svn://svn.zope.org/repos/main/ReleaseSupport/trunk/PackageMaps/zope3.map -ca ZPT Traceback (most recent call last): File C:\LocalSVN\zpkgtools\bin\zpkg.py, line 36, in ? sys.exit(app.main()) File C:\LocalSVN\zpkgtools\zpkgtools\app.py, line 655, in main app = BuilderApplication(options) File C:\LocalSVN\zpkgtools\zpkgtools\app.py, line 89, in __init__ Application.__init__(self, options) File C:\LocalSVN\zpkgtools\zpkgtools\app.py, line 74, in __init__ cf.finalize() File C:\LocalSVN\zpkgtools\zpkgtools\config.py, line 78, in finalize mapping=self.locations) File C:\LocalSVN\zpkgtools\zpkgtools\locationmap.py, line 238, in fromPathOr Url f = loader.open(path, rU) File C:\LocalSVN\zpkgtools\zpkgtools\loader.py, line 66, in open path = loader.load(url) File C:\LocalSVN\zpkgtools\zpkgtools\loader.py, line 180, in load path = method(url) File C:\LocalSVN\zpkgtools\zpkgtools\loader.py, line 266, in load_svn path = self.svnloader.load(url, tmp) File C:\LocalSVN\zpkgtools\zpkgtools\svnloader.py, line 335, in load raise SubversionLoadingError(url, 1) zpkgtools.svnloader.SubversionLoadingError: could not load from svn://svn.zope.o rg/repos/main/ReleaseSupport/trunk/PackageMaps/zope3.map (exit code 1) Any ideas? cheers, Chris ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
