Jonathan: Thanks for your advice. . .I'll try and be more concise. 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. Richard On 09/22/2004 07:59:47 PM, Jonathan Hobbs wrote:
----- Original Message -----
I am working on creating a zope product that uses multiple DTML pages to gather information from the user before actually constructing the product class, sort of like a 'wizard' interface. I am pretty new to this, so please bear with me.
To make a long story even longer. . .is there a way to wrap a returned DTML document in an intact acquisition context? I've tried .__of__(self) tacked on to the return statement but it seems as if it is the 'self' object that lacks an acquisition context. I've also tried making the DTML an attribute of a class that inherits from SimpleItem, which gives the KeyError on standard_html_header (incidentally, none of the DTML includes references to standard_html_anything).
If anyone knows of a product that uses a multi-step construction process prior to instantiation and ZODB storage I'd love to see how it works.
Your process seems a bit convoluted. Perhaps if you post what you are trying to accomplish someone may be able to assist (do you really want end-users to create new classes? or is there some other objective?)