[Zope] Multi tier partitioning meaningful in some Zope apps ?

[Greg Ward]

On 08 December 1999, Nitin Borwankar said:
> Does the foll "application architecture" make sense
> 
> Function        Zope                 Tier                (analogous)
> ========        ===============   ==============         ===========
> 
> Visual          -> DTML-Docs      -> Light Middleware    (JSP-like
> visual+some logic)
> 
> Biz Logic       -> DTML-methods   -> Heavy Middleware    (EJB-like
> non-visual all logic)

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

        Greg

-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913