Re: [Zope-dev] CatalogAware Products and PropertyManager
On Thu, 13 Dec 2001, Dirk Datzert wrote: Hi, has anybody written a some hotfix-like product which makes the PropertyManager more CatalogAware ? I knew now that adding, changing, deleting properties of a CatalogAware object will not reindex the object, but I want to say that this would be a central point of interest of me. There is a similar Hotfix to make DTML Documents CatalogAware, I think it is called DocumentTools. It might work for what you are doing, or could be modifiable for your needs. -Matt -- Matt Hamilton [EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration ___ 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 )
Re: [Zope-dev] CatalogAware
Michael Bernstein wrote:
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.
Hmmm... it does mean you can't cut, copy or paste postings though, which
can be a pain sometimes :-S
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 :-)
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.
cheers,
Chris
___
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 )
Re: [Zope-dev] CatalogAware
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. ___ 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 )
Re: [Zope-dev] CatalogAware
Michael Bernstein wrote: 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*. snip This is true, and one of the reasons why I (and maybe only I ;-) consider CatalogAware somewhat less useful than it could be. cheers, Chris ___ 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 )
Re: [Zope-dev] CatalogAware
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 ___ 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 )
Re: [Zope-dev] CatalogAware
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 duplicate anyway? You writing a replacement? ;-) cheers, Chris ___ 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 )
Re: [Zope-dev] CatalogAware
On 1/5/01 7:16 AM, "Chris Withers" [EMAIL PROTECTED] 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. Actually this is where the luminous KeyError lurks. If you don't unindex_object first (prior to 2.2.4), then you could potentially have words in the forward index that your object no longer contains, and eventually it could get into a state where you get a KeyError. In 2.2.4 I modified it (rather bluntly) to always do an unindex_object before even starting the index_object proceedings... This is obviously rather heavy, but it did prevent a lot of faulty uses... CatalogAware was wrong, for example :-) In 2.3a2 (hopefully :-) and if not a3), Jim and I have developed some merging code that will do much more intelligent merging of new and old data, reducing the size of transactions in the Catalog, and also preventing things from being touched when in fact nothing changed---this can be responsible for 70-80% of the bloat in some sites. In addition, many needless objects were touched when they had no relevance to the object being indexed. This should also help reduce bloat. Speed, so far is on par, and eventually we hope faster for most sites. Chris -- | Christopher Petrilli Digital Creations | [EMAIL PROTECTED]Where Zope comes from ___ 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 )
Re: [Zope-dev] CatalogAware
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.
___
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 )
Re: [Zope-dev] CatalogAware
[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 :) ___ 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 )
Re: [Zope-dev] CatalogAware
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 ;-) Chris ___ 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 )
Re: [Zope-dev] CatalogAware
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. ___ 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 )
Re: [Zope-dev] CatalogAware
[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. I think, that this object (in pseudo) would index itself in ZCatalog1 def myClass(CatalogAwareness): default_catalog = 'ZCatalog1' def __init__(self): self.index_object() If you have the path: mysite.com/ZCatalog1/ZCatalog2/Folder1/myClassInstance Yeah? ___ 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 )
Re: [Zope-dev] CatalogAware
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. ___ 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 )
Re: [Zope-dev] CatalogAware
Chris Withers wrote: Michael Bernstein wrote: If you are writing your own cataloging and uncataloging code, then I think that it could be. G 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. ___ 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 )
Re: [Zope-dev] CatalogAware
Chris Withers wrote: 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 ;-) If you are writing your own cataloging and uncataloging code, then I think that it could be. 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. I realize that Squishdot is a Python product, of course. As far as the information being old, it's tested. I just used it to build a new application this week. No bugs. CatalogAwareness is of no use for a product like Squishdot. Squishdot already inherits from ZCatalog. I realize that Squishdot already inherits from ZCatalog, I was asking why Posting objects shouldn't inherit from CatalogAware? I don't think that only ZClasses can inherit from CatalogAware, that doesn't seem quite right. Again, it's certainly possible that I'm overlooking something. Cheers, Michael Bernstein. ___ 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 )
Re: [Zope-dev] CatalogAware
Chris Withers wrote: 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... I guess it's just a matter of only reinventing the wheels you have to, and writing less code as a result. Squishdot seems like it would fall into the category covered by the following howtos: http://www.zope.org/Members/tseaver/inherit_ZCatalog http://www.zope.org/Members/AlexR/CatalogAware But I'm probably overlooking something. Cheers, Michael Bernstein. ___ 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 )
