"Phillip J. Eby" wrote:
> >How (and why) do you distinguish between UI implementation
> >and presentation logic?
> 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

> An example of presentation logic would be a method which displays a form to
> perform some action on the object.  E.g., let's say we have a "Task" object
> with an "Assign To" form.  Tasks are assigned to Assignees, but in a given
> application, there could be many possible kinds of Assignees and the means
> of selecting an Assignee is context-dependent.  Thus, a Task's presentation
> logic cannot implement such a thing directly; it must ask the Assignees
> specialist for a code snippet (UI implementation) that displays an assignee
> selection sub-form within its "Assign To" form.
> [snip]
> The Assignees specialist is responsible for providing an appropriate UI
> implementation (hence the name) for this operation.  It could provide a
> dropdown list, a type-in box with a button to pop up a search window that
> lets you search the employee directory, or any number of other possible
> implementations that would get the necessary data back to the assignment
> method once the form was submitted.  We could include a simple
> implementation with our task management framework, and the application
> integrator would override it if needed for their situation.

Thanks, this is starting to make a lot of sense WRT reusable

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

> >> We have not yet released any actual frameworks based on ZPatterns, [snip]
> >
> >Isn't LoginManager a framework?
> 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?

Thanks for your patience in answering my questions. I think
I'm getting a good understanding of this approach, but I'm
still working on internalizing it.

Michael Bernstein.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to