SchoolTool supports several ways of entering your data.  Most obvious is the web interface.  This method is also the most time consuming, and when working on a development server, it is even more impractical, because you may find yourself needing to start over from scratch, for one reason or another.  Instead, we are going to write Python scripts to automate the entire process of setting up your school.  This will be slightly more time consuming up front, but will give you peace of mind, knowing that you can always start over from scratch and rebuild your whole school in minutes rather than hours.  Also, it will allow you to work directly from whatever CSV exports you have from your existing systems, or that you create in a spreadsheet or database.

SchoolTool is somewhat different architecturally than most database-driven web applications you're likely to have used.  SchoolTool is based on the Zope application server.  Zope 3, to be precise, which is a complete rewrite of the more common Zope 2 server.  SchoolTool does not use a relational database, but stores its data in the Zope Object Database (ZODB).  There are no tables, just persistent objects.  So the scripts we're writing can't just dump columns of data into tables;  they must create objects.  Luckily, Python scripts and the ZODB work together seamlessly. 

We will make use of the csv module from the Python standard library to import csv files with a minimum of fuss.  effbot's site provides a good introduction to the module.  One possible complication is that the version of this module included in Python 2.4 does not support unicode.  If this creates a problem, you can still parse your csv files in the traditional way with line.split(",").  For the sake of brevity and clarity we'll use csv in the examples.

SchoolTool was designed from the ground up to use XML web services.  The particular style of web services we use is called "REST" (compared to, say, SOAP or XML-RPC).  Basically, you can control the server by sending it XML packets via HTTP GET, PUT or POST.  In fact, since it only uses XML and HTTP, you can do this remotely, from any programming language.  At this point, because writing the web services support increases our development time by about 30%, we've paused adding web services support to new functionality.  At this point (April 2006), it works for creating some objects and not others.  When it is possible to use the web services method, it is  preferable, since more error checking is done this way, although it is somewhat slower.

When we are using the web services, we will do

 from schooltool.restclient.restclient import SchoolToolClient

This SchoolToolClient object encapsulates all the XML plumbing and provides us with many straightforward methods for creating the core objects in a SchoolTool system.

If we are doing something not supported by web services, we can place objects directly in the ZODB easily enough.  Each package in the SchoolTool source tree contains useful references to help with this process.  The sampledata modules included in most packages are add objects to the database using methods we can copy.  The only difference is that the sampledata module usually generates its data randomly, while we'll be parsing the data from a csv file.  Also, most packages contain Python doctests, which provide excellent documented examples of how to create objects with scripts.  These doctests are usually either in README.txt files or in a tests or ftests directory.  Ideally, my subsequent documentation will be so flawlessly comprehensive that you won't have to go looking elsewhere for more documentation, but now you know where to look, just in case.

Next step, a little preliminary wiring for your setup scripts...