[Zope-dev] How is 'retrieveItem intended to work with TTW Specialists?

[Phillip J. Eby]

At 08:05 AM 9/30/00 -0500, Steve Spicklemire wrote:
>
>I'd hate to find out later that someone needs to go in and edit my Python
>code to make my framework useable.... But.. I think what I'm hearing is that
>working out the integration at the Rack level is much better than trying
>to delgate retrieval at the Specialist level. I'm not sure where I got the
>idea that delegating retrieval at the Specialist level was the 'right' way,
>maybe in the Drop Zone example? Anyway... thanks again for your reply. I'll

You might have gotten it from there, in that the example doesn't get into
any detail of *how* retrieval gets delegated.  There are many ways to
delegate retrieval, but direct delegation is only useful in the case where
the thing you're delegating to already has the interface you want.  In the
example, it was assumed that the SkyDiver implemented the interfaces needed
by the different black-box frameworks being re-used, and therefore
delegated retrieval would have been the appropriate customization of the
white-box specialists.  The point, however, is that it's the application
integrator's job to rip up your white-boxes in whatever way it takes to do
the integration.  Again, if they have built their crossover class (e.g.
SkyDiver) according to the interface required by the white-boxes, then
their customizations are trivial.  If not, then they must do more work.

If you want to make sure that someone needn't edit Python code, all you
have to do is ensure that your Specialist never does any data manipulation
except through altering attributes or propertysheets on a DataSkin, and
that any multi-item methods (e.g. search methods) are TTW-overrideable
methods (using the __replaceable__ property in your Python code).  Then,
the integrator can override those methods with SQL queries or catalog
queries or whatever, and they can script the mappings of the DataSkin's
attributes into whatever behavior they want.


>march happily along now and see what I run into next! ;-) (I'm especially
>grateful for your explaination of using a virtual object (non-persistent)
>in a Rack. I've not seen that explained so clearly anywhere else.. and I'm
>going to use it!

Great.  By the way, that is also how one makes a rack that retrieves
objects from an SQL or LDAP database.  You do a WITH/COMPUTE on the query
that retrieves the record and maps it into the attributes you want.  The
latest version of SkinScript (not yet released) now has a QUERY keyword
that makes use of SQL/LDAP queries easier, as you can do:

WITH QUERY someSQLMethod(key=self.id) COMPUTE foo,bar,baz

instead of having to do this junk:

WITH (someSQLMethod(key=self.id) or [NOT_FOUND])[0] COMPUTE foo,bar,baz

There is also now an OTHERWISE LET clause for WITH/COMPUTE that lets you
specify default values in case the query doesn't find a record.  These and
a few other new SkinScript clauses should be out in 0.4.3, sometime
mid-October.

Ty and I have also developed some advanced tricks to allow an SQL database
to refer to objects which are in LDAP or the ZODB, allowing one to store
different parts of your data in databases which have the best performance
or handling characteristics for that kind of data.  However, to use these
tricks you must specifically design your SQL database for the purpose.
It's not terribly tricky, but it's a whole 'nother pattern language of its
own, and we're not ready to "publish" yet.  Especially since at this stage
it'll be just another thing we've invented but not thoroughly documented
for others to take advantage of.  :(