[ZPatterns] Rack.getItem returning attributeless objects (ZPatterns newbie)

[Phillip J. Eby]

At 12:41 AM 7/6/01 +1000, Phillip Crumpler wrote:
>
> I have a specialist, with the default rack, storing a zclass derived from
>DataSkin. The rack is set to 'load by accessing attribute: id'. Within the

That won't work.  The object already *has* an 'id' attribute, so the
SkinScript that computes it will never be executed.


>specialist are a few sql methods: SQL_get, SQL_change, SQL_create,
>SQL_delete. The table has two columns, id (int) and name (text). The zclass
>has a simple index_html method to show the instance's id and name
>attributes.
>
>The rack has a skinscript method like so:
>
>WITH SQL_get(id=self.id) COMPUTE id, name

Try making this:

WITH QUERY SQL_get(id=self.id) COMPUTE name

And making the 'name' attribute be the "load" attribute.




>WHEN OBJECT ADDED CALL SQL_create(id=self.id, name=self.name)
>
>WHEN OBJECT CHANGED STORE id, name USING SQL_change(id=self.id,
>name=self.name)
>
>WHEN OBJECT DELETED CALL SQL_delete(id=self.id)

The rest of this looks fine.


>I'm new to skinscript, so I'm not too sure about this. The only other Data
>Plug-In in the rack is a SpecialistPlugIn (but the Specialist itself has no
>Data Plug-Ins)
>
>My (first) problem is this: a call to Rack.getItem will _always_ return an
>instance - if SQL_get returns no rows then it just ends up with no
>attributes.

Right, because the object already has an id.


> I could always just get brutal and insert it into the database directly but
>I think that would really be missing the point ;^)  How do I make
>Rack.getItem return None in this case?

Change to using a load attribute that's actually dependent on the result of
the query.


>- what is the best way to use auto generated ids from the database? Override
>the Racks newKey method to get a new value from the db?

Yes, actually.


>- what are Common Instance property sheets and dataskin attribute property
>sheets, available to zclasses derived from DataSkin?

The differentce is that CIPS don't work with ZPatterns, DAPS do.  The
problem with CIPS is that they store default property values directly in
the class, which nullifies the effect of attribute providers (as you've
seen yourself with the 'id' property!).  DAPS save the properties in the
class as 'class_default_for_X', which DataSkins will look at if no
attribute provider is available.

>- Have SheetProviders been implemented in ZPatterns? How are they used?

Yes, just the "PersistentSheetProvider".  Its primary purpose is to allow
you to store arbitrary WebDAV properties for an object.


>- is there any more doco available about this sort of thing? At the moment i
>have the wiki (which is excellent) and the SkinScript syntax guide.

That's pretty much what's available at present, apart from the source code
and mailing list archives.  (Zope-dev as well as ZPatterns.)