[Zope3-dev] Index integration

[Jim Fulton]

Dieter Maurer wrote:
> Jim Fulton wrote at 2005-2-16 07:24 -0500:
> 
>>...
>>BTW, a possibly simpler take on your proposal:
>>
>>Object-change adapters (Masks?)
>>
>>- We can adapt an object to an interface that
>>  captures just the relevent change.
>>
>>- We arrange that the adapted object adapts to the same
>>  reference and thus gets the same unique id
>>
>>- The adapted object is only recognized and thus
>>  only indexed by the relevent indexes.
>>
>>Perhaps these adapters are "filters" or "masks", the
>>opposite of decorators.  Rather than adding interfaces
>>to an object, they mask out interfaces.
>>
>>With this approach, indexes (or catalogs) don't need to
>>be aware of what's going on.
> 
> 
> I cannot yet say that I am fully familiar with Zope3 and
> its concepts.
> 
> But, I expect that objects usually are not modified directly
> but via adapters.

I don't think this is usually the case, but certainly it is
often the case.

 > It would be nice (from my point of view)
> when we could arrange that eventing the adapting object
> performs the "right thing". This would mean code like this:
> 
> 	 meta_data = IDublinCoreMetadata(object)
> 	 meta_data.setXXX(...)
> 	 zope.event.notity(ObjectChanged(meta_data))

Yup

> When we could arrange that the adapting object (meta_data in the
> example above) adapts to the same reference as "object",
> then all applications that need the "true" object ("object" above)
> could use the "ReferenceAdapter" to get it.

Yup

> This approach would make catalog and indexes happy.

I think so.

> However, I recognize that maybe not all applications might be
> happy.

I'll note that Catalogs in Zope 3 are much less ambitious.
They don't try to make everybody happy. :)

I think a variety of design patterns will emerge.  The idea
we're discussing is just one.

 > We did also change "object" (in the example above)
> and applications that subscribe to
> "(some interface of "object", IObjectChanged)" would not see
> such motifications -- neither with this approach nor with
> filters/masks...

It's really hard, or perhaps, impossible to know the right
thing to do in the abstract.  I don't think we should try.

I think it will be much clearer what to do for specific
applications and, hopefully, the catalog framework will
provide enough flexibility to make it easy to do specific
things. If not, then better framworks will emerge.

> Here is another idea that works around this problem -- and
> is along the lines of your "filter/mask" proposal.
> 
> We add a new event "SubobjectChanged(object, subobject)"
> derived from "ObjectChanged". "subobject" would describe
> the interfaces that were changed. In the example above,
> the notification would take the form:
> 
>     zope.event.notify(SubobjectChanged(object, meta_data))
> 
> 
> Applications interested in any change to "object" would
> subscribe to "(some interface of "object", ObjectChanged)".
> Indexes would subscribe to "(interface of index, ObjectChanged)"
> and "(None, interface of index, SubobjectChanged)".

(Minor detail: indexes don't subscribe. Instead, there are subscribers
  that dispatch to catalogs, which dispatch to indexes.)

> Unfortunately, index integration might be even more difficult,
> because an index might be willing to use an adapter to
> transform an object into the interface handled by the index.
> But this is a problem separate from the one to indicate
> "which part of an object changed".

Right.

I dunno.  I suggest trying some things as you need to for
specific projects.  The Zope 3 catalogs frameworks are simple
enough and open enough to try out different strategies.
Over time, we'll find out what works for particular kinds of
situations.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org