[Zope3-dev] Re: tiny patch to zope.server.interfaces.IStreamConsumer
Chad Whitacre wrote: P.S. I tried to file this as a bug+solution in the Z3d Issue Collector, but when I submitted the New Issue form, I was given a login screen. After several login attempts, I went through the forgotten password process, but never received an email. The only other thing I can think of is that my email address on record is bad, but I don't know how to verify or fix that. For the password issue please send a mail to [EMAIL PROTECTED] including your zope.org memberId. I'll try to help you then. Michael -- http://zope.org/Members/d2m http://planetzope.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] RFC: Rename principal to participant, my 2p ;-)
Philipp von Weitershausen wrote: - BUT, given that it's a big change and likely invalidates a lot of dead tree material, I'd suggest we just stick with principal and be done with it ;-) If that last point were the doctrine by which previous refactorings had to be undertaken (e.g. the refactoring of the Component Architecture), we would still be stuck with services and other antiquated concepts. I'd hardly call them antiquated. I agree that early on in a project, the freedom to change and refactor freely is great, but at some point, when you want lots of people to adopt your project, you need to slow down and stop making wide ranging changes unless you really really need to. In this case, it's a largely cosmetic change that doesn't do anything except invalidate a whole load of documentation ;-) cheers, 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
[Zope3-dev] Re: most specific interface?
Jean-Marc Orliaguet wrote: Philipp von Weitershausen wrote: Jean-Marc Orliaguet wrote: is the order of the list of interfaces implemented by an object subject to internal changes? I have identified the need for such a pattern: iface = object.interface() with: class someObject(object): implements(IMainInterface, ISecondaryInterface, ...) def interface(): Return the most specific interface implemented by the element. return list(providedBy(self))[0] to be able in that case to get access to the first interface implemented by an object, as a sort of main object type. We usually do this differently. If some interfaces are special types (e.g. IFile is a content type) then we have this interface provide ISpecialType (e.g. IFile provides IContentType). ISpecialType is an interface extending IInterface. Then, no matter where in the list of provided interfaces the type is, it can be fetch with queryType. Let's take the IFile example from above and set it up as a content type: from zope.app.content.interfaces import IContentType from zope.app.file.interfaces import IFile from zope.interface import directlyProvides directlyProvides(IFile, IContentType) ... Philipp I see, this is clever, and it simplifies the code. the idea is that you define as many categories as you need: IMetaType, ISomeCategory, IWidgetType ... and you create relations between interfaces with: directlyProvides(IFile, IContentType) Exactly. as if you had a relation tool, then every object that implements IFile (no matter in what position) will have the IFile content type? Yes. But where do you put the 'directlyProvides' statement? Like Jim said, anywhere in Python code. The fact that IFile directly provides IContentType isn't bound to any class statement. The typical case, though, is to use ZCML, as Jim also mentioned: interface interface=.interfaces.IFile type=zope.app.content.interfaces.IContentType / See the beginning of chapter 5 (page 55) of my book for a further explanation and an example from the interpreter shell. Philipp 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] RFC: Rename principal to participant, my 2p ;-)
Chris Withers wrote: Philipp von Weitershausen wrote: - BUT, given that it's a big change and likely invalidates a lot of dead tree material, I'd suggest we just stick with principal and be done with it ;-) If that last point were the doctrine by which previous refactorings had to be undertaken (e.g. the refactoring of the Component Architecture), we would still be stuck with services and other antiquated concepts. I'd hardly call them antiquated. I agree that early on in a project, the freedom to change and refactor freely is great, but at some point, when you want lots of people to adopt your project, you need to slow down and stop making wide ranging changes unless you really really need to. This attitude has left us with Zope 2 where it is. I really hope that we Zope 3 developers won't ever be too tired to tackle even serious refactorings -- if they work out for the better, of course. However, when I look at recent refactorings, and even just the fact that deprecating things is easy and much less pain that it was before, thanks to Stephan's zope.deprecation, I'm pretty confident and needn't worry. In this case, it's a largely cosmetic change that doesn't do anything except invalidate a whole load of documentation ;-) You're right about this being largely cosmetic. But I disagree that this means it's not worth to invalidate lots of docs. The reason I proposed the name change was for the sake of docs. So, changing the docs was actually one of my intentions :). Anyway, I think the discussion has reached a point where I can safely withdraw my proposal. Thanks to everyone for their valuable comments. I must say I feel better about principal now. Not the word itself, but the way we use it and the fact that it's used by others. Proper translations remain to be found... 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] RFC: Rename principal to participant
Steve Alexander wrote: I think so too. But I whould not try to explain a PAU (pluggable authentication utility) without to use the word principal. I think using the words user or participant for a principal in this case is not a good idea. Perhaps the scope of the PUA can be extended to have a plug-in factory for User objects, and to make the current User easily available inside page templates and other presentation code. People who wish to use[1] the PUA would define their own User class, which could be as simple as taking the principal id, but would often be more complex according to the needs of their application. Some abstractions to deal with user objects (which for instance can have an email address to name a common case) in Zope 3 would indeed be useful. I found I had to build my own already. Note that such user objects (or group objects) in applications are frequently content objects and are accessible through content space. I think in Zope 2 terms this entity may be called 'member'... The wrong way to go about this is to store user information somewhere under ++etc++, as that isn't content space in my book and I don't want to expose end users (that need to do user management sometimes) to anything in ++etc++. (it's okay to store low-level user information in ++etc++, as at is now, but no extensible user info with extra information like email addresses, etc, I think). 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: RFC: Rename principal to participant
Steve Alexander wrote: I think so too. But I whould not try to explain a PAU (pluggable authentication utility) without to use the word principal. I think using the words user or participant for a principal in this case is not a good idea. Perhaps the scope of the PUA can be extended to have a plug-in factory for User objects, and to make the current User easily available inside page templates and other presentation code. People who wish to use[1] the PUA would define their own User class, which could be as simple as taking the principal id, but would often be more complex according to the needs of their application. Interesting. It looks to me like you're calling a User object what the CMF calls a Member. Would you say that the existence of such a concept in PAU should make principal annotation a unnecessary, if not even deprecated? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Rename principal to participant
Interesting. It looks to me like you're calling a User object what the CMF calls a Member. Sure. Does the CMF have any users who aren't members? Would you say that the existence of such a concept in PAU should make principal annotation a unnecessary, if not even deprecated? I don't really see the point of principal annotation as a special thing. Being able to annotate things is good. I'm not sure principals should be a special case either way. Can you annotate permissions? I don't think systems should be built relying on being able to annotate principals. That sounds kind of implicit. I'd rather see a first class User concept. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Rename principal to participant
Steve Alexander wrote: Interesting. It looks to me like you're calling a User object what the CMF calls a Member. Sure. Does the CMF have any users who aren't members? Well, I think so. At least the CMF has different objects for members than for users (the former come from the CMF Member tool, the latter from a standard Zope user folder). That distinction was it that I was reminded of when you said you wanted separate User objects. Would you say that the existence of such a concept in PAU should make principal annotation a unnecessary, if not even deprecated? I don't really see the point of principal annotation as a special thing. Being able to annotate things is good. I'm not sure principals should be a special case either way. Can you annotate permissions? Ok, I see your point :). My question was actually positioned with the PrincipalAnnotation utility in mind and whether you think that it still is needed once you have first class User objects. I don't think systems should be built relying on being able to annotate principals. That sounds kind of implicit. I'd rather see a first class User concept. That was more the statement I was looking for. That, and a statement regarding the PrincipalAnnotation utility in particular... 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] RFC: Rename principal to participant
If not that, we can at least make the weaker case that no Zope 3 *UI* user (whether it's the ZMI or something built on top of it) ordinarily should have to know about 'principals'. I agree with that. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Rename principal to participant
Note that such user objects (or group objects) in applications are frequently content objects and are accessible through content space. I think in Zope 2 terms this entity may be called 'member'... In Launchpad, we have a Person table in the database. Data from there are converted into objects, and used in the application. These are Person objects. The user for a given request is a Person object. It is the Person object representing the user who is identified as using the system in that thread at that time. Here we go... some docs from the Launchpad wiki: https://wiki.launchpad.canonical.com/UserPersonPrincipal The wrong way to go about this is to store user information somewhere under ++etc++, Sorry for the crudeness, but ++etc++ makes me want to barf. Have an etc stuff web server running on a different port, with a different root traversal resource. Don't make it part of the web app that you show to users. You'll just want to turn it off later on. as that isn't content space in my book and I don't want to expose end users (that need to do user management sometimes) to anything in ++etc++. (it's okay to store low-level user information in ++etc++, as at is now, but no extensible user info with extra information like email addresses, etc, I think). -- Steve Alexander ___ 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: RFC: Rename principal to participant
Uwe Oestermeier wrote: Martijn Faassen wrote: I ended up creating a first class User object too. See also my note about being able to access these in content space. The same holds for my project. Shouldn't they be part of the framework if so many applications need them? I smell a proposal :). ___ 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: RFC: Rename principal to participant
Philipp von Weitershausen wrote: I smell a proposal :). I cannot promise to write this proposal in the next two weeks, but I will try to write one before the NeckarSprint (6-9. Oct) takes place. The implementation of user objects would be a manageable sprint task. -- Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
