[Zope3-dev] Re: [Z3lab] Why use relations?

[Jean-Marc Orliaguet]

Janko Hauser wrote:

>
> Am 31.08.2005 um 10:25 schrieb Jean-Marc Orliaguet:
>
>> Hi !
>>
>> I have been thinking about Jim's question: "why do you need 
>> relations?".
>> Some obvious answers came first others emerged later on, now I think
>> that most of them are emerged, so I'll try to summarize them by 
>> order of
>> importance (to me):
>
>
> I'm in support of most of your points, although I do not see that the 
> catalog is actually proposed as an alternative. Jim's suggestions 
> were more directed to store things in each other. Or reference them 
> somehow, but not by an indirection with a central index.
>

HI!

My intuition is that if you store "things in each other" you have
implicitly created an index as soon as the objects get cataloged.

Usually you start storing information about other objects in the objects
themselves thinking: "my application will only need to work that way,
the information belongs here ..." Later on, some use case forces you to
think differently and use a different approach, e.g. containment,
traversals, acquisition (if the information is not there, then look for
it there instead ...)

Then you see: this is too slow, I need to create an index in the catalog..

But this is another discussion that has more to do with the actual
implementation of the application than some explicit design.


>> I think that it is important for the Z3ECM project to state why to use
>> relations? Jim's question was very pertinent.
>
>
> Actually in the frame of the Z3ECM project I really do not see, how 
> we can not use an "explicit" relation system. On the other hand, much 
> of this discussion was crossposted also to z3-dev, which means, that 
> not everything in the z3-core should start to be dependent on a 
> relation system. And an important of part also of z3-core is the 
> creation of UI for the applications.
>
> Zope is all about object relations all the time, the most obvious is 
> the parent, child relation. Another is the interface relation 
> expressed in ZCML. The dependance on containment made many Z2 
> products difficult to reuse, because one needed to pull things out 
> from some other application container. I see relations as an 
> important way out of this. They support the notion of small, dumb 
> objects, which are assembled by adapters to bigger parts.
>
> If they are needed for a proposed UI system I can not judge, as I 
> haven't installed and looked at it.
>
> __Janko
>
>

Yes, I know that there is no such thing in Zope3 currently, and that
containment works best on tree-like structures and that it is not the
answer to everything :-) But shouldn't there be an interface definition
for plugging in / querying different relation stores in the same way?

It is weird to think: Z3ECM needs it, but Zope3 does not need it (at
least define a base interface would help make different implementation
compatible ...)

the question is much wider than the UI system issue.

/JM


I quote the original message, maybe I should have sent it to zope3-dev also:

=========== QUOTE ==============================

Hi !

I have been thinking about Jim's question: "why do you need relations?".
Some obvious answers came first others emerged later on, now I think
that most of them are emerged, so I'll try to summarize them by order of
importance (to me):


1/ Being able to create new functionality in the application without
changing the schema of the content objects.

In cpsskins the content classes (pages, cells, slots, portlets, styles,
widgets, layouts, perspectives, ...) are minimal: they have a title (if
needed), a unique ID automatically generated by IntIds, a type, if they
need to be classified in subtypes, and that's all. For instance to
create the new functionality "perspective" I added a new content class
(Perspective) and a new kind of relation (hasPortletFromPerspective),
but I did not modify the schemas of existing content classes.

So new functionality in the application means:

- new relation predicates

or

- the same relations and elements, but connected differently.

a lot of time spent on refactoring of an application comes from having
to modify the schema of classes to add new functionality to the
application and update all the code in python / zpt, create migration
scripts...

this follows the DRY (don't repeat yourself) concept, on content
objects, i.e. don't write more code if you can re-use already existing
objects but connect them differently.

Zope3 implements this idea on a component level by using adapters.


2/ Explicit relations vs implicit relations.

The relations between the elements are *explicit*, as opposed to the
relations implicitly stored in an object catalog (e.g. z3 catalog) that
indexes objects and that also tries to index the relations between the
objects creating new types of indexes (path index, date index, ..).

E.g. if the "style" attribute is stored in a "portlet" in z3 catalog,
the style will be indexed  and considered has one side of a dyadic
relation between a portlet and a style. Implicitly it means (portlet) "_
has style _" (style). It it up to the application to know that the
"style" attribute means "_ has style_"

This is by the way known in philosophy as the "fallacy of reification",
i.e. converting something abstract (a relation) into something concrete,
e.g:

   (something) _ is sweet

becomes:

   (something) has (sweetness)

cf http://en.wikipedia.org/wiki/Reification


3/ Import / export

Relations can be exported / imported very easily because they are
explicit. They are not mixed up with other catalog entries. The elements
are exported easily too, their schema is extremely simple (no
complicated export schemas).


4/ Portability

The notion of relation is universal, it is not Zope-specific. A relation
says nothing more than: elements are connected together using some
predicate. implementing new relation stores is a matter of implementing:

- the notion of predicate
- the notion of relate (the elements being related)

this can be done in almost any technology.

It means that the data is not bound to Zope objects



I think that it is important for the Z3ECM project to state why to use
relations? Jim's question was very pertinent.

Unfortunately the discussions so far on the list have had to do with the
technology used for the implementation and not why it is used.

/JM


-- http://lists.nuxeo.com/mailman/listinfo/z3lab

=========== END QUOTE ===========================