But there are really two ways to do this, either of which is viable.
1. the right way ;-)
2. Code all of your logic using TTW stuff and Zope components. Use the Publisher.Test.test method to call methods of your Zope components in unit tests.
Do you really think this is a viable approach for a product with a non-trivial amount of logic?
I'm afraid we are getting way off the topic of ZEO here, but... I think this is important, so...
[Agreed. Ill CC zope-dev and I suggest we continue there.] Sorry, I phrased my question ambiguously..... I meant, do you think a TTW development approach is viable for applications with a non-trivial amount of logic?
(I took the ZEO mail list out of the loop)...
[Agreed. Ill CC zope-dev and I suggest we continue there.]
Sorry, I phrased my question ambiguously.....
I meant, do you think a TTW development approach is viable for applications with a non-trivial amount of logic?
Perhaps not. Not yet. For example, we have no equivalent to CVS for objects in the objectbase. This is why filesystem products are so attractive for apps with lots of logic. But combining the two approaches I think can provide you with the best of both worlds. TTW changeability for presentation, and filesystem base classes for traditional development. The ability to test TTW stuff (particularly DTML methods) with ZPublisher.test allows for traditional unit tests.
participants (2)
-
Chris McDonough -
Toby Dickenson