[ZPatterns] Re: [TransWarp] Website up, 0.2 release out

[Phillip J. Eby]

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 
implementation elsewhere.

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 
component.

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.