From: Robin Becker [mailto:robin@jessikat.fsnet.co.uk]

...

zClasses are not written in Python so there is no code to see. Except fot the dtml code and you can see that when you have imported a zClass product.

...

I disagree strongly. Many of the useful coding tools need line oriented Ascii text; where is diff or grep for my ZClass code. The XML export form would do except that the differences caused by ordering/numbering mean that diff reports many irrelevant differences. Zope loses by not having a decent external storage mechanism for its programming.

Whoa there ... I didn't say anything you could disagree with. I just stated facts. But I do agree that writing software in Zope is a problem for me too. I would also like a flat text storage system, but I also see why it is difficult considdering the design choices made in Zope. I believe that my problems stems from the fact that code, content and presentation is to strongly interwoven. zClasses are nice and simple but difficult to edit, as it has to be done in the browser. Or at least pasted into it. You also get yourself painted into a corner pretty quickly. Subclassing a Pyhton class as a base for a zClass is kind of nice. But currently I am having problems using that method as it seems that "helper classes" cannot be adressed from dtml methods in the zClass. (Se my acessing parameters in a "helper class" posting). Products are difficult to make, and all the tutorials are rather bad. Business logic and presentation is mixed together. (Business logic should not use any code or libraries from Zope at all.) A nice way to work would be to make a Python class that is completely independent of Zope. Test and debug it. Then make a thin Zope wrapper that adds just enough functionality to make it work in Zope, and so that it can be accessed nicely via dtml. I am trying this approach currently, but it gets ugly real fast. It will probably be nicer when I understand it fully. I Will post a How-to then. Regards Max M