Uwe Oestermeier wrote:
[EMAIL PROTECTED] wrote:
What is the missing event bug?
Currently no modification event is fired if one uploads new file content
via ZMI.
In a former mail I proposed to fire the event in File.setData,
alternatively it can be fired by the upload view.
Would this be f
[EMAIL PROTECTED] wrote:
>What is the missing event bug?
Currently no modification event is fired if one uploads new file content
via ZMI.
In a former mail I proposed to fire the event in File.setData,
alternatively it can be fired by the upload view.
>
>
>Would this be for 3.2? Keep in mind that
Uwe Oestermeier wrote:
I would like to fix the missing event bug,
What is the missing event bug?
implement Jim's proposal and
mark ObjectContentModifiedEvent and ObjectAnnotationModifiedEvent as
deprecated.
Any objections?
Would this be for 3.2? Keep in mind that we want to generate a bet
I would like to fix the missing event bug, implement Jim's proposal and
mark ObjectContentModifiedEvent and ObjectAnnotationModifiedEvent as
deprecated.
Any objections?
Uwe
[EMAIL PROTECTED] wrote:
>
>I suggest we generalize this a bit. I suggest that the ObjectModified
>event could accept one
On 5/26/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> Given the applications above, I don't think that there's value in
> fine-grained modification events that justifies the complecity of
> proposals we've thought of so far.
>
>
> Thoughts?
I doubt the event system needs to be much more fine-grain
[EMAIL PROTECTED] wrote:
>> Because there is no guarantee that all relevant modifications are
>> accompanied by events?
>
>Right
But this problem is not unique to versioning. If you cannot rely on events
there is also no guarantee that your catalogs are always up to date.
Therefore I'm planning a
Garrett Smith wrote:
Jim Fulton wrote:
Garrett Smith wrote:
:-) I guess this approach is *so* endemic to Zope 3, I must be
missing something huge.
What we're talking about is not very different from the way that
composition is used to prevent explosition of field types.
For example, we use
Garrett Smith wrote:
> Jim Fulton wrote:
>> Garrett Smith wrote:
>>> :-) I guess this approach is *so* endemic to Zope 3, I must be
>>> missing something huge.
>>
>> What we're talking about is not very different from the way that
>> composition is used to prevent explosition of field types.
>>
>
Jim Fulton wrote:
> Garrett Smith wrote:
>> :-) I guess this approach is *so* endemic to Zope 3, I must be
>> missing something huge.
>
> What we're talking about is not very different from the way that
> composition is used to prevent explosition of field types.
>
> For example, we use: List(Int
Uwe Oestermeier wrote:
[EMAIL PROTECTED] wrote:
I'm 99% sure that this event model will not be sufficient for object
versioning.
Why?
Because there is no guarantee that all relevant modifications are
accompanied by events?
Right
I think these problems can be solved, but perhaps you have
[EMAIL PROTECTED] wrote:
>I'm 99% sure that this event model will not be sufficient for object
>versioning.
Why?
Because there is no guarantee that all relevant modifications are
accompanied by events?
Because the events do not carry enough information?
I think these problems can be solved, but p
Garrett Smith wrote:
...
I'm seeing a lot of hypothesizing and we should instead be driven by
hard requirements/use cases.
I think Dieter's use case was a pretty good one. It convinced me.
I think getting modification time "right" is another one.
IIR, the one definite requirement is to provi
Garrett Smith wrote:
Jim Fulton wrote:
Uwe Oestermeier wrote:
...
Alternatively, all mentioned usages could be easily subsumed under
an extended ObjectModifiedEvent definition. Some optional keywords
(for the interface and the attribute that was used to change the
object, and additional infos
Florent Guillaume wrote:
Jim Fulton <[EMAIL PROTECTED]> wrote:
...
That looks good to me. Especially because, using interfaces, we could
theoretically express more than just a set of attributes that have
changed on an object. I'm thinking of:
- having the interface itself add semantics to
Florent Guillaume wrote:
> On 31 May 2005, at 12:39, Garrett Smith wrote:
>>> That looks good to me. Especially because, using interfaces, we
>>> could theoretically express more than just a set of attributes that
>>> have changed on an object. I'm thinking of:
>>>
>>> - having the interface itsel
On 31 May 2005, at 12:39, Garrett Smith wrote:
That looks good to me. Especially because, using interfaces, we could
theoretically express more than just a set of attributes that have
changed on an object. I'm thinking of:
- having the interface itself add semantics to what a subscriber
could
Florent Guillaume wrote:
> Jim Fulton <[EMAIL PROTECTED]> wrote:
>> Based on the discussion so far, I'm convinced that something like
>> this would be useful, at least as an optional feature, as you
>> suggest.
>>
>> I suggest we generalize this a bit. I suggest that the
>> ObjectModified event
Jim Fulton <[EMAIL PROTECTED]> wrote:
> Based on the discussion so far, I'm convinced that something like this
> would be useful, at least as an optional feature, as you suggest.
>
> I suggest we generalize this a bit. I suggest that the ObjectModified
> event could accept one or more modificati
Jim Fulton wrote at 2005-5-30 08:42 -0400:
> ...
>I suggest we generalize this a bit. I suggest that the ObjectModified
>event could accept one or more modification descriptions (hints?).
>Some examples:
>
> ObjectModifiedEvent(obj, IObjectFile)
>
>This says that we modified the objects file dat
"Garrett Smith" wrote:
>
>A couple questions:
>
>- How is a 'better' (loaded term, feel free to interpret) arrangement
>than using application-specific event types that clearly define a) when
>the event is generated and b) what information the event conveys?
Application specific events can still b
Ooops! I just saw that my previous posting on the other thread has become
obsolete to a large degree.
[EMAIL PROTECTED] wrote:
>
>I suggest we generalize this a bit. I suggest that the ObjectModified
>event could accept one or more modification descriptions (hints?).
>Some examples:
>
> ObjectM
Jim Fulton wrote:
> Uwe Oestermeier wrote:
> ...
>> Alternatively, all mentioned usages could be easily subsumed under
>> an extended ObjectModifiedEvent definition. Some optional keywords
>> (for the interface and the attribute that was used to change the
>> object, and additional infos about the
Uwe Oestermeier wrote:
...
Alternatively, all mentioned usages could be easily subsumed under an
extended
ObjectModifiedEvent definition. Some optional keywords (for the
interface and
the attribute that was used to change the object, and additional infos
about
the changed values if available)
Jim Fulton wrote at 2005-5-27 10:45 -0400:
> ...
>> You cannot make text extraction cheap (as it handles potentially large
>> data).
>
>You can't make it cheap in all applications. For most applications,
>text extraction and comparison is very cheap.
>
>I'm guessing that you are refering to indexi
Dieter Maurer wrote:
Jim Fulton wrote at 2005-5-27 08:29 -0400:
...
Then, we probably do something wrong...
That's always a possibility. I think what we are doing is
pretty reasonable. Perhaps you have other suggestions.
I think we need more control over what modifications trigger
what
Jim Fulton wrote at 2005-5-27 08:29 -0400:
> ...
>> Then, we probably do something wrong...
>
>That's always a possibility. I think what we are doing is
>pretty reasonable. Perhaps you have other suggestions.
I think we need more control over what modifications trigger
what reindexing events.
I
Dieter Maurer wrote:
Jim Fulton wrote at 2005-5-26 14:43 -0400:
...
Probably the indexes that we *most* want to avoid reindexing are
text indexes. We have a ISearchableText interface that we
commonly adapt objects to to get the text to index. We really
can't predict how this text is compu
Jim Fulton wrote at 2005-5-26 14:43 -0400:
> ...
> Probably the indexes that we *most* want to avoid reindexing are
> text indexes. We have a ISearchableText interface that we
> commonly adapt objects to to get the text to index. We really
> can't predict how this text is computed.
Then,
A week or so ago, there was a thread on the distinction between
IObjectModifiedEvent, IObjectAnnotationsModifiedEvent, and
IObjectContentModifiedEvent.
I'd like to step back a little bit and brainstorm some use cases
that, hopefully, illustrate why we care about this. Here's
a start:
- A persi
Uwe Oestermeier wrote:
Garrett Smith wrote:
> So we shouldn't see ObjectModifiedEvent being fired directly then. It
> should be one of the two subclasses, correct? This is not the case
> throughout zope/app.
Jim Fulton answered:
> Yup. Yup.
A closer look at the ObjectModifiedEvents (or the
This proposal is way too unpythonic IMO.
Application code shouldn't have to go through this much
machinery just to make changes.
I don't mind if some application does something like this,
but I wouldn't want to make this a standard mode of operation
for Zope 3.
If a goal is to avoid reindexing
Dieter Maurer wrote:
>Sounds good, but I am nevertheless convinced that we
>want finer grain control -- almost as fine (but probably with other
>means) as the "idxs" argument to "catalog_object" (which controls
>precisely which indexes should be reindexed). We will probably
>replace the selection o
Uwe Oestermeier wrote at 2005-5-11 11:18 +0200:
> ... indexing performance ...
>I agree, but perhaps we can find a compromise that fits
>all needs. I propose to use pluggable modification utilities.
>
>The container related events are already fired by only two
>functions (setitem and uncontained)
Dieter Maurer wrote:
As soon as you index the content, you will be interested
to distinguish between a modification in the primary
content and some meta data (as it has big repercussions
on the speed of the reindexing).
I agree, but perhaps we can find a compromise that fits
all needs. I propo
Garrett Smith wrote at 2005-5-9 12:35 -0500:
> ...
>I'd be concerned about making ObjectModifiedEvent too burdensome for
>developers. For most, cases, it's sufficient to just say "this object
>has changed" and be done with it.
But many developers are interested in efficiency.
As soon as you index
Uwe Oestermeier wrote:
...very good analysis of current modified event usage...
> Alternatively, all mentioned usages could be easily subsumed under an
> extended ObjectModifiedEvent definition. Some optional keywords (for
> the interface and the attribute that was used to change the object,
> an
Garrett Smith wrote:
> So we shouldn't see ObjectModifiedEvent being fired directly then. It
> should be one of the two subclasses, correct? This is not the case
> throughout zope/app.
Jim Fulton answered:
> Yup. Yup.
A closer look at the ObjectModifiedEvents (or the related modified() calls)
Garrett Smith wrote:
Jim Fulton wrote:
Garrett Smith wrote:
Uwe Oestermeier wrote:
In the meanwhile we need a decision, whether the
ObjectContentModifiedEvent should be used in the File._setData
method. I would like to check this solution in. Any objections? The
ObjectContentModifiedEvent class c
Jim Fulton wrote:
> Garrett Smith wrote:
>> Uwe Oestermeier wrote:
>>
>>> In the meanwhile we need a decision, whether the
>>> ObjectContentModifiedEvent should be used in the File._setData
>>> method. I would like to check this solution in. Any objections? The
>>> ObjectContentModifiedEvent clas
Garrett Smith wrote:
Uwe Oestermeier wrote:
In the meanwhile we need a decision, whether the
ObjectContentModifiedEvent should be used in the File._setData
method. I would like to check this solution in. Any objections? The
ObjectContentModifiedEvent class can be removed later on, if noone
else is
Uwe Oestermeier wrote:
> In the meanwhile we need a decision, whether the
> ObjectContentModifiedEvent should be used in the File._setData
> method. I would like to check this solution in. Any objections? The
> ObjectContentModifiedEvent class can be removed later on, if noone
> else is using it.
Garrett Smith wrote:
I think ValueChangedEvent would be a good addition to the forms
machinery. But if you need something like that now, I'd recommend using
your own edit view class.
That would be a solution for the moment, but in the future I would like to say that my
application provides als
Uwe Oestermeier wrote:
> "Garrett Smith" wrote:
>
> I'd see this being something like a ValueChangedEvent that specified
> the object, schema, field name, old value, and new value. This would
> be a nice way to bolt on validation without modifying the schema.
>
> Yes, that's exactly what I need f
"Garrett Smith" wrote:
I'd see this being something like a ValueChangedEvent that specified the
object, schema, field name, old value, and new value. This would be a
nice way to bolt on validation without modifying the schema.
Yes, that's exactly what I need for versioning.
Anyone needing mor
Uwe Oestermeier wrote:
> But I could also live with ObjectModifiedEvents only.
IMO, the second event type, if it doesn't have a clear distinction,
should be removed.
> A more radical approach would be to specify in each
> ObjectModifiedEvent which aspects of an object changed. By aspect I
> mean
Garrett Smith wrote:
What is the difference between 'content' that gets modified and the
object that gets modified.
In my understanding the difference stems from the filesystem
metaphor behind Zope. The "content" of a Zope object corresponds
to the content of a file, while other attributes a
>From the interface docs, it's not clear to me what the difference
between the events are:
class IObjectModifiedEvent(IObjectEvent):
"""An object has been modified""
class IObjectContentModifiedEvent(IObjectModifiedEvent):
"""An object's content has been modified"""
What is the differenc
Uwe Oestermeier wrote:
Hi,
I'm working on a versioning system that creates a new version for each
changed file content.
I tried to listen to
zope.app.event.interfaces.IObjectContentModifiedEvents,
but unfortunately no such event seems to be generated.
Editing an existing zope.app.file.File via
48 matches
Mail list logo
