[Zope-dev] Quickie on ZPatterns ... I promise :)

[Phillip J. Eby]

At 09:15 AM 7/27/00 +0100, Steve Alexander wrote:
>Bill Anderson wrote:
>> 
>> Let's say I have an object I will store in a rack. Let us say I want
this object to be
>> cataloged in a ZCatalog. Any caveats I need to know about
>> ..such as "Don't do that!" ?
>> ?;^)=
>
>Make one of the object's base-classes DataSkin.
>
>Don't make it CatalogAware.
>
>Use triggers to index and unindex the object from a catalog. You'll
>probably want to store the catalog in Specialist.
>
>By the way, Phillip Eby has released a new development snapshot:
>
> 
>http://www.zope.org/Members/pje/ZPatterns/ZPatterns-0-4-1snap1.tgz/view
>
>I'll be trying it later today.
>

FYI, the snapshot really only adds proxy roles support for generic
providers/triggers, and adds a first-cut version of SkinScript.  If you're
adventurous, you can look at SkinScript/Compiler.py and have a look at the
grammar in order to figure out what the language does.  So far I've
successfully tested a SkinScript method that does the work of four
GenericAttributeProviders and two GenericTriggers, just by using the
appropriate statements.  Here's a SkinScript snippet you might use for
CatalogAwareness:

WHEN OBJECT ADDED 
CALL somecatalog.catalog_object(self)

WHEN OBJECT CHANGED
CALL somecatalog.recatalog_object(self)

WHEN OBJECT DELETED
CALL somecatalog.uncatalog_object(self)

(Replace the incorrect catalog API calls with ones that are correct...  I'm
sure I'm missing some parameters and probably getting the names wrong...)

Note that "somecatalog" must be in the acquisition context of the
SkinScript method itself.  If you want to use a catalog in the context of
the DataSkin, you need to say "self.somecatalog...".

Some other SkinScript snippets:

# Store attribs persistently - replaces 
# Persistent Internal Attribute Provider
STORE attrib1,attrib2 IN SELF

# Computed attributes
WITH SELF COMPUTE 
  attrib1=attrib2+attrib3,
  attrib4=attrib6*10

# Generic attrib provider
WITH (SomeSQLMethod(key=self.id) or [NOT_FOUND])[0] COMPUTE
  field1, field2, somefield=field3+field4,
  fancy_id = '*(%s%s)%' % (otherfield,self.id)

# Generic trigger
WHEN OBJECT ADDED,CHANGED,DELETED
CALL someexpr(self.id)
SAVING foo,bar, baz=spam, widget=diddly+id

# Attribute provider
STORE attr1,attr2
USING somefunc(self)
SAVING attr1,attr2

# Conditional attrib provider
WHEN OBJECT ADDED
STORE attr2
USING otherfunc(self)

That about covers it for what's implemented so far.  The goal is to
ultimately replace the majority of providers and triggers with SkinScript.
But it will still be possible to write and use custom plug-ins that provide
attributes or handle events in other ways.  But SkinScript will be quite
handy for most things.