[Zope-dev] Re: Future of ZClasses

[Philipp von Weitershausen]

Lennart Regebro wrote:
> On 9/27/06, Andreas Jung <lists at zopyx.com> wrote:
>> It's definitely time to work on a replacement.
> 
> Yes. And here is my short vision of that. Comments are appreciated.

Have you looked at zope.app.schemacontent, Sidnei's prototype for 
TTW-schemas and content based on that?

> 1. We have a base content class used to create content objects. This
> has the concept of type, pretty much like CMFs portal_type. The type
> is defined in the ZODB.

Possibly. It's important to keep this content class really really dull 
("one size fits all") so that we don't need to magically create 
persistent classes or something.

> 2. On the type you can set marker interfaces,

Why not set marker interfaces directly on the objects? That whole "type" 
thing is unnecessary. Just use interfaces.

> that enables adapters with different functionality, such as indexing
> awareness, and whatnot.

Yes and no. "catlaog awareness" is a Zope 2 thing, with the CA you'd use 
events.

> These adapters are written in diskbased pythons. Hence any type of
> basic functionality like this still needs to be disk-based.

Except for views, perhaps. Simple template-based views could still be 
done through-the-web, perhaps even views that are implemented as Python 
Scripts.

> 3. Each type also has schemas

Type, schema, and interfaces should be synonymous: interfaces. Don't 
invent more concepts than we already have.

> and forms,

those can be automated from the schema

> 4. When you then run into a thing you can't do through the web you are
> not stuck.

Wrong. You write it in Python and register it locally for your "type" 
(read: interface).

> If you want to add new event handler for your type, you can write a
> new functionality adapter on disk, and then enable it via marker
> interfces for your type.

No need for the marker interface. You already have your "type" 
interface. Just use that.

> If you python scripts security becomes a
> hindrance, you can easily move that to disk by making another marker
> interface and building views for that. We could even have a button
> "Export to disk module" which exports the current templates + scripts
> to a view + methods + templates all on disk.
> 
> This combines and easy plug-and-play attitude with TTW programming
> without providing a dead end.

Hopefully.

So, when are you going to write it? :)