[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 we
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
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
[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
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())
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
[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
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 modification
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:
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
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:
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 data.
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 indexing large
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
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
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
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 of
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). If
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,
and
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
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
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 more
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 for
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 the edit view leads
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
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 difference between
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
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 the
28 matches
Mail list logo
