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 fairly easily. > > 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 objects. > > 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 not. 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 application itself. /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association [EMAIL PROTECTED] \---------------------------------------------------/ _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
