December 13, 2001 11:58 AM
Subject: 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 ?
> >
> &g
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 wou
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.
If t
Hi,
I want to make ZNavigator CatalogAware and thought
that I only had to put CatalogAware as the first class-parent like
this:
def ZNavigator ( CatalogAware , ... ):
...
def NavItem ( CatalogAware , ...):
...
Am I right or wrong ?
I want to catalog every property into
ZNavigator
On Tue, 26 Jun 2001 09:31:02 -0400, Chris McDonough
<[EMAIL PROTECTED]> wrote:
>Right.. if you don't use CatalogAware, however, and don't unindex before
>reindexing an object, you should see a huge bloat savings, because the
>only things which are supposed to be updated then are indexes and
>meta
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
>
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
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 ('Post
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 necess
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
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 st
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
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*.
This is true, and one of the reasons why I (and maybe only I ;-)
consider CatalogAware somewhat less use
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
[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
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 o
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 c
[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
Michael Bernstein wrote:
>
> 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.
Hehe... many would agree with that sentiment.
The point behind CatalogA
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 method
TED]>
Sent: Wednesday, January 03, 2001 11:07 AM
Subject: Re: [Zope-dev] CatalogAware
> 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
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
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/Me
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/CatalogAwa
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
>
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
Is it possible (worth?) to make dtml-document catalogue aware by default? Or
to allow the creater to decide this behavior by setting a property?
Rgs,
Kent Sin
-
kentsin.weblogs.com
kentsin.imeme.net
___
Zope-Dev maill
27 matches
Mail list logo
