[Zope-dev] Re: [Zope] Multi tier partitioning meaningful in some Zope apps ?

[Patrick Phalen]

[Moved to ZOPE-DEV for hopefully further discussion]

[Greg Ward, on Thu, 09 Dec 1999]
:: My preference -- after only a few weeks with Zope, mind you -- is to put
:: as little logic as possible in DTML.  Restrict it to display/user
:: interface logic; anything more than that, and you'll be in
:: teeth-gnashing-land pretty quickly.  It's not a general programming
:: language; that should be obvious from the fact that it doesn't have
:: variable assignment (except in the limited "let" sense).
:: 
:: Business logic should be coded in Python, and interfaced via External
:: Methods.  (I guess you could use these newfangled Python Method
:: thingies, but I want *more* in the filesystem and *less* in ZODB, thank-
:: you-very-much.)  Note: *interfaced* via External Methods; I like my
:: External Methods to be fairly short little things that deal with stuff
:: like translating Web/HTTP/Zope pecularities to the more general world
:: addressed by my back-end Python classes.
:: 
:: > Data Access     -> ZSQL-methods   -> Data API            (JDBC-like)
:: 
:: Hmmm.  It's entirely possible that data access could/should be managed
:: by just making all those back-end Python classes inherit from the ZODB
:: Persistent class -- bang! no more SQL to worry about.  That's an awfully
:: big leap of faith to take, though...


This is worth further discussion, expansion, IMO.

I'm curious if you (Greg) are finding that your External Methods that
"deal with stuff like translating Web/HTTP/Zope peculiarities" are
shaping up to be reusable code. I'd also like to see an example or two
to see how you're approaching this, if possible. I wonder if we could
have a few base classes which would take care of the majority of these
situations.

I'd certainly welcome further thoughts/comments from others on this
approach, particularly pros/cons on the "big leap of faith" part in the
last paragraph.