Martijn Pieters escribió:
Please don't email me personally; let's keep this discussion on the list.

Garito wrote:
Yes, the indexes depends on the entity (I don't know what indexes I use
until I define the entity but I need to catalog every characteristic of
the entity)

For example if I have a entity with a container where to put my cousins
information I will catalog a keyword index called (is an example,
remeber) HowMuch that counts the number of the objects stored in the

Or if I talk about skills I will catalogue the marks or the way to print
the certificate of excelence (again an example)

But then you can create specific subclasses that are catalog aware. What
standard objects would you use to implement this? You have a specific,
non-generic use-case that has already been catered for by the framework.
I can't subclass every class I need. These will need to reajust (subclass) every new case
For example:
Now I know I need Page Templates and Script Python catalogaware, then I subclass them and I finish the work, good

But tomorrow I need a Mail host catalogaware, begin again and create a subclass for Mail host

I would like if there are a generic way to add catalogawareness by code. If there are my problem about catalogawareness finish
Making all Zope objects catalog aware by default makes no sense
though. You have yet to come with a compelling generic use-case, let
alone with one that convinces me. Why catalog database connectors for
example? What kind of search are you performing?
Please, don't think in a particular case, think a way to do that if you

No, we need a use-case. Otherwise you have what we call a YAGNI, a "You
aint gonna need it" feature that noone will maintain because noone uses it.

A vague notion that you'd like to see this for your application is not a
I use these feature then YAGNI converts to AGUT (at least Garito use these) ;)
Again I know these way is a very particular way, nothing more

When Zopers define what Zope will be they thing in a particular use case? Or Ploners or CMFers? I don't think so

I have a very clear model on my brain that is possible with more or less code What I'm trying is to reduce the length of the code I need to put these model at Zope
Have you thought about the potential problems of making all objects
catalog-aware by default, like potential conflicts and side-effects?
What kind of side-effects or conflicts (put an example to understand,

Catalog indexes retrieve their infomation from the object, through a
named attribute. If that attribute is callable, the index calls it, so
it executes the code. That may have side effects not originally forseen
because the original code never anticipated being indexed. This can
happen when the attribute name can mean different things in different

Zope is a complex beast, and the idea of making everything catalog aware
is not going to play well.
Sure but Zopers don't stops these way only because someone could use it in a wrong way But I can understand the side effects (thanks for the example, it clears my doubt)

Why making everything catalog aware is not going to play well?
I only want catalog aware what is on my products area (sometimes bigger than others)
I say a big -infinity from me on the whole idea.
I can't understand the last sentence (my english is a kid english, sorry

It means I say no to the idea. A big no.
Well, sorry for that!
Martijn Pieters

Mis Cosas

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to