[Zope] Getting some documentation started....

Michel Pelletier michel@digicool.com
Wed, 18 Aug 1999 00:27:50 -0400


Lindon Parker wrote:
> 
> Bradford wrote:
> >If you'll tell me how to hook a ZSQL method for insert/update to dtml, I'll
> >jump back on now and start that chapter.  I'm not busy tonight...
> 
> So you guys at Digi did this right, and we'll be seeing Bradfords draft
> documentation here for review soon(ish) right?
> 

Good Question.  I also think that there are several good examples buried
in the past of the list.  Instead of coming up with a new one, it might
be possible to search for it on egroups (then again it might not).

> And whilst we're here if you'll tell me how to search through all the Zope
> objects in my site by some attribute and then display some (other)
> attributes, basically like a SELECT statement but not on a database instead
> on Zope itself(see I'm really new) I'll write that FAQ/chapter too...
> 

Well there is, of course, more than one way to skin this cat. Before
Zope 2.0, there was the find machinery, which would brute force search
through your objects looking for ones that matched certain criteria. 
This is, of course, not very efficient for the same reasons that full
text indexers don't use command line tools like 'find' and 'grep'.  They
are good one time use tools, but not efficient for lots of searching.

Zope 2.0 introduces ZCatalog.  ZCatalog is a very flexible and powerful
tool, and thus, probably requires lots of documentation.

ZCatalog works one of two ways, first, you can use the aformentioned
'Find' machinery to find objects on your Zope and 'catalog' them.  This
means that if a found object has an attribute your looking for, the
value of this attribute is stored in the catalog is a very fast BTree
like data structure.  By fast, I mean less than a second to find one out
of a million cataloged objects (my book on BTree theory says that
average case it takes only 20 simple comparison operations to find one
out of one million items, so it's probably a lot less than one second).

The tradeoff is speed for memory and database consuption.  Since the
catalog is storing lots of information about the object, such as
references to its values and such, ZCatalog can bloat your
database/memory footprint.

The second way ZCatalog works is trasparently with ZClasses.  If you
design your ZClasses right, they can automaticly catalog and uncatalog
themselves as they are created, destroyed, edited, and moved around
Zope.  This is wildly useful for things like News items.  If you create
your own 'News' ZClass that properly catalogs itself, you can create a
fully text searchable News system with little maitenance overhead.

Oh did I mention ZCatalog can fully text search?  That's right, one of
the indexes ZCatalog can create are 'TextIndexes'.

Thankfully ZCatalog comes out of the box fairly well preconfigured for
Zope.  Granted, you must add any additional attributes you want to find
that don't come stock, but be default ZCatalog will index id, creation
time and meta_type, and text index title and text content (if there is
any).

Note that ZCatalog does *not* create search forms for you.  But a good
template form and report document can be generated by the 'Z Search
Interface' wizard by selecting 'Add: ZSearch Interface' in Zope and
selecting the Catalog you wish to point the search form to.  You can
have as many types of search forms as you please.

There will be *many* upcomming usage examples in the new zope site,
which uses the Catalog extensivly on almost every page.

-Michel



> Lindon Parker
> TwoMoon Media
> 
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://www.zope.org/mailman/listinfo/zope
> 
> (To receive general Zope announcements, see:
> http://www.zope.org/mailman/listinfo/zope-announce
> 
> For developer-specific issues, zope-dev@zope.org -
> http://www.zope.org/mailman/listinfo/zope-dev )