However, the idea of seperating "business logic" from "presentation" sounds good. Presumably Python methods represent "business logic" and dtml methods are the presentation layer. Making it easier to use "external procedures" might be a big win (no flames on PythonMethods vs. External Methods, ok).
ASP's and COM components aren't editable through the web in the same way that DTML Methods and Friends are, and therefor aren't exposed to the same security risks. (And we all know that Microsoft is the queen of good security. *Coff!* :-). But granted Microsoft also has fairly decent development tools and enough kludgy server-side extensions (frontpage extensions, their hack of WebDAV) that may ease this somewhat. Having DTML Methods as the main way of scripting being open through the web interface, it can become a little too easy to expect to do everything in this situation. In essence, Zope Products are to Zope what COM components are to MS. Products are full Python classes that support an interface to be published through the web and also accessed through DTML Scripting, as well as behaving to the Zope security model. Granted writing a Product is not as easy as writing some DTML Methods, or even External Methods; but writing a COM object isn't a cakewalk either. But again, MS has the development tools and dancing paperclips and wizards to supposedly help the developer. ZClasses, when used with External Methods or subclassing from disk based Products, are another good way of seperating business logic. Business Logic, being as important as it is, is not something I would want to write in DTML, and probably not even in PythonMethods due to security restrictions. Basically if you're looking for similarity between Zope and ASP/COM in this aspect, ASP Pages are basically scripting COM objects. DTML Scripting is basically scripting Zope objects, which are in the form of the basic Products (DTML Methods, Documents, Folders (ie <dtml-call "SomeFolder.manage_changeProperties(foo='bar')">)), ZClass Instances, etc. But also remember that ASP/COM doesn't have Acquisition, web-object traversal, ZODB, Zope Security, the through-the-web near-total-management-without-requiring-ActiveX-or-Java, or other things that Zopers take for granted. These features give Zope a lot of power, but also present some interesting challenges in that they're quite a bit different way of thinking than most models that we may be used to. And...we don't have an IDE that wraps up the development and deployment of Products and External Methods. My suspicion is that Microsoft makes this sort of deployment (through the use of all those darn Wizards) a bit easier. Submissions in this area are welcomed.