All, After struggling for a while with all of the parts of the Zope framework in all it's complex and stark beauty a light seems to have gone off inside. 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) Data Access -> ZSQL-methods -> Data API (JDBC-like) This stretches the truth somewhat especially in comparison to Java technologies. (EJB focuses on transactions a lot, with the intention of making them transparent). And of course Zope offers other component technologies that this does not encompass, but is this a viable way of a) Thinking about application architecture for the first set of apps while learning Zope ? b) Actually developing apps ? c) Partitioning tasks for distribution across skill sets ? I understand this will need addition usage conventions so as to "reduce the degrees of freedom" in Zope to a manageable subset for this "methodology" - such as :- "Use REQUEST['fieldname'] to extract data in the middle-tier and then call ZSQL, rather than using REQUEST['fieldname'] directly in the ZSQLMethod." The latter would make it a two-tier application which also may be useful structure for smaller apps where two of the tiers could be collapsed together. I would also welcome how/whether this "n-tier" partitioning would also be useful for thinking about the internals of Products and ZClasses when designing them. In the case of Products and ZClasses all layers may not be present. e.g. the ZODBC DA is primarily Data API layer only (management interface not withstanding). Comments/debate/flames invited Nitin Borwankar nitin@borwankar.com