On 7/20/06, Garito <[EMAIL PROTECTED]> 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
I use these feature then YAGNI converts to AGUT (at least Garito use
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
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.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -