[Zope-dev] More comments on ZPatterns

Phillip J. Eby pje@telecommunity.com
Tue, 04 Jul 2000 00:32:17 -0500


At 10:06 AM 7/3/00 -0500, Steve Spicklemire wrote:
>
>Seriously, I'm trying to get it all figured out, and I thought maybe
>if I attempted to do something 'real' with it I would at least learn
>what I *don't* understand. Well.. I've learned a *lot*! (about what I
>don't understand.. ) ;-) The source code is astonishingly simple 
>looking, but about one layer deeper that I can easily grok, apparently.

That's an unfortunate side-effect of applying Demeter's law...  it's easy
to grasp (in an abstract way) local implementation aspects, but hard to
grasp how the actual *concrete* implementation works from looking at the
pieces.  It's the "there's no *there* there" effect, as Ty dubbed it.



>I also create a "TableInfo" ZClass, subclass of DataSkin, that
>quantifies the kind of data the customers have to choose from, and
>metadata about the data (headers, query parameters and suchlike).
>
>I create a ZClass property sheet for the TableInfo ZClass.
>
>Finally I create an instance of Specialist (tableManager) with a
>(default) rack of TableInfo objects.
>
>Now... some of the Tableinfo properties, and some of the View
>properties are *really* in MySQL. I figured out, from the mail list
>and the source code, that I can create a Generic attribute provider in
>the rack that can get attributes from an SQL database for my DataSkin
>descendents using the 'source expression' and 'target expression'
>business.

Congratulations, you found the top secret documentation.  :)


>Source expression:
>  (GetTableInfo(tableInfoID=self.id) or [NOT_FOUND])[0]
>
>Target expressions:
>  tableHeaders=RESULT.tableHeaders
>  footnote=RESULT.footnote
>
>and when I ask one of my TableInfo instances for their footnote it
>comes right out of MySQL! Cool. Now.. I can't seem to figure out how
>to *change* the data in the database when the user 'edits' the

>DataSkin.... which brings up the whole issue of changing stuff in
>DataSkins.

Here's some more top-secret documentation...  Use a GenericTrigger to
implement attribute changes.  Set up your trigger to be activated on object
changes, and set the trigger expression to call an SQL method, e.g.:

UpdateTableInfo(object=self,CHANGED=CHANGED)

In the SQL method, code something like this:

UPDATE mytable
SET
<dtml-if "CHANGED('attr1')">
attr1=<dtml-var "object.attr1">,
</dtml-if>
...
WHERE primary_key='<dtml-var "object.id" sql_quote>'

with an "if" block for each attribute you might want to update.

Last part, and this is the trick that's not yet documented...  set the "Set
Attrs" field to be a list of the attributes you want the trigger to handle
set/delete operations for.  (You don't need to put anything in the
"Keeping" field unless you need a "before" value of an expression to use in
your SQL.)