[Zope3-dev] Containment constraints

[Steve Alexander]

> * We may want to impose containment constraints externally to a
>   container. For example, we may use a marker interface to
>   identify specialized containers according to use. Imagine a "news
>   folder" that is a specialized use of a folder. We want to constrain
>   news folders to contain only news items.

I anticipate that this will be a common kind of use, considering TTW 
development.


> * A container's setObject method has no way to check constraints
>   that items may place on their containers.

Right. We should look to separate this concern.


> Alternatively, we could provide IObjectAddedEvent subscribers that
> veto inappropriate combinations of containers and items.

That would be ok, but would be a hassle in the user interface. Imagine a 
UI where you are offered lots of things that you can do. But, you find 
that when you try to do those things, many of them are forbidden.
This could be fixed with "subjunctive events". That is, a UI element can 
send off an IPerhapsObjectAddedEvent. If sending the event causes a 
raised exception, then the related IObjectAddedEvent is forbidden. Thus, 
an action that would cause that IObjectAddedEvent is also forbidden.

A subscriber would listen for both IPerhapsObjectAddedEvent and 
IObjectAddedEvent, and would simulate actions for the 'perhaps' event, 
but still raise an exception.

You could get from an IxxxxEvent to an IPerhapsxxxEvent by adapting an 
event to IPerhapsEvent.


> It might be useful to abstract the containment constraints into some
> separate specification and registry. This would allow the constraints
> to be shared among adding, copying and moving. Possibly, it would be
> simpler to express abstract constraints than to write constraining
> code in the various adapters.  We would need to come up with some ways
> to express these constraints.

Yes, I agree.


> Note that most of these constraints are expressed as allowable
> combinations of interfaces. Also, we'll often want to add constraints
> to sub-types.

Do you think we need more arbitrary constraints too? It would be nice if 
we didn't...

What about an IFlame object can be added only to a message thread of an 
IMetaDiscussionBoard, but not to a message thread of an IDiscussionBoard.

In this case, the constraint would be about the context of the location 
an object is to be added, not just the location.
We can work around this case by making the (otherwise identical) message 
thread types have different marker interfaces: IMessageThread, 
IMetaMessageThread.

--
Steve Alexander