[Zope] can I move my zope site off zope?

Tue, 27 Nov 2001 10:07:55 -0800

Ok, time to put on my advocacy hat...

You have indicated you would be using PHP, so let me give you my personal
opinion, for what it is worth: Mixing SQL/code/HTML in the same file/module
is bad bad bad.  After doing a big team-developer project in ASP a few years
ago, I see the inherent lack of scalability of this sort of setup; with ZPT,
ZSQL methods, etc in Zope, you get true separation of concerns, modularized
code you can unit-test (without having to resort to functional software
testing).

For working with relational data, here's my personal opinions:
Fair: ASP/PHP/JSP
Good: ASP+COM/PHP+MODULES/JSP+EJB
Better: Zope with DA/ZSQL methods / TTW python scripts / ZPT uses the TTW
Python scripts
Best: Python API / abstracted framework for data access, used by Zope Python
product; well documented with UML diagrams of class relationships and
inheritance; ZPT for presentation.  Persistent objects in ODB represent
underlying relational data.  Reuse of code and patterns on future products.

I don't understand what you mean a DA is hard to set up... for me, "apt-get
install zope-mysqlda" worked for me ;)  Your app is "distributed?"  Lots of
PHP apps used shared memory for IPC, or make you broker things like session
data and stuff normally done in memory into your RDB if you want to make
them cluster-safe.  ZEO with Zope is soooooo much easier, and very
transparent - it makes the burden of clustering a sysadmin job and NOT a
developer job.  Use ZPT for the templating, and Python products for your
code, and restricted TTW python scripts as glue when necessary.  Since you
are obviously concerned with application interoperability, why not consider
that you are not likely to get stuff like XML-RPC working out of the box
with PHP.

Also, IHMO, there is a better way to do this in Zope and get the
interoperability you desire: a hybrid persistent object+relational storage
model.  I have an application I'm building now that will store between
half-a-million to a million records scattered over several databases and
about a dozen tables in a MySQL InnoDB tablespace; all work is handled in an
API I built from scratch for this project that maintains thread-safe
connections to the database and an abstracted OO API to the data, which
handles things like MySQL transactions, database integrity, and data access,
bypassing the use of a DA/ZSQL methods altogether.  The core API is done in
Python using MySQLdb; you create a DB class designed to handle connections
and basic operations, as well as a record class for each logical view of
your underlying relational database.  The key to getting the most out of
this setup is that the API is used by a Zope product module that creates
proxy objects (subclassed from the previously mentioned record API object,
CatalogAware, and SimpleItem) for each of these logical views, and stores
them in a container for each view (a container class subclassed from
BTreeFolder).  The proxy objects do nothing but provide an object-per-record
in a view; making these proxy objects persistent allows a useful hybrid
storage model, which you can then catalog the data using ZCatalog, and
present things like full-text indexes through Zope for any relational data.

The downside to this is that it makes you do more work than simply using a
DA... but it buys flexibility...

The upside to this is that the design pattern works, provides all the key
components of a very object-oriented way of doing things; and once you do
your first project for relational data this way, you can reuse the same
design patterns on your next relational data integration project in a
fraction of the time.  Doing this really requires you to be able to know
your underlying API, and the use of UML class diagrams of your API on your
first project is very helpful as a reference for using this design pattern
and to apply to later projects using similar techniques.

My honest opinion: if you are willing to do things right, for big projects
with multiple developers or a need for reusable code and/or patterns, Zope
is a better platform than any light-weight template/code hybrid framework
like PHP/ASP/JSP, etc.  My company uses PHP for lightweight stuff, including
some simple task automation, but for any heavy-duty tasks, we use Zope; and
there is nothing to preclude using both, if you use relational data or an
interoperability standard like XML-RPC.

And to be honest, I think the best thing about Zope is this: 6 months from
now, if you want to reuse - or for that matter re-read - your own code,
Python is going to be far superior to any other language, especially if you
have to fight your way through all the HTML in that same module/file with a
machete!

Sean

-----Original Message-----
From: Jacob Singh [mailto:jacob@prisonbooks.org]
Sent: Tuesday, November 27, 2001 7:35 AM
To: zope@zope.org
Subject: [Zope] can I move my zope site off zope?

So I'm considering doing a major product with zope, and I'd like to hear
what people think about taking a site off of zope.  I know it's a great
framework to build in, but I'm really used to Database programming and
ma inclined to use that.  I know you can have SQL adapters in Zope, but
for two reasons I don't want to use them, 1. They can be a hassle to set
up and since this is a distributed app, this might be a problem.  2.  It
doesn't really take advantage of the object oriented nature of zope's
content management.  It basically then is just an excuse for a good
templating engine.  What I am worried about though is if I build my
product without SQL(it is a task management/portal suite),  it will
forever live on Zope, and getting to that data from other programs will
be next to impossible.  Does anybody have any experience/advice on this,
please let's hear from the zealots AND the skeptics. I know Zope is
awesome, I just want to make sure it doesn't get me in a proprietary
bind.
Thanx
J

_______________________________________________
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 )