Re: [Zope-dev] CatalogAware Products and PropertyManager

2001-12-13 Thread Matt Hamilton

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 Products and PropertyManager

2001-12-13 Thread Dirk Datzert

thanks

I found it under
http://www.zope.org/Members/Kaivo/DTMLDocumentExt/DTMLDocumentExt-0.2.tgz/vi
ew


- Original Message -
From: Matt Hamilton [EMAIL PROTECTED]
To: Dirk Datzert [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, 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 ?
 
  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

2001-01-08 Thread Chris Withers

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

2001-01-08 Thread 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.

___
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

2001-01-05 Thread Chris Withers

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

2001-01-05 Thread Chris Withers

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

2001-01-05 Thread Chris Withers

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

2001-01-05 Thread Christopher Petrilli

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

2001-01-05 Thread 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.

___
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

2001-01-04 Thread Erik Enge

[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

2001-01-04 Thread Chris Withers

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

2001-01-04 Thread Michael Bernstein

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

2001-01-04 Thread Erik Enge

[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

2001-01-04 Thread 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.

___
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

2001-01-03 Thread Michael Bernstein

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

2001-01-03 Thread Michael Bernstein

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

2001-01-02 Thread Michael Bernstein

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 )