GenericSetup and separation of concerns

As I continue my investigation of and attempt to implement a GenericSetup approach to customizations for my Plone site, I am seeing more clearly the need for this transition, even if the reasoning behind some of the design choices escapes me.  

In TTW customization of Zope 2 there was no natural way to cleanly separate customizations from default functionality.  Perhaps more significantly, the system did not really provide a canonical way of separating presentation from business logic.  Zope Page Templates (and the older DTML methods) were, and are, too powerful for their own good.  On the other side “Script (Python)” scripts are too limited in power (due to security restrictions) and scope to be able to handle general purpose business logic.  This state of affairs leads almost unavoidably to “spaghetti code” strung across a mixture of page templates, DTML methods, “Script (Python)” scripts and “External Methods”. 

The addition of “Controller Page Template”, “Controller Python Script”, and “Controller Validator” objects appears to have been an earlier attempt to address the problem of a lack of a clear MVC-style “controller”.  While these objects provided some conveniences, at least for form processing, they didn’t eliminate the deeper problem.  I’m still not sure that Plone 3/Zope 2/Five has really resolved the fundamental issue, but definite progress has been made.  

I do regret the profusion in GenericSetup of XML configuration files (a la Java web apps) which IMO humans should not have to read, much less write. The use of XML-like “ZCML” for the main configuration files seems particularly strange. There must have been some initial reason for not using XML, but now it just seems arbitrary and bewildering.  Personally, I would much prefer a pure Python implementation, but what do I know?


, , , , , ,