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
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
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
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
metadata
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,
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:
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
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
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
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
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
[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
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
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
[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
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
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
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
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
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
20 matches
Mail list logo
