"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. Thanks, Michael Bernstein.