[Zope-dev] ZPatterns design questions

[Phillip J. Eby]

At 12:50 PM 10/7/00 -0700, Michael Bernstein wrote:
>"Phillip J. Eby" wrote:
>> 
>> Presentation logic lives with an object's class, and deals with what that
>> object knows about presenting itself.  UI implementation is "glue"
>> presentation that lives in a Specialist for use by any object that needs to
>> present UI related to objects of the kind the Specialist handles.  The
>> terms used here are "official" terminology with precise definitions, btw.
>> I am just trying to answer your questions as best I know how.
>
>I'm not sure, but did you mean 'are not' in that last
>sentence?

Whoops.  :(  Yes, you're correct, I lost the 'not' somewhere along the way
there.


>Here is where my 'Specialist/Generalist' confusion came
>from. It seems to me, that the simple implementation (you
>might also call it the default implementation) for the
>selector UI in your example should be contained in a
>'Generalist' object that could be overridden by a
>'Specialist'. This would help make crystal clear the line
>between Presentation Logic and Implementation UI, and would
>also serve as a useful starting point for creating the
>overriding methods in the 'Specialist' by the framework
>customizer.

Hm.  It seems to me to add too many entities without any real advantages.
It's straightforward to have overrideable default implementations in a
Specialist - note LoginManager's login, logout, and forbidden pages, which
are UI snippets of this sort.


>> Okay, you've got me there.  I tend not to think of it that way, if only
>> because there are many things less than satisfactory about its current
>> state of implementation.  For example, if we had it to do over again, I
>> would re-work the internal API so that roles, domains, authentication,
>> etc., could be controlled by plug-ins on the user sources.  At that point
>> there would be no need for different kinds of user sources, as they would
>> all be fully generic.  But anyway, I digress.
>

>In light of my own dificulties in adding SMB authentication
>to PersistentUserSouce.py, and Bill Andersons dificulties
>with password encryption on some Unices, I think that this
>would be a *very* worthwhile effort. Such a project might
>also give you the mandate to get DC to fix the Zope internal
>acl_users interfaces that were getting in your way.
>
>How large of a project would this be?

Not very hard, I think.  Basically I think we'd warp the "Data Plug-Ins"
plug-in group on UserSource to allow what I'll call "authorization
plug-ins" to be included.  And, we'd complement that with some of the work
Ty's already done on mapping roles, domains, etc. back onto plain object
attributes so that you can just use regular attribute providers or
SkinScript to compute them.  I'm not sure, but I think I recall that we
even came up with a way to securely manage a password attribute, which we
needed for one of our own applications a month or two ago.