[TransWarp] Website up, 0.2 release out
Phillip J. Eby
pje at telecommunity.com
Tue Mar 5 15:21:19 EST 2002
At 12:12 PM 3/5/02 -0500, Steve Spicklemire wrote:
>Cool! This looks great. I can't wait to dig in... can you suggest a good
>place to "start"?
Hm. It depends a lot on what you want to do with it...
> (e.g., if I want to think about converting a ZPatterns app to
> TransWarp... where would I begin?)
Well, you could start looking at the TW.Database.DataModel
package. TypeManagers and RecordTypes are rather like a lower-level
successor to the concept of a Rack, but also very different in that they're
designed to manage low-level database caching and transactional issues, but
not the translation of database values into domain attributes.
Specialists are just not there yet. Specialists will be much as they were
in ZPatterns, but most of the database<->domain translation (analagous to
SkinScript) will be in objects contained in Element classes. Elements are
a bit like dataskins, in that they represent domain objects, and delegate
Here's what ZPatterns-ported Zope 3 application components will probably
look like in TransWarp: you'll have a Python module which defines some set
of application domain classes and associated Specialists. Only domain
logic will be specified there, no UI code (since you can do that with Z3
views) or implementation-specific code. This is the "domain layer" of this
portion of your application.
Then, you'll have an implementation module, which inherits from your domain
logic module. There, you can flesh out any implementation-specific code,
such as the SkinScript-like mappings of domain-level Element attributes
onto data layer fields. You'll also flesh out your Specialists with
implementation methods here. This module is the "dispatch layer" of your
Next, you'll have other modules that spell out your data layer. The data
layer has new abstractions like Database, TypeManager, and RecordType. A
Database contains some number of TypeManagers, which in turn contain
RecordTypes. Each TypeManager represents a family of related datatypes
with a common root type. An SQL database will typically have many such
type families, while an LDAP database will usually have only one (since all
LDAP "objectclasses" essentially derive from "top").
The Database object manages a Connection to some type of database, and also
interacts with the application's TransactionManager to perform typical
"pickle-jar" support for Record objects. Records are retrieved from
TypeManagers or RecordTypes, with the TypeManager implementing record
caching and the RecordTypes implementing storage and retrieval methods.
Last, but not least, you'll need an application to contain and make use of
these layers. The application will contain component instances for your
data layer, and for your dispatch layer. (The domain layer is effectively
abstract, and simply inherited into your dispatch layer, which is an
implementation-specific version). The application will also contain
instances of any other components needed to complete the
structure. Currently, an application object would be created in a module
and then exposed to ZPublisher, but at a later stage of things it should be
possible to have persistent instances of all the "static" application
components such as Specialists, etc.
In a way, TransWarp is taking an opposite tack to ZPatterns (as Zope 3 is
to Zope 2). That is, I'm building *first* for filesystem-oriented
development, and persistence second.
>Sorry to hear about your wrist...
It's our good old friend, carpal tunnel syndrome. :( My hands are feeling
a little bit better today, so perhaps tomorrow I'll be able to begin work
on Specialists and the like.
By the way, please keep in mind that 0.2pre1 is not anywhere near where it
needs to be to allow someone to even partially port a ZPatterns app. 0.2
final should be capable of porting a ZPatterns app that:
1. Uses SQL or LDAP for data storage (no ZODB support planned before 0.3!)
2. Is filesystem based (no persistent Specialists etc.)
3. Doesn't need 100% compatibility with Zope 3 or 3X (0.2 final is targeted
for Zope 2 ZPublisher-only applications)
Hope that clarifies the current status better.
More information about the PEAK