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?