[Zope3-dev] Interfaces and Schemas

[Stephan Richter]

On Friday 08 August 2003 16:58, Steve Waterbury wrote:
> Basically, I see schemas and interfaces as complementary, and
> perhaps "equal" in a sense. 

In Zope 3, Schemas and Interfaces are equal all the way!

> The idea I'd like to propose is 
> that an interface could have a schema associated with it, and
> that they could be similarly named -- e.g., an IDocument and
> an SDocument.  And there should probably be well-defined
> (i.e. testable) relationships between the methods of IDocument
> and their effects on the "fields" (which in some cases may be
> state-dependent) of SDocument.  And each could have families
> of Adapters, which in general would be quite different.

This was our original design, but Jim was hitting with a hammer on my head 
insisting that this is not a good idea. :-) I believe him now. The separation 
between interface and schema objects would be artificial and would introduce 
a lot of unnecessary complexity. 

BTW, you contradict yourself here; first you tell me that schemas and 
interfaces should be equal, but then you write about a separation of the two.

> Any class then could implement either the interface or the
> schema (or both, or neither), but presumably there would at
> least be a Document class that implements both.

Note that you can easily do this:

class IUserData(Interface):

    username = TextLine(title=u"Username")

    password = Password(title=u"Password")

class IUserMethods(Interface):

    def authenticate(password):
           """Try to authenticate the user..."

class IUser(IUserData, IUserMethods):
     pass

We think that this separation is YAGNI! Note that we also usually do not 
specify accessor and mutator methods, since we use Python's property 
functionality. 

> Is that concept compatible with Zope 3's architecture?
> (From what I've read so far, it isn't quite compatible, but
> might be doable.)

How is it not compatible?

> Perhaps more importantly, is it of interest at all?

Seperating Interfaces and Schemas? Probably not in the near future. We are 
really happy about our Interface/Schema functionality.

> (It is of direct use in my application because I have an O-R
> mapping to a PostgreSQL backend, and schemas and interfaces will
> all be persistent in the registry that drives the mapping, so I
> will implement something like this one way or another. :^)

Sidnei Da Silva has worked and is working actively on an integration of 
SQLObjects, which he demoed already. He is currently working on Persistent 
Schemas, so that you can create new database objects on the fly.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training