[***SPAM*** Score/Req: 04.00/04.00] Re: [Zope] Catalog aware

[Garito]

Martijn Pieters escribió:
> On 7/20/06, Garito <garito at 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