[Zope-dev] ZPatterns design questions

[Phillip J. Eby]

At 09:49 PM 10/4/00 -0700, Michael Bernstein wrote:
>
>While I wouldn't say that there has been an actual 'paradigm
>shift' between the original RIPP presentation and ZPatterns,

What's happened is that there's been a lot of "implementation shift".  The
goals of RIPP have never changed, but they are far from being all available
in convenient form in the ZPatterns implementation of that model.  That's
why ZPatterns' version number is so low - we've implemented less than half
of RIPP at this point.  Meanwhile, along the way we came up with better
ways to do things than we had in our first round of ideas.

For example, before we thought of Attribute Providers, we assumed that
PropertyHandlers were necessary to implement RIPP designs successfully.
And before we thought of SkinScript, we assumed that AttributeProviders
would be custom written for different types of databases.  And so on.  This
has caused a lot of shifts in the details of our recommended implementation
practices, even though the design philosophy for RIPP applications has not
actually changed in the slightest.  All that's happened is that
implementing such applications is now far easier than Ty or I would have
dreamed possible a year ago when we began to formulate the RIPP concepts.
(Even though we still haven't got all of RIPP available and occasionally
suffer for the lack of some bits like PropertyHandlers.)


>I'm sufficiently confused at this point to ask for an
>explanation (with definitions and a *simple* example) of
>your current thoughts on separating 'domain code' from
>'implementation code', both of which still need to be
>separated from 'presentation code' (DTML interfaces), unless
>I'm mistaken. Please assume I'm asking a lot of 'why'

>questions along the way.

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, in the DropZone
example, the billing sub-application would probably delegate the user
interface for presenting a "find customer" form to the Customers
specialist, which would contain an appropriate HTML snippet.  "Out of the
box", that specialist would contain a default find-customer form provided
by the creator of the billing framework, and it would be the job of the
application integrator to override it to fit the overall application.

Our current practice is to place both domain and presentation logic in
ZClasses, 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.)

We have not yet released any actual frameworks based on ZPatterns, but if
we were to do so, we would probably also define many UI methods as
"class_default_for_X" so that end users could override them with a Class
Extender in their Rack or Specialist, without having to subclass our
classes.  We do not have any "best practice" recommendations in this area
as yet, since we haven't had to tackle a project of this nature so far.


>I'm familiar with the convention of separating 'data' from
>'business logic' from 'presentation logic', but this new
>four-way separation (storage, domain, implementation, UI) is
>confusing the heck out of me.

There's really only three: Presentation, Domain, and Implementation.  These
largely correspond to Coad's UI, PD, and DM/SI, although we're also mixing
UI snippets into the DM/SI part, simply because that's the locale for
customization/integration.  (In general, we do not assume that placing more
than one kind of thing together as neighbors in the same place is a
problem.  It's what things *reference* that makes their implementation
clean or dirty, not necessarily who their neighbors are in the Zope object
tree.)


>I know that both of you (Phillip and Ty)  are very busy
>right now, but could you perhaps give us a few short
>installments? Starting at the beginning (wherever that is),
>of course.

How's the above for a beginning?