[Zope] acquisition context within product method

[Richard Rosenberg]

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?)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>