[Zope-dev] ZPatterns design questions

Phillip J. Eby pje@telecommunity.com
Fri, 06 Oct 2000 18:51:28 -0500


At 07:59 AM 10/5/00 -0700, Michael Bernstein wrote:
>"Phillip J. Eby" wrote:
>> 
>> Domain logic: methods which implement the basic behavior of an object, by
>> manipulating its attributes and by calling methods on itself or other
>> objects.  (Including delegation to a Specialist, its own or another.)
>> 
>> Presentation logic: "view" methods which implement user interface by
>> displaying object attributes and/or the results of either presentation or
>> domain methods, and "controller/view" methods which call domain logic
>> methods and display results.
>> 
>> Implementation logic: All of the code and objects contained in a Specialist
>> which map between the domain model of an object and its physical storage
>> implementation(s).  This category can be further subdivided into data
>> management implementation, and UI implementation.
>> 
>> DM implementation deals with storing and retrieving objects and associated
>> data, and firing off of implementation rules (e.g. ensure that all objects
>> which meet such-and-such criteria are cataloged in catalog Foo).
>> 
>> UI implementation deals with providing snippets suitable for use by
>> collaborating classes and/or specialists.  For example, [snip]
>
>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.


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.

As a counter-example to the above, consider Zope's local roles UI.  When
you assign local roles, Zope goes to the specialist "acl_users" and asks it
for all possible users, then displays them in a dropdown list.  While we
could do the same thing in our Task/Assignees example (i.e. have Task just
display a dropdown list of all Assignees), this is bad because it does not
scale well.  What if our Task object is used for a company intranet where
there are 10,000 employees?  What if assignees can be either employees or
outside vendors, and they are looked up differently?

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.

This is what UI implementation logic is for, and it's an important part of
the rationale for the existence of Specialists (formerly known as
Implementors).


>> Our current practice is to place both domain and presentation logic in
>> ZClasses, [snip]
>
>Do domain and presentation logic methods go into the *same*
>ZClass, or separate ones (I realize that this may be a
>stupid question)?

Same one.  We assume that it is more useful/important for a framework to
offer ready-to-use classes than lots of mixins.

>> dropping down to ExternalMethods or Python bases for the ZClasses
>> when domain logic requires things you can't do in DTML or PythonMethods.
>> Domain and presentation logic are kept to seperate methods, so that domain
>> logic methods can be re-used for XML-RPC or other programmatic interfaces.
>> Presentation is usually done in a flexible way, relying upon UI
>> implementation hooks where sensible.  (Since objects under a specialist
>> acquire from the specialist, it's easy to hook to a specialist-level
>> utility method.)
>

>I understood what you were saying until the parentheses.
>Could you repeat that part in a different way?

Objects retrieved from a Specialist (in general) have the Specialist as
their aq_parent.  This means that if an object wants to use UI
implementation snippets from its own Specialist, it can do so without
having to explicitly name the specialist.  This is useful for two kinds of
snippets: 1) lookup snippets as described earlier, and 2) configuration
snippets, ala standard_html_header, which can be used to customize the look
of the presentation logic.


>> 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.


>Great! Now I need a really stupid-simple example. Something
>that could have been implemented trivially by using Zope's
>built in objects, maybe a ZClass, and a bit of DTML, like a
>list of press releases, or a FAQ, or a company directory.
>Something *really* simple, so I can see how it's done with
>ZPatterns.

I think Steve Spicklemire's tackling this one.  I'll have a look at what
he's done and see if I have any nits to pick before trying to do one of my
own.  :)