hi folks, i'm in the middle of developing a zope application and its starting to get complicated. i'm looking for tips on how to manage the complexity or design to minimize it. the application is a registry of trainers and training events. because of the client's needs and my experience with relational databases, the backend is SQL Server. the first part was a training calendar. it deals with three main objects(tables): TrainingEvent, Person, Location. there are about 4 other supporting tables: County, DateTime, etc. i originally planned to use ASP, but couldn't find any tools i was happy with. already a little behind, i gambled and decided to use zope. not knowing any python, i went the DTML/SQL method route. this part of the application is working well. here's the problem. the full (larger) scope of the project is now becoming clear. to model all the data will probably require 18-20 tables. working with the data will require 3 or 4 separate applications. any ideas on how to develop this in zope in a manageble way? the first application is composed of a LOT objects: DTML input forms, DTML form handlers, SQL methods, etc. i'm afraid if i keep going this route things will spiral out of control. what seems like a better structure is 3 tier: python business objects talk to (encapsulate) the database. zope controls the business objects. the main reason i switched to zope is that it seems like zope is set up for this. before i jump into this, is there anyone who has done something similar? can you offer any advice or moral support? sorry for the broad questions, but i guess i'm looking for feedback at a higher level. over the next few months i'll have 1000s of more specific questions :) thanks in advance for any feedback, -scott ----- Scott Lewis Baltic Avenue Productions csl@balticave.com
On Fri, 21 May 1999, Scott Lewis wrote:
here's the problem. the full (larger) scope of the project is now becoming clear. to model all the data will probably require 18-20 tables. working with the data will require 3 or 4 separate applications.
I have no experience with relational databases but if you can 'factor out' the common behaviour of your applications then you can add the relevant SQL methods, external methods etc in a top level folder and let subfolders acquire it. Nevertheless I have read about many complicated RDBM apps implemented in Zope on this list so I hope that might give you some encouragement! Good luck Pavlos
Scott Lewis wrote: [snip]
what seems like a better structure is 3 tier: python business objects talk to (encapsulate) the database. zope controls the business objects. the main reason i switched to zope is that it seems like zope is set up for this.
before i jump into this, is there anyone who has done something similar? can you offer any advice or moral support? sorry for the broad questions, but i guess i'm looking for feedback at a higher level. over the next few months i'll have 1000s of more specific questions :)
Hm, I have experience talking to databases from Python via Python's standard database interface (basically SQL, the particular backend I used was ODBC). Python is a very nice language to deal with data like this, I found. Python's list and dictionary datatypes are very useful. Python also has a clean structure, so the Python part seems okay (unless it is speed, though I have found it's quite capable so far). How do you plan to use Python to talk to databases? Are you going to use Zope or use the Python db-api? If you use Zope SQL methods you need to talk through these methods from your Python. I don't have experience with it but this is possible; the Z SQL methods can be treated as Python methods from Python, basically. Another tricky part would be 'business objects'. The simple way to interface Zope with Python are external methods (written in Python). If you get your business objects done with external methods, I'd recommend this route. External methods are not 'business objects', however ('business methods', I suppose?), though of course you can package a number of them together inside a Zope folder. (you can bundle them in a subfolder which will be automatically acquired by other subfolders..this way they remain manageable and don't pollute your root folder). If you need actual objects (i.e. something with methods), you can go various routes. One is to write a Zope product. This is quite a challenge; I've tried it once before but got bogged down. Today I did get a product working (basically by copying and pasting and removing what I didn't need from another product, this seems to be the easiest way). (cheer!). Just be aware you might run into some difficulties; one needs to know quite a bit about the Zope API. Another way in the future would be to use ZClasses. ZClasses are part of the Zope 2.0 Alpha, but it'll take some time before there'll be a production version of Zope featuring them. From what I understand of ZClasses you can create a new Zope product from inside Zope with them (basically by packaging DTML and external methods together). Good luck and regards, Martijn
Hi: I'm jumping into this discussion cause I'm also doing something similar.. On Wed, 26 May 1999, Martijn Faassen wrote:
How do you plan to use Python to talk to databases? Are you going to use Zope or use the Python db-api? If you use Zope SQL methods you need to talk through these methods from your Python. I don't have experience with it but this is possible; the Z SQL methods can be treated as Python methods from Python, basically.
Using Zope's SQL methods work pretty well. When you call the SQL method from Python it returns an instance of the Results class (see Shared/DC/ZRDB in the lib dir). Its actually really easy to use this class because it has overridden indexing methods, etc, so you can do something like: rs = sql_method() rcpts = map(lambda x: x['email'], rs) (note there is a bit of trickiness involved getting the method. Sometimes I pass it as a parameter from a DTML #call tag) So this extracts the email column from each row and puts it into a list. Obviously the main advantage here is that you can abstract the database layer. I suppose this means you don't even need to access SQL databases, since other things could return Results objects. Fun stuff. :)
Another tricky part would be 'business objects'. The simple way to interface Zope with Python are external methods (written in Python). If you get your business objects done with external methods, I'd recommend this route. External methods are not 'business objects', however ('business methods', I suppose?), though of course you can package a number of them together inside a Zope folder. (you can bundle them in a subfolder which will be automatically acquired by other subfolders..this way they remain manageable and don't pollute your root folder).
One idea I was playing around was using the pluggable brains support with SQL methods to wrap all results into business objects. I haven't really found much documentation on this, but I will be investigating this very soon as I prototype some stuff to explore various implementation methods. What do you think about this instead of external methods? Managing a class is sometimes easier than managing a bunch of seperate methods.
Another way in the future would be to use ZClasses. ZClasses are part of the Zope 2.0 Alpha, but it'll take some time before there'll be a production version of Zope featuring them. From what I understand of ZClasses you can create a new Zope product from inside Zope with them (basically by packaging DTML and external methods together).
Hmm, I am wondering about using ZClasses because I'd like to further abstract data storage by saying that I could either store objects in the ZODB or in a SQL database. One thing missing to fully enable this are ZODB Query Methods which would allow you to return Results objects from a ZODB-based query. Maybe this already exists for ZTables? If so I'd like to know. Does this mean a ZClass could potentially be used as a pluggable brain for SQL Method or are we talking different things here. Anyway, that's enough for me. my brain hurts. :) ------- Jordan B. Baker -- jbb@spyderlab.com weaving the web @ http://www.spyderlab.com
participants (4)
-
Jordan B. Baker -
Martijn Faassen -
Pavlos Christoforou -
Scott Lewis