[Zope-PTK] RIPP Discussables

Phillip J. Eby pje@telecommunity.com
Mon, 01 May 2000 19:29:09 -0500


At 07:26 PM 5/1/00 -0400, Kevin Dangoor wrote:
>
>On a more serious note, how would you implement categories of messages?
>Would there be a sort of "root message" for the category that everything
>hangs off of and then you have a discussable object for the category that
>requests that thread?

Depends on what you mean by categories.  If you mean categories as forums
where you discuss things related to that category, then that makes sense.
If you mean categories that cut across forums, then the below is more
relevant.


>If each Specialist has its own search routines, how would one go about
>implementing a site-wide search? I guess the Racks could all register their
>objects with a specific catalog for easy searching...

A specialist just implements a place to call a search function.  That
doesn't mean it actually has to implement the search.  The racks could
indeed register items with a single catalog for this purpose.  In many
cases, it will suffice simply to place a Catalog inside the Specialist
where it can be acquired by the Racks, or use one above the Specialist if
it is common to more than one Specialist.  In the situation where you have
more than one Specialist covering the same general kind of objects (e.g.
discussion messages), it is probably a good idea to have a shared search
mechanism.  The nice thing is that nothing cares - everything just asks its
local specialist for what they need, and in effect the Specialist will
perform a similar "just ask its Catalog (search specialist)" operation.

I'm working on Catalog handling for future versions of the ZPatterns
package to support this more easily - probably by queuing objects to be
updated in a catalog at transaction commit.  I say "catalog" as opposed to
"ZCatalog" because I want it to be generic enough to work with any object
which supports a simple indexing/registration API.  At some point Ty and I
would like to see a re-engineered ZCatalog done as a PlugInContainer using
PlugIns for indexes, so that you can develop SQLIndexes, LDAPindexes, and
other sorts of handy extensions.  But we won't work on that one
until/unless we really need it, as for lots of apps it is straightforward
to just add direct search capabilities to the underlying Racks and have a
Specialist delegate to it.