On Tue, 26 Jun 2001, Erik Enge wrote:

> If your application can't be written in five minutes and you expect to use
> it more than once, you shouldn't use ZClasses - IMO.  The only argument
> for ZClasses (that I had at the time) was that it was very easy and fast
> to set up a couple of classes and some instances.  After I wrote mk-zprod,
> making Python Products is even faster than ZClasses, and certainly scales
> better.

Another thing is transparency and control.  With source files, it's easier
to 'see'; not to mention that code can be factored out into generic python
modules in a less cumbersome way.

How about meta-programming (designing) via the Zope interface, with UML or
somesuch; automatically generating Python code, then enable designers to
use a ZFormulator-ish product to edit the interface while a programmer can
work on the 'backend' (emacs on a terminal)?

One thing I'd really like to implement is DTMLFile transparency via the
web, so that a designer could enter into Control_Panel/Products/MyProduct
and edit webinterface files there, reflecting it on the filesystem.

ZClasses (as they are today, 'half-baked') should be tossed out, and focus
brought on making one approach easier.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to