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.
-Morten
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
