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 )