[TransWarp] SkinScript-to-Jars phrasebook, deleting objects, and terminology

[Phillip J. Eby]

At 04:55 PM 7/1/02 +0200, Ulrich Eck wrote:
>
>will it be possible to "transparently" change storage jars,
>without modifying Elements that use it ??? so one could
>switch between ZODB-storage jar and sql-st.jar (thinking
>of query-issues and oid-incompatiblities,different name-mappings)

You'll still hide such matters behind Specialists.  It's just that the
mappings from Specialists to the next layer down will be relatively thin
and lightweight, the way they were in ZPatterns.  In ZPatterns, Racks did
the majority of the "heavy lifting" of managing objects, and the same will
be true of jars or racks or whatever we end up calling them.

Specialists will continue to be important in Zope 3 and PEAK, but less so
than in Zope 2 and ZPatterns.  For example, it's going to be rare for your
domain-level classes to actually do anything with Specialists, and for your
Specialists to have much code at all.  The user interface code that used to
go in Specialists for themselves and as snippets for domain objects can be
replaced with Zope 3 "views", for example.


>is a query-jar also for retrieving obj.ids (e.g. a list of
>person-oids), 

Not really.  I'm assuming that you will generally want either record-like
(non-object) results, or lists of actual objects.  I mean, you could
certainly make such a jar as you describe, I just imagine you'll rarely
need such a thing, unless the application domain has a use for it.  And
even that seems rare, because usually you want at minimum an ID *and* a
human readable identifier if you're doing some kind of list display.


>and will it implement native-filters or
>a unified (OQL-like) QL ??

If you make a query jar, it'll be to implement *one* query, that is
parameterized by its OID.  Of course, you can use tuples or other objects
as OIDs, so they can actually contain multiple query parameters.  For
example, a query jar based on first and last name called "byName" might be
usable thus:

listOfPersons = byName[ ("Phillip","Eby") ]

As you can see, this concept allows queries to be cached quite readily, as
well as allowing them to be treated as objects which can be placed in other
objects, to be loaded upon actual use.  That is, 'listOfPersons' in the
example above isn't actually a list of the persons, but a *ghost* of a
PersistentList of persons.  Trying to access any attribute of
'listOfPersons' will cause the query to execute, creating a set of
(possibly preloaded) ghost persons in the PersistentList.

Anyway, no, query jars won't support any external filtering or query
language against their contents.  Query jars *encapsulate* a query so that
the rest of the app doesn't have to know how it's implemented.


>a DataLayer definition would look similar to the
>current as done in DataModel? (don't count on the
>class-names .. just my imagination :)

I don't know exactly what the layout will be like, but certainly it will be
a structure of components within components as TW DataModel layers were.
Probably there will be a clustering of jars with their "root type" jar, as
RecordTypes clustered under RecordManagers in TW DataModel.


>or it is loaded via xml/etc config .. am I right ??

That would certainly be nice; and I've also thought that it could actually
be loaded directly from the database's own knowledge of the DB schema!  But
initially we will be doing this by hand, of course.