[Zope-dev] RE: [Zope-ZEO] Advice
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? ___ 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 )
Re: [Zope-dev] RE: [Zope-ZEO] Advice
(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. ___ 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 )
Re: [Zope-dev] Re: [Zope-ZEO] Advice
We're using ZCVSMixin for just such a scenario. It's working a lot better than nothing. ;-) It does still have rough edges, and you need to know too much about how it works to do anything complex, but it does allow us to manage changes and test/stage/update etc with a much greater degree of control than we used to have... Of course right now it's unix only... but I should be able to fix that once my current slate of projects are finished. -steve "Andy" == Andy McKay [EMAIL PROTECTED] writes: One of the reasons our group is moving away from Zope is that it has very poor support (if any) for the development/staging/live model. We like this model. We think it's a good thing. But sync'ing code across multiple Zope installations is a royal PITA. I'd like to hear more about the problems you've had and how you overcome them in a different system. And no, versions are *not* the answer. Well, they are a pretty good answer for lots of applications in my experience. Andy Version can work for small changes, but they certainly dont Andy for large numbers of changes across lots of objects. And Andy since the catalog is a key component for our site, its a Andy real problem. Andy ___ Zope-Dev Andy maillist - [EMAIL PROTECTED] Andy http://lists.zope.org/mailman/listinfo/zope-dev ** No cross Andy posts or HTML encoding! ** (Related lists - Andy http://lists.zope.org/mailman/listinfo/zope-announce Andy http://lists.zope.org/mailman/listinfo/zope ) ___ 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 )
