"Phillip J. Eby" wrote:
> Ty and I use ZClasses because you can see your changes much more quickly
> than if you have to restart Zope.  Basing your ZClasses on DataSkin makes
> the limitations pretty much disappear, from our point of view, because we
> never put any actual "implementation" code in our ZClasses: just domain
> logic, property sheets and UI (DTML) methods.  All the actual mapping
> to/from data storage is carried out in the appropriate Rack or Specialist,
> neatly seperated.  Occasionally we need an ExternalMethod in either the
> ZClass or the Specialist, but these are getting rarer as we find ways to
> create method-like helper objects that can be added through the Zope UI to
> accomplish common tasks.  In general, we prefer that Python written outside
> of PythonMethods be re-usable for a variety of projects rather than a
> one-up for a specific application.  YMMV.  :)

While I wouldn't say that there has been an actual 'paradigm
shift' between the original RIPP presentation and ZPatterns,
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.

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.

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.


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