[Zope-dev] Re: Future of ZClasses

[Lennart Regebro]

Thanks for the comments. For all the things you wrote that I deleted,
I would just say "Exactly!" :-) Here are the things that are not
"exactly!":

On 9/28/06, Philipp von Weitershausen <philipp at weitershausen.de> wrote:
> Have you looked at zope.app.schemacontent, Sidnei's prototype for
> TTW-schemas and content based on that?

Nope. But thanks for the hint.

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

Because you want to be able to add a new functionality (by setting a
new marker interface on the type), and get it added to all the objects
that have that type. Of course, the type assignment would, I expect,
in itself be done by a marker interface, but that's implementation
details I don't want to think about yet. :-)

I was unfortunately talking too much implementation details. I should
have tried to be more conceptual. From now on, I will call the
functionality adapters for "aspects". :)

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

Well, that was the one example I could think of just then, although I
knew it was a crap one. I could think of specialized aspects, such as
an aspect to automatically ping a site like del.icio.us when you post
your bloggentry, but I couldn't think of anything truly generic.
However, during this answer, I did think of something better:
Workflows:

You could for example have an aspect for a simple publishing workflow.
So if you enable this, the objects of the type gets a publishing
workflow. And another aspect could enable the wmfc workflow module for
the object, for example. (Which makes me realize that some aspects
could need settings on the type... Hmmm...)

> > 3. Each type also has schemas
>
> Type, schema, and interfaces should be synonymous: interfaces. Don't
> invent more concepts than we already have.

Nah, they should not be synonyms. But I was as mentioned mixing
implementation and concepts before. I'll explain:

The people who use these new ZClasses want to be able to create
content types that has forms with a set of fields and informations
like if a field should be required or max length and stuff. They also
want to be able to create specialized views, and enable "aspects" for
the type, like saying that objects of this type should have this
workflow.

They will never understand you if you call both the forms, and the
views and the aspects for "interfaces", because although technically
there are interfaces below all of this, the functionality in the end
is wildly different, and the way you use it is also wildly different.
How all this is implemented and attached to the object is nothing the
user want to be aware of.

However, you may be right in that maybe one schema, and a set of
views, in themselves should be an aspect, so that you do not assign
these to types, but you create a form-aspect and a view-aspect, and
assign these to the type.

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

I think you missed a "not" there. :)

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

Yes, and no. If I do that, I can't use the aspect for other types.
Then I'm stuck with using it ONLY for that type. This may be what I
want, or it may not be.

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

My crystal ball blue-screened. :-)

-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.cps-project.org/