"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 sentence?
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 frameworks. 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.
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.