Here's what I would do: Write as much of the code as possible such that it is not dependant on Zope. Use unit-testing and Interfaces for everything. Factor things into relatively simple modules that layer on top of one another. Then write a top layer (hopefully a thin one) to integrate it all with Zope. Version 2.x assuming the first part doesn't take years ;^). Assume that this part will be largely thrown away when Zope 3 rolls out. If you have reasonably factored the non-zope code, and used Interfaces then I think you will find that creating a new top layer for Zope 3 to be *much* easier. Things like templates may be reusable with some modification, but likely by the time you do this, you will undoubtly want to refactor things. Last, don't be afraid to throw away all the implementation code eventually (or even early and often ;^). Try to get the general architecture right (and declare it with the interfaces and other docs). Given a working specification and a well thought out and tested architecture, rewriting the code will be the easy part. hth, Casey On Thursday 03 October 2002 02:50 am, Wankyu Choi wrote:
Hi All,
I have a rather big and complex portal project that'll take at least half a year to complete (plus, I need to pack in e-commerce and club features to accomodate the existing user base, a huge one). Taking CMF and/or Plone as it is would need too much customization. Still, basing my project on CMF is an option I'm considering. Until now, I've been coding this portal from scratch with no dependency on any other product and it's usable with 1.0b tag. (It's in no way complete and not public yet, but if you want to see it in action visit http://www.neoboard.net. Only a minimum set of features - navigation, article system, etc - are visible since my other open source project "NeoBoard" doesn't require Membership and stuff.).
What holds me back from going ahead with my plan is... Zope 3. I read an interview article where Jim Fulton **hoped** Zope 3 would be available in **a** usable form in July or early this fall.
Against this backdrop, what would you do if you were in my shoes?
1. Go ahead with the no-dependency plan with all modules having distinct connecting points with Zope so that I could plug them into Zope 3 some day. (Is it even possible? Not sure if Zope2 products would seemlessly integrate into Zope3. Jim's interview suggested Zope3 would offer backward compatibility but also suggested that Zope2 products would have to get upgraded to Zope3 architecture anyway.)
2. Base my project on CMF since CMF will be integrated into Zope 3 Core. I'm a bit reluctant to taking this option since, again, too much customization is called for. I'd have to override almost all tools/types plus authentication scheme in order to accomodate the existing user base. (Guess it'll take a lot of re-coding anyhow with Zope 3 even if I push ahead with this plan.)
3. Create a Zope 3 sandbox. Experiment with it and get on with the project inching along with Zope3 development. Learn-and-develop-as-I-go approach, sort of.
I'm pretty much inclined to option number 3. I don't want my project to become a dinasaur when Zope 3 surfaces. (Wouldn't I see myself having to upgrade my product the moment Zope 3 gets here in full swing just when I thought the project was over?)
Any thoughts/help will be appreciated.
Regards,
Wankyu Choi
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )