Geoff Gerrietts wrote:
[some paragraphs about scaling which I can't really comment on]
As for source control, I figure all of your code (DTML, yuck) is in the
ZODB. This went out of fashion a long time ago, most serious development
happens on the filesystem (in Python packages) which can obviously be
source-controlled very well.
A good deal of the code is in the ZODB, because it's (yuck) DTML
documents, yes. We have another sizable chunk that lives on the
filesystem. The challenge in managing the build/deploy process has
been trying to find a way to keep those two conjoined. I suspect that
any dependency on the ZODB at all is likely to be considered an
impediment, and my quick eyeballing says it's not gone or even really
optional under Zope 3 (but I'm sure we could work something out.)
The ZODB is still there in Zope 3, but Zope 3 is much less dependent on
it. In fact, there are people who are using Zope 3 without any ZODB
instance at all, but directly talk to a relational database. Currently
this requires a bit of hacking, but our good man Chris Withers has
expressed interest in making the next release of Zope 3 more flexible in
this regard.
What's already possible is to have a minimal ZODB with only one
persistent object: a SQLObject or SQLAlchemy container. That's a
container (e.g. like a folder) whose items aren't persisted in the ZODB
but come from a relational database.
You seem to already have come to the conclusion that having code live in
both the filesystem and the ZODB can be painful. I think a good first
step for you would be to migrate your remaining ZODB-based code to the
filesystem. That not only makes deployment easier, you're also free to
refactor it then (e.g. using Zope 3 idioms). In the long run, this also
means saying good-bye to things like External Methods because they
require code on the filesystem and configuration in the ZODB.
Regarding "oh you'll hafta start over", it's pretty much true, if you
want to switch to Zope 3. But nobody says you have to. You can do it
incrementally by porting some of your app's functionality to Zope 3
components step by step (as mentioned already, most work in Zope 2). Big
projects like Plone aren't rewriting their whole codebase either, but
new development is completely Zope3-based. Their target platform still
is Zope 2, though.
"You'll hafta start over" is only ever true in degrees, though, and
I'm still trying to figure out what the degrees are. The business
logic will still be the same. Can we hack together a DTML processor
that allows us to export the DTML documents to the filesystem and
publish them from there? Maybe, I don't know. Did someone else already
do that? Don't know that either. How dramatically will our products
need to change? Probably 75% of our Python code is written in a
bastardized form of ExternalMethod; we might be able to leverage that
unfortunate architectural choice to significant advantage during our
porting phase. These are the kinds of questions I have, and I think
the answers probably aren't easy or someone would have offered them
up.
It is certainly possible to execute filesystem-based DTML (using
Globals.DTMLFile). It's hard to say how much your products will have to
change without knowing the codebase. If you have external methods, it
shouldn't be too hard to refactor this code into components in "proper"
Python modules. To make things easy, the external methods could stay at
first, for backwards compatibility. I would take this one step at a time
(that's at least what everybody else seems to do and it looks like it's
working out for everybody).
Someone's going to need to learn enough Zope 3 to answer the
questions. I'm not sure it will be me, but maybe. :)
Well, whoever it'll be, there are books (e.g. http://worldcookery.com)
and trainings (e.g. http://trizpug.org/boot-camp/camp5) that should help
with the learning :).
--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
