From: "Richard Rosenberg" <richrosenberg@earthlink.net>
Allow me to start off by saying I have just finished going through the Zope Bible, and this is purely an educational exercise. This particular product class will (in the end I hope) essentially be a sort of query template that relies on zSQL methods. It began as an experiment to determine if I could get by with only 2 zSQL methods to serve all queries (except DELETEs, which at the moment I am not interested in) sent to a database connection. Before anyone gets upset, please keep in mind that this is an experimental effort only at this point.
At the moment I have 2 (rather lengthy) zSQL methods - one for SELECTs and one for UPDATEs/INSERTs - that properly handle most types of joins, and support just about any WHERE clause. Each zSQL method expects one argument, which is a list of dictionaries (for SELECTs a list containing one dictionary). The dictionaries which comprise the query parameter are constructed via 3 python scripts and 3 DTML documents. Each of the DTML documents gathers information from the user and each script is called when the rendered DTML from is submitted:
DTML 1 asks for a database connection ID from a dropdown list, and on submit calls a script that retrieves a listing of all of the available tables via one of the aforementioned zSQL methods. The same script then returns DTML 2. . .
DTML 2 displays a listing of tables from which the user must select one or more table names. DTML 2 then calls another script that retrieves a listing of all available field names for each table, along with type information for each field. The same script then returns DTML 3. . .
DTML 3 allows the user to define join criteria if applicable, fields to include in the result, and any selection criteria (sql WHERE clause). On submit DTML 3 then calls yet another script which uses all of the gathered information thus far to construct and validate the parameter sent to the existing zSQL method. A final DTML page is returned to display the results for testing purposes.
So I thought. . .would it even be possible to make this into a product? I realize that it may not be desirable, but is it possible?
Presently, when I select the product from the product add list, the first step (selecting a connection id on a DTML document) goes fine, and it calls a module level level function to retrieve the listing of tables. The function chokes when it attempts to return another DTML document on the following line:
return Step2Form(self, request)
which is why I ask the question:
How does one create a product which relies on multiple pages to gather information from the user when the product instance is added to a folder via the product add list (a wizard-like interface)? Can it be done, or is this a limitation of Zope?
In messing around with this I have found precious little information related to this specific question, and I am aware of no products which implement this functionality in their 'product add' process. In fact, it seems to be conspicuously absent. Thanks.
There may be some hints in a couple of Dieter's packages: http://www.dieter.handshake.de/pyprojects/zope/Wizzard.html http://www.dieter.handshake.de/pyprojects/zope/Dispatcher.html Jonathan