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
__
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
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?
Whether these user objects are placed in t
Philipp von Weitershausen wrote:
Steve Alexander wrote:
[snip]
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
> 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 obj
> 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 lis
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
> 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
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
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
Shane Hathaway wrote:
Steve Alexander wrote:
In Launchpad, request.principal is not used by the application
programmers. It is used only by the authentication, authorization and
publication machinery. The machinery looks up a Person (an application
domain object) for the current principal (th
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 refactoring
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()
>>
13 matches
Mail list logo
