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
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
16 matches
Mail list logo