"Phillip J. Eby" wrote:
> 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. [snip] - we've
> implemented less than half of RIPP at this point.

Ok, That's what's been confusing me. I was thinking that at
least some of the missing functionality was due to a change
of goals.

> >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, [snip]

How (and why) do you distinguish between UI implementation
and presentation logic?

> 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)?

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

> We have not yet released any actual frameworks based on ZPatterns, [snip]

Isn't LoginManager a framework?

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

Ok. That makes some more sense. (still working on the Zen,

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

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


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