[Zope] Methods - inheritence vs acquisition

Cary O'Brien cobrien@Radix.Net
Wed, 8 Mar 2000 09:22:56 -0500 (EST)


Michel wrote:

> Cary O'Brien wrote:

[snip, thanks for the explanation]

>  
> > 2) It seems that the examples require the user to generate forms by
> >    hand, which seems unnecessary.  For example, (after a protracted
> >    struggle with the underlying python code) I wrote a method that would
> >    create an html table for any query, ripping the column names and data
> >    out of the result object.
> 
> Ok.  You're talking about SQL Methods?
>  
> >    2.1) Shouldn't this be a standard part of Zope?
> 
> If you're talking about SQL Methods or other objects that implement the
> Zope Search Inteface then it is allready a standard part of Zope.
> 

Sorry, I wasn't clear.  What I was looking for was a method to get,
for example, an html table out of what an ZSQL method returns.  I
had to look at the code under lib/python/Shared/DC/ZRDB to figure
out that calling a ZSQL Method returns a Results object, and then
look at the results object to see that it has methods like names(),
data_dictionary() and tuples().  Then I could write a loop like...

    <dtml-with "Your-query-method(parameter=value, parameter=value)">
    <table border=1>
      <tr>
        <dtml-in "names()">
          <th><dtml-var sequence-item capitalize spacify></th>
        </dtml-in>
      </tr>
      <dtml-in "tuples()">
      <tr>
        <dtml-in sequence-item>
    	<td><dtml-var sequence-item></td>
        </dtml-in>
      </tr>
      </dtml-in>
    </table>
    </dtml-with>

My point, I guess, is to suggest that this should be a built-in method
in a ZSQL query.   Unfortunately this would also hard-code the
appearance of the table unless it had lots of options.

I'm probably missing something.

> >    2.2) If so, do you want this code?
> 
> You should look at what is there first and tell us how to improve it.
> 

I did find code that kind of did this in the manage_test method in the
ZRDB/DA.py file, but when called returns manage_tabs, and also access
some non-dtml-accessible functions like result._serachable_result_columns().

I'm sure I'm missing something, but this doesn't seem accessible from DTML.


> >    2.2) Likewise for property edit forms.  I did find some DTML that
> >         would do this, but shouldn't this be standard.
> 
> The managment interface obviously builds the property view dynamicly, so
> something like this is in Zope.  Whether or not it is useful to others
> is unknown to me.
> 

Once again, there is code to render property table forms, but it is 
buried inside lib/python/OFS/properties.dtml.  Once again, it seems
as if a standard method to generate a form for editing properties
would simplify creating applications by eliminating the need to
type in, by hand, the required forms.

I've seen a couple of pieces of code, both in the mailing list and
on zope.org to do this.  

The overall goal is to make it easier for beginners to whip up an
application without having to know too much about html forms and
formatting.  Plus to make the system easier to maintain by not having
redundant information (i.e. in the property sheet or query, and also
in the DTML that renders it).

Thanks for your time...

-- cary (obviously confused)