Steve Alexander wrote:

reindex_object is a method of the mix-in class CatalogAwareness.

Ah, that's okay then, since Squishdot doesn't have anything to do with CatalogAwareness.

I think calling index_object should work, as a well-implemented catalog will do the right thing. However, calling reindex_object makes your intentions more explicit.

AFAICT, the catalog doesn't have a recatalog_object method and the comments for catalog_object in ZCatalog.py suggest it can be used to re-cataloging and well as cataloging. ...in which case, I wonder why CatalogAwareness goes to the trouble of unindexing and then re-indexing? answers on a postcard, or email ;-) cheers, Chris

Michael Bernstein wrote:

Hmm. Aren't postings CatalogAware? If they're not, shouldn't they be?

Why? ;-) Squishdot manages the cataloging, re-cataloging and un-cataloging of its own postings. I don't think CatalogAware would make that process any simpler or more reliable... *grinz* Chris

Michael Bernstein wrote:

I guess it's just a matter of only reinventing the wheels you have to, and writing less code as a result.

I'm pretty sure Squishdot is re-inventing no wheels ;-)

http://www.zope.org/Members/tseaver/inherit_ZCatalog http://www.zope.org/Members/AlexR/CatalogAware

These are both pretty old and seem to be aimed at ZClasses. Squishdot has nothing to do with ZClasses. CatalogAwareness is of no use for a product like Squishdot. Squishdot already inherits from ZCatalog. cheers, Chris

Michael Bernstein wrote:

If you are writing your own cataloging and uncataloging code, then I think that it could be.

Grrrr.... The cataloguing code in Squishdot amounts to about 4 lines, all of which are calls to standard ZCatalog interface methods as described in: http://www.zope.org/Members/michel/Projects/Interfaces/ZCatalog If you don't believe me, grep squishdot.py for catalog_object and uncatalog_object...

I was asking why Posting objects shouldn't inherit from CatalogAware?

That wouldn't actually change the number of catalog-related lines of code in Squishdot. It was merely increase the compelxity of the product by adding CatalogAware as another base class for postings.

I don't think that only ZClasses can inherit from CatalogAware, that doesn't seem quite right.

CatalogAware isn't quite right ;-) cheers, Chris

Chris Withers wrote:

Michael Bernstein wrote:

...

If you are writing your own cataloging and uncataloging code, then I think that it could be.

Grrrr....

The cataloguing code in Squishdot amounts to about 4 lines, all of which are calls to standard ZCatalog interface methods as described in: http://www.zope.org/Members/michel/Projects/Interfaces/ZCatalog

If you don't believe me, grep squishdot.py for catalog_object and uncatalog_object...

Ok, I believe you! Don't get mad just beacause I was asking a question. I guess I didn't understand. In fact, if catalog_object and uncatalog_object are interchangeable with index_object and unindex_object, then I'm sure I don't understand the point of inheriting from CatalogAware at all. Is it reindex_object, which doesn't seem to have an equivalent?

...

I was asking why Posting objects shouldn't inherit from CatalogAware?

That wouldn't actually change the number of catalog-related lines of code in Squishdot. It was merely increase the compelxity of the product by adding CatalogAware as another base class for postings.

All right. Scratching-my-head-over-this-whole-CatalogAware-thing-ly yrs, Michael Bernstein.

[Chris Withers] | The point behind CatalogAware was, as I understand it, that the object | inheriting from CatalogAware wouldn't have to worry about managing its | own indexing. Sadly, that didn't work out... I haven't been following this discussion, so my question may be redundant, and if it is I'm sorry. :) Are you saying that, as a general rule, inheriting from CatalogAware and using index_object, reindex_object and unindex_object does not work? Or, probably more likely, are you saying that since you have to put index_object in the __init__ method you consider it to be managing its own indexing? Thanks :)

Chris Withers wrote:

Erik Enge wrote:

...

Are you saying that, as a general rule, inheriting from CatalogAware and using index_object, reindex_object and unindex_object does not work?

It probably does, but if you're a catalog yourself anyway, as Squishdot is, it just more overhead rather than calling your own catalog_object and uncatalog_object methods ;-)

Aha! You're saying that catalog_object and uncatalog_object are methods of the catalog, so when the catalog contains the objects directly, it's all that's neccessary, correct? index_object, unindex_object, and reindex_object (the CatalogAware methods) are all methods on the object to be indexed, not methods of the catalog, as I understand. When called, they find the nearest (acquisition-wise) ZCatalog (named Catalog by default), and cause catalog_object and uncatalog_object to be called on it (I'm not sure what method reindex_object causes to be called). So, postings would only need to be CatalogAware if you wanted them to be able to 'live' anywhere within the Zope heirarchy, instead of being contained directly within the Squishdot object (which inherits from ZCatalog). Do I have this correct? Michael Bernstein.

Erik Enge wrote:

[Michael Bernstein]

| When called, they find the nearest (acquisition-wise) ZCatalog | (named Catalog by default),

I think you can specify the ZCatalog it should index itself in by putting the default_catalog attribute in your class.

Your example is correct as far as it goes, but as I understand it, you are not really specifying the default catalog per se, but the default catalog *name*. Therefore, it will then look for the nearest catalog of the name that you have redefined as the default. So if you redefine it to be ZCatalog1, and you have the following structure: / |-/Catalog | |-/ZCatalog1 | |-/folder1 | | | |-/folder1/ZCatalog1 | |-/folder2 Assuming a CatalogAware ZClass has had it's default_catalog defined to be 'ZCatalog1', and that an instance of this ZClass is then added in /folder2, it will index itself in /ZCatalog1, whereas an instance that is added in /folder1 will index itself in /folder1/ZCatalog1. This is my current understanding, I apologise if what I've said is incorrect. HTH, Michael Beernstein.

Michael Bernstein wrote:

Aha!

You're saying that catalog_object and uncatalog_object are methods of the catalog, so when the catalog contains the objects directly, it's all that's neccessary, correct?

Yes :-)

uncatalog_object to be called on it (I'm not sure what method reindex_object causes to be called).

unindex_object followed by index_object. I'm not convinced it's necessary, as no-one has said that uncataloging is a necessary step before catalogng something that's already in the catalog.

So, postings would only need to be CatalogAware if you wanted them to be able to 'live' anywhere within the Zope heirarchy, instead of being contained directly within the Squishdot object (which inherits from ZCatalog).

Yes, but Squishdot postings are intimately tied to the Squishdot folderish object anyway, so that's not going to happen ;-) cheers, Chris

Chris Withers wrote:

Michael Bernstein wrote:

...

uncatalog_object to be called on it (I'm not sure what method reindex_object causes to be called).

unindex_object followed by index_object. I'm not convinced it's necessary, as no-one has said that uncataloging is a necessary step before catalogng something that's already in the catalog.

I have no idea one way or the other.

...

So, postings would only need to be CatalogAware if you wanted them to be able to 'live' anywhere within the Zope heirarchy, instead of being contained directly within the Squishdot object (which inherits from ZCatalog).

Yes, but Squishdot postings are intimately tied to the Squishdot folderish object anyway, so that's not going to happen ;-)

I understand. Thanks for your patience. I now have a better understanding of ZCatalog and CatalogAwareness. Now I'm wondering how to duplicate the behaviour of Postings being contained within Squishdot, but not appearing in the 'Contents' tab. Cheers, Michael Bernstein.

Chris Withers wrote:

Michael Bernstein wrote:

...

Now I'm wondering how to duplicate the behaviour of Postings being contained within Squishdot, but not appearing in the 'Contents' tab.

that's definitely a 'bad' thing :-(

Why is that bad? A custom object management UI ('Postings' and 'Moderation' tabs) seems appropriate for Squishdot. I wouldn't want to manage postings from the standard management interface.

Why duplicate anyway? You writing a replacement? ;-)

No, I'm creating two different applications, an image archive and a book catalog. Both need to handle large numbers of items. The standard management interface does not scale to the number of objects involved from a usability perspective. Neither of my projects need objects to nest (as squishdot postings do) so I don't need to duplicate the tree interface, but instead I'll probably create a batching interface to allow relatively easy access to all contained objects. I'd like to know how to prevent the objects being listed in the 'Contents' tab, while still allowing other objects (like DTML methods) to be added there. Any clues? Michael Bernstein.

Chris Withers wrote:

Michael Bernstein wrote:

...

No, I'm creating two different applications, an image archive and a book catalog. Both need to handle large numbers of items. The standard management interface does not scale to the number of objects involved from a usability perspective.

Look at Shane Hathaway's BTree Folder :-)

Interesting idea, I hadn't considered that as a solution. Has anyone created a ZClass that inherits from BTree Folder and ZCatalog?

...

I'd like to know how to prevent the objects being listed in the 'Contents' tab, while still allowing other objects (like DTML methods) to be added there.

Well, all the postings are actually stored in SquishSite.data, so they're not actually 'contained' in the SquishSite object, hence they don't show up in the contents tab. A bit of magic in SquishSite.__getitem__ makes the postings URL traversable.

Interesting. Thanks for the info. I've been using Squishdot a long time, and I never knew that. Michael Bernstein.