On Thursday 04 October 2001 07:34 pm, Jay, Dylan allegedly wrote:
> I tried using ZClasses but it seems to run slow and take up space. Instead
> I'm using Catalog (without ZCatalog) to contain the data. I'm presuming
> this will be quite efficient (comments welcome).
Yup that should be pretty efficient. Plus you can index and query the thing
> Now to my question, How do Catalog plugable brains work? I've looked but
> can't see what the brain class has to look like to work. My first attempts
> don't seem to work. The classes are created but don't contain the data. Is
> the record data passed into the constructor?
I'm not an expert on brains per se, but my understanding is that they allow
you to wrap functionality from a particular class around data stored in a
table (such as a Catalog or an external database) without making each record
an instance of the class.
This is how, when the Catalog returns data, you get the getURL and getObject
methods for each record (among others). TinyTable and Z SQL Methods also
support this functionality, and it is exposed in the management interface.
This would allow you to store the actual data as regular metadata elements in
the Catalog, and get objects out when you query it. It would avoid storing
the data twice, once in the objects and again in the metadata and all of the
disadvantages this causes in terms of storage and synchronization.
> Also in my searches I came across lots of references to something called
> ZTables. This seems to be a Catalog with a UI that is about lots of tabular
> information (rather than a ZCatalog which is specialized to replicating and
> indexing existing objects). Is this dead? If not where is it? If so, why?
AFAIK, Catalog contains the only remaining remnants of ZTables in Zope.
> It seems like a really good idea to me. It seems to be there are times when
> objects (esp ZClasses) are too heavy?
ZClasses impose a performance penalty due to their inherent complexity and
overhead. You would do much better creating a straight Python class for
applications where performance and overhead per record is an issue.
I personally avoid using ZClasses for everything but the simplest custom
> Anyone with comments about how ZPatterns fits into all of this would also
> be welcome.
My understanding is that ZPatterns is for abstracting the application from
the storage. It is most beneficial for creating storage-independent
applications. It would benefit you if that is a requirement, no so much if
An example might be an application with data in objects, catalogs and
external databases. ZPatterns would let you create an abstraction layer so
that the application would not need to be aware of where any given piece of
data was coming from. You could therefore change your data storage later and
ideally you would only have to change the abstraction layer, not the
Casey Duncan, Sr. Web Developer
National Legal Aid and Defender Association
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -