Re: [Zope] Catalog aware
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 container
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.
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 need
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 use-case.
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, please)
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 contexts. Zope is a complex beast, and the idea of making everything catalog aware is not going to play well.
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 again!)
It means I say no to the idea. A big no. Martijn Pieters
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 container
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 need
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 use-case.
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, please)
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 contexts.
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 again!)
It means I say no to the idea. A big no.
Well, sorry for that!
Martijn Pieters
-- Mis Cosas http://blogs.sistes.net/Garito
Garito wrote:
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 container
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
haha. I wonder which property of that single MailHost object you probably use you want to catalog and what exactly would be your Query to the ZCatalog, once you want to find out...
I would like if there are a generic way to add catalogawareness by code. If there are my problem about catalogawareness finish
Speaking of code: did you think about my hint? I mean the one with the loop - if you have the weird notion you need to make anything catalogaware, why dont you write a product which iterates over all other products in zope, and if not catalogaware, generate a generic catalogaware subclass for you? Heaven, you could even half way finished by the tiem you feed the thread :-) Regards Tino
On 7/20/06, Garito <garito@sistes.net> wrote:
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 use-case.
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
So, one isolated case doesn't make a generic use case. You still haven't given us your particular application, only vague handwaving about how the way you are implementing your ideas needs a catalog. Until there is a clearly described general need for a feature like generic catalog-awareness, there is no case for such a feature to go into the core of Zope. I must say that of what I have been able to understand of what you are doing, it sounds to me as if you are approaching your problem in the wrong way. Page Templates and Python Scripts are there to implement application code and presentation, not store application data. The catalog is a means to find application data based on various aspects of that data. So Zope provides you with framework code that makes it easy for your data objects to re-catalogue themselves on changes, but all the application support objects don't implement this because they don't, normally, contain data. If your implementation relies on Python Scripts or Page Templates to contain application data, you are using the framework in a way it was not designed to do (for a good reason)! If so, rethink your application, instead of trying to make the framework fit. -- Martijn Pieters
Martijn Pieters escribió:
On 7/20/06, Garito <garito@sistes.net> wrote:
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 use-case.
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
So, one isolated case doesn't make a generic use case. You still haven't given us your particular application, only vague handwaving about how the way you are implementing your ideas needs a catalog.
Until there is a clearly described general need for a feature like generic catalog-awareness, there is no case for such a feature to go into the core of Zope.
I must say that of what I have been able to understand of what you are doing, it sounds to me as if you are approaching your problem in the wrong way.
Page Templates and Python Scripts are there to implement application code and presentation, not store application data. The catalog is a means to find application data based on various aspects of that data. So Zope provides you with framework code that makes it easy for your data objects to re-catalogue themselves on changes, but all the application support objects don't implement this because they don't, normally, contain data.
If your implementation relies on Python Scripts or Page Templates to contain application data, you are using the framework in a way it was not designed to do (for a good reason)! If so, rethink your application, instead of trying to make the framework fit.
Ok, a real case: I'm working on a data system (I like the concept data system) for a friend He is Dj for that I want to create a concept like Session Form -> A formulator See -> Used to view the session on its default view Ask -> Used to view the session to change it data (to modify the object) Edit -> Used to change the properties (via Ask view) ... Ask will be something like <tal:b tal:repeat='field Form/get_fields'> <label tal:attributes='for field/getId' /> <tal:b tal:replace='structure field/render' /> </tal:b> As you can see a lot of entities will use the same Ask I will create a container to store all these kind of functionality to use is as a generic Ask In a normal way I can use adquisition to make these way but I want to store things with some kind of order then I define something like MyFriendsWeb (this is an entity) Forms (is not an entity but I use the same product to create it) Session -> Formulator Production -> Formulator Functionality (is not an entity but I use the same product to create it) Ask See Edit Session (this is an entity) Form -> points to MyFriendsWeb/Forms/Session See -> Will use the generic one Ask -> this one too (the generic one) ... Production (this is an entity) Form -> points to MyFriendsWeb/Forms/Production See -> Will use the generic one Ask -> this one too (the generic one) MyFriendsWeb is an entity for that reason catalog everything that not in another entity like Session Session is another entity for that catalog See (the pointer one not the real See), Ask (like See is a pointer) and so on What I want is semantic structure not only usefull structure that makes that every entity will know everything it can do or be With my model I use my product for every container, formulators/page templates/script pythons like functionality an so on My product is about 300 lines of code but I can describe everything I need Is like Plone but with 300 lines of code My model works but I would like if its possible to use something like <tal:b tal:replace='structure Session/Form/header' /> or <tal:b tal:replace='MyFriendsWeb/Sessions' /> instead of <tal:b tal:define='Form <some code to retrieve the form. First if here has Form, then in the acquisition context and finally searching on the catalog of the entity>'> <tal:replace='structure Form/header' /> </tal:b> It works, its only a question of use it as simple as I can For that my product is a ZCatalog with a property Entity (boolean) If you mark Entity as true for an object every objects below these one are catalogued by my product I use an override of __bobo_traverse__ and __call__ What do you think? -- Mis Cosas http://blogs.sistes.net/Garito
On 7/20/06, Garito <garito@sistes.net> wrote:
What do you think?
I realize this is probably because English isn't your first language, but I completely failed to understand there what your application does or tries to accomplish. I just cannot reconstruct what the application should do for your friend. Sorry! -- Martijn Pieters
On 7/20/06, Garito <garito@sistes.net> wrote:
Ok, a real case:
I'm working on a data system (I like the concept data system) for a friend He is Dj for that I want to create a concept like
Session Form -> A formulator See -> Used to view the session on its default view Ask -> Used to view the session to change it data (to modify the object) Edit -> Used to change the properties (via Ask view) ...
Ask will be something like
<tal:b tal:repeat='field Form/get_fields'> <label tal:attributes='for field/getId' /> <tal:b tal:replace='structure field/render' /> </tal:b>
As you can see a lot of entities will use the same Ask
Sure.
I will create a container to store all these kind of functionality to use is as a generic Ask In a normal way I can use adquisition to make these way but I want to store things with some kind of order then I define something like
MyFriendsWeb (this is an entity) Forms (is not an entity but I use the same product to create it) Session -> Formulator Production -> Formulator Functionality (is not an entity but I use the same product to create it) Ask See Edit Session (this is an entity) Form -> points to MyFriendsWeb/Forms/Session See -> Will use the generic one Ask -> this one too (the generic one) ... Production (this is an entity) Form -> points to MyFriendsWeb/Forms/Production See -> Will use the generic one Ask -> this one too (the generic one)
MyFriendsWeb is an entity for that reason catalog everything that not in another entity like Session
Session is another entity for that catalog See (the pointer one not the real See), Ask (like See is a pointer) and so on
What I want is semantic structure not only usefull structure that makes that every entity will know everything it can do or be
I think I see.
With my model I use my product for every container, formulators/page templates/script pythons like functionality an so on
Sure, just like portal_skins does.
My model works but I would like if its possible to use something like
<tal:b tal:replace='structure Session/Form/header' />
or
<tal:b tal:replace='MyFriendsWeb/Sessions' />
instead of
<tal:b tal:define='Form <some code to retrieve the form. First if here has Form, then in the acquisition context and finally searching on the catalog of the entity>'> <tal:replace='structure Form/header' /> </tal:b>
It works, its only a question of use it as simple as I can
Well, this seems complex. Can't you just have context/Session/Form/header instead of just Session/Form/header?
For that my product is a ZCatalog with a property Entity (boolean) If you mark Entity as true for an object every objects below these one are catalogued by my product
Uhhh. That doesn't help.
What do you think?
Sound fine. I notice that in all of your description above there is a complete lack of indexed page templates. ;) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
participants (4)
-
Garito -
Lennart Regebro -
Martijn Pieters -
Tino Wildenhain