At 02:53 03/08/99 , Robert Carey wrote:
Michel Pelletier wrote:
Robert Carey wrote:
I would like to be able to write generic handlers for data returned by ZSQL methods. To do this I need to know how to get access to the metadata for rows returned by ZSQL methods.
If I define a class and associate it with a ZSQL method using the Advanced tab of that method's management page, what is the right way for that class to learn the names of the columns returned by the query?
ZSQL Methods return a sequence of record objects. These record objects are instanciated on the fly. You can even specify a class in the filesystem that defines your returned objects. These are called pluggable brains, and are probably what your looking for, because you can define the actualy object returned to you, and don't have to go sniffing on it to find out it's properties.
-Michel
I am somewhat confused. I thought that a pluggable brain was the same thing as a class associated with a ZSQL method. Is it something else?
No, Michel is not paying attention. You were using a pluggable brain, which is indeed a class associated with a ZSQL Method.
There are places where I would like to do some sniffing to determine properties, rather than hardcode them into a class definition.
For example, what I wanted to do was write a generic method that could be used in more than one of those classes without the classes having to know anything about the details of the query they were written to support.
Here is an artificial example. Suppose you wanted to construct a header out of the names of the columns in the relation returned by any query, and you wanted to be able to apply that header to a number of different queries. If this use of __record_schema__ is all right, you could do something like:
# generic class - can be applied to any ZSQL method class handler: def title(self): ret = "" for i in self.__record_schema__.keys(): ret = ret + str(i) + " " ret = ret + "<br>" return ret
# event-table specific class associated with ZSQL method getevent class event(handler): def get_event(self): return "<br>%10.10s:%10.10s..." % (self.name, self.description)
# user-table specific class associated with ZSQL method getuser class user(handler): def get_user(self): return "<br>%s:%s" % (self.first_name, self.last_name)
where "user" and "event" are classes designed to support the records returned by the specific ZSQL methods called "getuser" and "getevent."
Then from DTML you could do something like:
<!--#var standard_html_header-->
<!--#in getuser--> <!--#if sequence-start--> <!--#var title--> <!--#/if-->
<!--#var get_user--> <!--#/in-->
<hr>
<!--#in getevent--> <!--#if sequence-start--> <!--#var title--> <!--#/if-->
<!--#var get_event--> <!--#/in-->
<!--#var standard_html_footer-->
This would display a result like:
USER_ID USER_NAME LAST_NAME FIRST_NAME
Marion:Sheckley Marcus:Booth Eva:Baumgarten Regina:Morse Vernon:Banks Byron:Keats
------------------------------------------------
ADDED_BY START_DATE RECURRING END_TIME SORT_ID LOCATION HAS_APPOINTMENT START_TIME CAPACITY EVENT_ID END_DATE DESCRIPTION NAME COST
Early Bird:Come join ... Lazy Work :Rick is le... Current Ev:Come discu... Dahlia Dal:We are off... An Evening:We will di... Movie in t:Tonights m...
Ignoring for the moment that in this context the generated page is not particularly meaningful, note that the header of each section was produced by the same piece of inherited code with no knowledge of the specific query. There are places where I would prefer to work in a way analagous to this rather than to have to code the header information specifically into individual classes such as "event" and "user."
What I would like to know is if
for i in self.__record_schema__.keys():
is a legitimate way to get at this information, and if it is not then is there another way that I can use?
Or, for that matter, am I totally misusing the ZSQL class facility, and should I be doing something else? Is there a tutorial on ZSQL methods that goes into how to use pluggable brains? I love using Zope, but I sometimes have trouble knowing whether I am going with or against the grain of the system.
Thanks,
Rob
With Zope, the source is most often your documentation. And yes, what you are doing is legitimate and correct. I believe DC is in the process of officially documentating the source, therefore making it official. The fact you found __record_schema__, means you already know where to look. For those that don't, lib/python/Shared/DC/ZRDB/Results.py creates instances of the record object, which is based on a simple, empty class end an optional user specified filebased class, the pluggable brain. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------