Forum OpenACS Q&A: Response to Article on ACS x Zope
1. Is there any problem with the third party Zope Postgresql client driver that would make it more difficult to use the OpenACS Postgresql code with Zope? (I just assumed it "works" and will be more suitable for specific Postgresql facilities than going via ODBC, but have no knowledge).
I've used it on a small scale project and it worked fine. It survived the upgrade to PostgreSQL 7.02 as well. I don't know of any specific problems with it - I'd just like it to be part of the standard Zope distribution and treated as a core part of Zope.
2. Is there some difficulty implementing Linux (and FreeBSD etc) ODBC client drivers for Zope that explains why there is only a Win32 ODBC driver?
I really don't know. I asked on zope lists about why the lack of database drivers and was told that DC were supporting Oracle, Sybase and ODBC only. I asked why ODBC was only WIN32 but I didn't get any reply. This was before Chris McDonough joined them Chris - any news ?
Albert also said -
[AL] Sounds like you could be ideally placed to take the initiative in getting people interested in making it "stand alone" so that it could keep in sync with ACS as well as being available to Zope. Any interest in that cf "forking"?
Like others on this list I'm proceeding slowly down the maze of web development, hoping to avoid dead ends and sometimes walking on top of the hedges to have a better view. I will have hands on ACS (not Open ACS) soon and will be able to see what the capabilities of the system are (in the areas of ecommerce and education mainly). I also intend to keep on with Zope if I can because I think its going to be really, really good ...
Chris McDonough has outlined the constructs in Zope which let you treat the data source in abstraction from the presentation layer. It actually goes further than he mentions - the data returned by a <dtml> tag could be coming from anywhere. The fact that it is coming from a PostgreSQL database (or a Python list) has no impact at all on the presentation of that data.
The clever thing about Zope is that using this approach is really easy and doing it any other way would be more difficult so any Zope application has this abstraction built in.
For example the General User Folder product which is a simple login manager is used to validate user logins and passwords. As supplied these are contained in lists - so the software calls a dtml method called "UserAuthenticate" which just contains the list of valid users
To change this so that it validate this against an SQL database all you do is to replace the physical list of users with a dtml tag which refers to an SQL method which returns a list of users.
The software which calls "UserAuthenticate" neither knows nor cares whence the data cometh.
So as far as abstraction is concerned as you know I wasn't suggesting that Zope can automagcally optimise SQL requests for various databases. However the application itself needs no knowledge of how to get the data, that can be contained in the method which does the retrieving.
Moving an app from Oracle to PostgreSQL would involve, for example, spoofing OUTER joins wherever they occur, but it would then be easy to have an attribute which you set to say which database was in use, the SQL method would generate the correct code based on the value of the attribute.
Thinking about it you could have a set of attributes for example "outer join supported", "scroll cursors supported","row level locking supported". The correct code could then be generated depending on how those attributes were set. Perhaps
There may be more you can do to make the abstraction more complete, but that would still have no impact on the presentation layer (which only ever needs to call the same method to get, insert, update or delete the data it needs). Therefore you could add better abstraction "underneath" at any time in the future, once the technology is available. In the meantime, hand-optimised SQL code would work well enough.
As to whether I can be of any use, well once I get hands on ACS I'll let you know