Re: [Zope3-dev] Re: The elevator speech for Zope 3
Oliver Marx [EMAIL PROTECTED] writes: I have looked at Grok. I love the ideas. But it feels like its a little too much convention over configuration. I do not hate zcml. I hate to write zcml. If there was a way to auto generate zcml and way to overwrite that zcml when needed - then I would be a happy man. Have a look at bebop.protocol in PyPI. It's still a preminary version but it does exactly what you want. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] State of zope.fssync
Hi All, I'm still working on zope.fssync and zope.app.fssync. When I started, I had the hope to finish this work before the 3.4 release, but as always it took longer than expected. Now I'm unsure how to proceed. I have refactored zope.fssync and zope.app.fssync into two clearly separated packages: - zope.fssync contains now a Python API that has no critical dependencies on Zope, the ZODB, and the security machinery. - zope.app.fssync contains a protected web-based API and special synchronizers for zope.app content types. Other major changes are - synchronizers (i.e. serialization/de-serialization adapters) are created by named utilities which use dotted class names as lookup keys - added doctests for zope.fssync and functional doctests for zope.app.fssync - support for large files - adapters for pickler, unpickler and handling of persistent pickle ids - binaries are no longer merged - case-insensitive filesystems and repositories use disambiguated names on export and the original names on import - export and import of directly provided interfaces - direct export to archives/direct import from archives - addressed encoding problems on Mac OSX I can commit these changes to the trunk before the feature freeze, but I have mixed feelings about doing so, since there are still problems to be solved, e.g. - export/import of int id utilities and catalogs: both should be rebuild and not serialized/de-serialized and in the moment it is unclear to me whether we need a fssync-specific form of post processing for this - missing doctests for the use case of content management Therefore I propose to postpone the release of zope.fssync until the next release cycle. Any comments? Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: IKeyReference for files
Martijn Faassen [EMAIL PROTECTED] schreibt: Yeah, and I do need to be cross-platform with this, so inodes are not ideal. Hi, it depends on how cross-platform you need to be and whether you have another solution that is ideal;) For Win32 you can use the low value of the FileIndex number of the filesystems master file table. This is the last value of the (10-)tuple returned by the Win32 API method win32file.GetFileInformationByHandle() Note that the new Blob-support also uses win32file Concerning the problem of the different filesystems and devices I can only guess whether your use cases really need to take different devices into account. In our use case we simply assumed that the files are on a single device and remain were they are. If you follow Christian's suggestion of using hard links with the oid of a shadow object in the ZODB a similar restriction applies. In any case I'm also interested in IKeyReferences for files, so I hope that there is a better solution that is cross platform, allows an efficient lookup, works across devices, and offers also an easy way to detect catalog relevant changes. I fear there is no ideal solution to all these problems and we need to consider trade-offs. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal for optimized Blob handling
Christian Theune [EMAIL PROTECTED] schreibt:
Nope. It won't disappear if you link it again. And the link(src, dst)
does move it to a 'save' location ;)
Again I'm not convinced because you cannot be sure that no other process
deletes the temp file.
In the following I simulate this with a os.system call:
import tempfile, os
d = tempfile.NamedTemporaryFile()
os.path.exists(d.name)
True
d.write('Test')
os.path.exists('/tmp/asdf')
False
os.link(d.name, '/tmp/asdf')
d.close()
os.system('rm /tmp/asdf')
0
os.path.exists('/tmp/asdf')
False
open('/tmp/asdf').read()
Traceback (most recent call last):
File stdin, line 1, in ?
IOError: [Errno 2] No such file or directory: '/tmp/asdf'
:)
Why not rename the temp file to a place in the blob directory?
That would also avoid the copy operation.
Uwe
Dr. Uwe Oestermeier
Institut für Wissensmedien
Knowledge Media Research Center
Konrad-Adenauer-Str. 40
D-72072 Tuebingen
Germany
[EMAIL PROTECTED]
Tel. +49 7071 979-208
Fax +49 7071 979-100
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal for optimized Blob handling
Christian Theune [EMAIL PROTECTED] schreibt:
Nope this is not the correct simulation. Who except your application
knows about /tmp/asdf? You have to simulate deleting d.name and then
you'll see that /tmp/asdf does not disappear.
Ok, but what Dieter means is that the tmp dir as a whole is emptied from
time to time.
I see your point that closing a temp file removes it whereas the link
still works,
but that does not solve the problem that system administrators may sweep
things out.
The following solution avoids this problem:
os.mkdir('/Users/uo/blobs')
d = tempfile.NamedTemporaryFile()
d.write('Test')
d.flush()
os.rename(d.name, '/Users/uo/blobs/asdf')
open('/Users/uo/blobs/asdf').read()
'Test'
os.path.exists('/tmp/asdf')
False
Uwe
Dr. Uwe Oestermeier
Institut für Wissensmedien
Knowledge Media Research Center
Konrad-Adenauer-Str. 40
D-72072 Tuebingen
Germany
[EMAIL PROTECTED]
Tel. +49 7071 979-208
Fax +49 7071 979-100
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.fssync dependency on zope.app.file
Hi, I'm currently working on zope.fssync and zope.app.fssync. There are still some things to do (e.g. changing the API of the default file serialization adapter to read and write methods, adding security statements for serializers and deserializers). I'm planning to finish these things until 3.4. My preference would be to leave everthing as it is and include zope.fssync as a dependency and zope.app.fssync as a part of the egg. Alternatively I can try to move the code of zope.app.fssync (and zope.app.file.fssync etc.) to zope.fssync. I can live with both alternatives, of course, but in my opinion it makes sense to leave the Python API (independent of ZODB and locations etc.) in zope.fssync and the web-based API (with security and location aware pickler) in zope.app.fssync. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.fssync dependency on zope.app.file
Jim Fulton [EMAIL PROTECTED] wrote: We need to either remove zope.app.fssync.file, or, if we think that fssync is moving along well enough, we need to move zope.app.ffile.fssync to a separate project in some namespace package, such as zope.app.filefssync. fssync is too experimental to include zope.app.file.fssync in zope.app.file. I agree that fssync is still experimental. The DefaultFileAdapter setBody and getBody methods, for instance, do not apply well to Blobs and other file implementations. Another problem, at least for me, is that the current implementation addresses more the use case of export/import than the use case of content management. Currently FSSync replicates the ZODB object tree in the filesystem, serializes everything into a temp file, and starts to respond after these very expensive operations. How are the chances that the response.write method is reinstated in the future? Or are there already alternatives I have missed? Given that zope.app.fssync needs more work, wouldn't it be better to move everything into one place then, e.g to zope.app.fssync.file, zope.app.fssync.zptpage etc? If the API becomes stable we still can create the separate projects. Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.fssync dependency on zope.app.file
Jim Fulton [EMAIL PROTECTED] wrote: Since you're the one working on this, I'll defer to you on this detail. :) Ok, then I will move the things to zope.app.fssync. Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] future of fssync (was: RE: [SpringCleaning07])
Sorry for replying so late. I have just checked in some bug fixes for fssync (r72206). This was indeed not much work. Jim Fulton [EMAIL PROTECTED] wrote: I don't think a whole lot is needed to make fssync a reality: 1. Cure any bitrot that has set in. It would also ne nice to replace existing tests with modern doctests. 2. Provide a Python API. fssync originally had a Python API, but this was replaced with a web-based API. I think there should be both a Python API that wasn't encumbered in any way by security, and a protected web-based API. The Python API should really be Zope and even ZODB independent. I don't think this would be a lot of work. The original one wasn't and would be useful in many cases. 3. I think there should be a secure web-based interface. This will require: - Adding security checks that the user is allowed to access serialization and de-serialization adapters, - Adding security declarations for these adapters, I don't think any of these would require a great deal of work. I can try to deal with these tasks, but I fear that there is a little bit more to do. While playing with real data, I noticed - problems to serialize large sites (I run into a stack overflow and have still to figure out why this happened), - problems with unicode filenames. As a first step I would like to clean up the existing code. Concerning this I have questions/suggestions: - Can the fssync:adapter zcml directive be replaced by ordinary trusted adapters? - Can zope.app.fssync.fspickle be replaced by zope.xmlpickle? (It seems that fspickle preserves location ids but it does not seem to preserve the order of dict items) - What's the purpose of zope.app.fssync.fsbundle? Are there still usecases for this code or can it be removed? - What's the purpose of zope.app.fssync.fsregistry? Can this be replaced by utility registrations? All in all the fssync code seem to be in an old-fashioned but usable shape and it's a pity that it has not been maintained. Perhaps the maintenance can be made easier if we can change the code without deprecation warnings. Nobody seems to have used fssync in the last two years. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] future of fssync (was: RE: [SpringCleaning07])
Jim Fulton [EMAIL PROTECTED] on Mittwoch, 24. Januar 2007 at 16:48 Uhr +0100 wrote: Maybe, but I like your idea of using utilities below. My original thinking was along these lines: fssync should strive to serialize all object data. (Note that it isn't always obvious what data is intrinsic to an object.) I felt therefore, that inheriting synchronization adapters would be bad. If someone created a subclass and forgot to create an adapter, then their data would be serialized incompletely. I like the idea of using named utilities, using dotted class names as utility ids. See below. Ok, I will give named utilities a try. - Can zope.app.fssync.fspickle be replaced by zope.xmlpickle? (It seems that fspickle preserves location ids but it does not seem to preserve the order of dict items) I'm a bit rusty on this. I would think that these can be combined. It should, I think, be possible to generate location-aware pickles and then use zmlpickle to represent these as XML. The trick, I think, would be use the pickle persistent-reference mechanism to refer to other objects by location, when necessary. I say this without looking at the code. :) If you need me to dig deeper, I'll try to find time to do so. I found such a combination in zope.fssync.server.entryadapter. There a location-aware pickle was created by fspickle.dumps and converted via xmlpickle.toxml. This version generated xmlpickles with changing dict representations which in turn led to false alarms that objects had been modified. I will try to combine the xmlpickle._PicklerThatSortsDictItems with the fspickle.ParentPersistentIdGenerator and see whether this solves the problem. If this doesn't work, I will ask you for further assistance. Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Grrr. zope.org wikis are evil.
Fred Drake [EMAIL PROTECTED] on Montag, 9. Oktober 2006 at 5:20 Uhr +0100 wrote: Didn't someone write one like this for Z3? Possibly as part of a zope3.org thing? I now vaguely recall something being done, but that's about all I remember. Hi, yes, we started such a thing at the NeckarSprint last year. Unfortunately it never got ready to use . It uses Kupu and TinyMCE as WYSIWYG editors besides ReST: http://svn.zope.org/zope3org/trunk/src/zorg/wikification/ I fear that I will not be able to continue this work in the next few months, since I have to concentrate on my Bebop project. In this project we try to implement a lot of additional features like previews, versioning, diff views, integration with blog and news views, filesystem synchronization etc.I would love to see Bebop as a basis for a zope3.org site, but that's not realistic at the moment. For the zope3.org site it would probably the best to use an existing tool like Trac which is dedicated to the need of programmers. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Displaying ReStructered Text
Hi, have a look at the rest2html function in http://svn.zope.org/*checkout*/zope3org/trunk/src/zorg/restsupport/__init__.py?content-type=text which uses the zope.app.renderer.rest module. Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 lacks Ajax capability?
Hi Roger, hi Jeff, Roger wrote: See this for more information, but don't ask me if it's working. http://svn.zope.org/zope3org/trunk/src/zorg/live/README.txt?rev=66712view=markup It works at least for our purposes. We are using an experimental LivePage application here at our institute. Experimental means that 4 subjects of a psychological study share a message board via browser live pages. Jeff Rush wrote: (1) a piece of Javascript downloaded with a page request turns around and issues an HTTP GET back to Zope3 such that that connection is kept open indefinitely, and the thread within Zope3 that is servicing that request hangs around and periodically shoves bits of data (XML, JSON, whatever) down that pipe that get acted upon by Javascript within the client's page. This provides server = client communications via a brief REQUEST and a neverending RESPONSE chunked up into pieces representing operations run on the client. (2) another piece of Javascript downloaded with a page request similarly turns around and issues an HTTP GET/PUT back to Zope3 with a header to keep the connection open. Over this pipe the client can issue conventional multiple REQUEST/RESPONSE cycles to invoke functions within the server, providing client = server communications. However the trick re Zope3 is that the URL/view to which that request connects must be one that can rendevous with the thread or a piece of state associated with (1) above, so that the server and client have a meaningful basis on which to talk. I struggled with both problems in the zorg.live package. (1) In this package I implemented a specialization of the twisted server which handles LivePage requests outside Zope's threads. Otherwise the number of connected clients would have been limited to the number of Zope threads which come with their own object caches and database connections, in my view an unnecessary overhead for most LivePage requests. (2) Each client is registered on the server side in a thread safe global utility. This utility handles the clients ids which are send as parameters of each LivePage request. Feel free to contact me if this looks interesting to you. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 lacks Ajax capability?
Jeff Rush wrote: Provide a chat window at the bottom of a page, in which a student interacts with a teaching app and members of his team. In the upper portion of the page, the teaching app alternately presents proficency questionaires and lessons. This seems to be very similar to our live comments demo app: http://svn.zope.org/*checkout*/zope3org/trunk/src/zorg/live/demo/comment/README.txt Unfortunately the documentation is far from complete, but I can work on it if there is a concrete need. -Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Event fixes
Florent Guillaume wrote: I didn't follow Dominik's suggestion of using IModificationDescription because I feel this a case sufficiently fundamental that we really want a subclass. I agree with Dominik that this justification is somewhat vague, but I think that it really doesn't matter whether we use a subclass or a modification description here. Both solutions will work for me. Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 website report?
Hi Valeri, I can help to review existing Zope3Dev wiki. May be create list: wiki -- status. Statuses may be: -- outdated -- under development (still requires further agreement) -- recomended (tried and tested) RIght? Such a list would be very useful. But I think the states recommended and outdated are sufficient (at least for the moment). If in doubt I would take over the contribution and let the recipients decide whether they make any use of the contribution or not. If you send this list to me I will integrate it into the importer. Thanks for the help, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Containerview Proposal
Hi, Stefan Martin and I have written a proposal for a reimplementation of the container views. http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ConfigurableContainerViews We would like to work on this at the NeckarSprint next week, so any feedback is welcome. Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Containerview Proposal
Benji York wrote: I'll be releasing some code today that does most of what this proposal wants for any collection of objects, not specifically container views (because you'll often want to represent tabular data that doesn't exist in any particular container). It would fairly easy to build a container view using it. Great! We can use it at the sprint then. Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Rename principal to participant
Philipp von Weitershausen wrote: I smell a proposal :). I cannot promise to write this proposal in the next two weeks, but I will try to write one before the NeckarSprint (6-9. Oct) takes place. The implementation of user objects would be a manageable sprint task. -- Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 and ZEO
Tim Peters wrote: Zope3 3.1's bin/mkzeoinstance seems to work now, I dedected another problem: bin/runzeo doesn't start ZEO. This script calls ZEO/runzeo.py which has a main function but no if __name__ == __main__ : main() at the end. Has this already been fixed in the mentioned internal branch? Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope3 and ZEO
Hello, today I downloaded the Zope-3.1.0c2 release candidate and played a little bit with it. I noticed that the bin/mkzeoinstance script is broken and returns Traceback (most recent call last): File ./mkzeoinstance, line 40, in ? from ZEO.mkzeoinst import ZEOInstanceBuilder I found no hint how Zope3.1 can be run with ZEO instead. Besides that the README.txt contains still references to Zope-3.0.0 and a XXX to be written under Starting Zope Shouldn't that be fixed before the final release is out? Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Upcoming Zope3 Sprint 6-9. Oct
Hi all, the Bebop Team would like to invite Zope3 developers for the next upcoming sprint at the Knowledge Media Research Center, Tuebingen, Germany. The meeting will start on Thursday, October 6 and end on Sunday, October 9. The focus of the sprint will be on the Zope3.2 release. This might include topics like - Twisted integration - WebDAV support - Catalogs - Customizable container views - Zope3 and Ajax - Event debugging and many other... Stephan Richter and Dominik Huber are the coaches of this sprint and will introduce the participants into the current state of the Zope3 framework. The sprint is intended for Zope developers. That means that the sprint will start without a tutorial, but interested newcomers who studied the books of Stephan Richter and Philipp von Weitershausen are also welcome. If you are interested consult the WikiPage at http://www.zope.org/Members/oestermeier/NeckarSprint As a zope.org member you can edit the page with http://www.zope.org/Members/oestermeier/NeckarSprint/editform Please contact me, if you have questions or suggestions. Hope to see you... Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
[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 want to generate a beta release this weekend. I can do it tomorrow since there are only a few places where modification events are actually used. If that seems to risky I will wait for 3.2. Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
[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 perhaps you have other reasons in mind. Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
[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 debug tool that uses a beforeCommitHook to check whether all modifications I'm interested in are accompanied by events. This indeed is another way to say that I'm doing versioning better at the transactional level. My point is, that this debug mode is relatively expensive and I hope that I can switch it off as soon as all components fire the events as required. Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
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: ObjectModifiedEvent(obj, IObjectFile) This says that we modified the objects file data. Note that an interface is an acceptable description. In fact, we might allow pretty muich anything as a description. ObjectModifiedEvent(obj, IObjectFile, Attributes(IZopeDublinCore, 'title', 'description'), ) This says we modified the file data and the DC title and description. 1+ Uwe, I still think you need something else for your versioning work. I'm not sure. Previously, I thought that it would be useful to have the old and new values of an attribute change in addition. Such infos allow to create the first version of an attribute value after the first change, which means that one creates versions only for the (usually few) parts of an object that really change. Since each versioned value has some overhead (e.g. modification time, user etc.) this makes a difference The proposed approach makes the descriptions optional, and I agree that a framework should not be overloaded by application specific optimizations. Therefore, I probably will continue using complete replicas of the original objects since I cannot rely on the fact that all programmers specify all changes in such detail. Otherwise it would be possible to extend the modification descriptions a little bit and provide ValueChanged(IZopeDublinCore, 'title', u'Old title', u'New title') descriptions at least for the few cases in the framework where modification events are produced. Whether other programmers find these descriptions also usefull can then be left to the future. What remains is the problem that change detection should be fool proof. It would be nice to have a debugging tool that prints a warning if a modified object is written back to the database without a corresponding event. Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
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 affected indexes with some interface related concept. That's exactly what my proposal wants to achieve. If you need finer control the pluggable modifier is the right place to introduce whatever you want. Besides special events you can add hooks, introduce type specific adapters etc. All we need at the moment (at least for cataloging and versioning) is the certainty that all relevant modifications are going through the same replaceable component. Everything else can be implemented later on. As far as I understand Zope3's catalog implementation most indexes use a interface + attribute specification, which a ValueChangedEvent could provide. The BetterModifier in my proposal sends these infos in addition to an unspecific modified event and thus should be sufficient for most purposes. One problem I see is that different schema adapters can use the same slots for different fields. To solve this problem one could probably use object annotations to store footprints of the involved indexes and their relationships. But again the modification component would be the right place to evaluate these annotations. -- Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
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 also versioning for content types of other third party applications. This leads to a second major problem: How can I be sure that other applications do send events for all modifications they perform. It is very easy to forget that. My versioning scheme would be less error prone if I could check for modified objects via ITransaction.beforeCommitHook or ISynchronizer.beforeCompletion. Can this already be done in the current state of development? I found no hints in the Zope3 sources that these interfaces of the transaction module are already used. 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. Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
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 information in ObjectModified can just create a new event type with the additional info. This seems application specific to me. But there is a major problem: How can you reuse an existing infrastructure then? You have to write all editing views or other components that modify the content objects anew. In my view ValueChangedEvents are usefull in many applications and for many purposes (reindexing catalogs, updating views in standalone applications, triggering external processes etc.). Would it be too much overhead to have them in the framework from the beginning? Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Missing ObjectContentModifiedEvent
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 only to an ObjectModifiedEvent, uploading new content produces no object event at all. Should this be fixed by generating ObjectContentModifiedEvents in both cases (which I would prefer), or should the less informative ObjectModifiedEvent be used? In the later case, the misleading IObjectContentModifiedEvent should probably removed from the list of objectevents. In general, missing events are difficult to detect and I'm quite sure that file editing and uploading are not the only relevant cases (e.g. WebDAV and FTP are other ways to modify file contents). Wouldn't it be the best solution to generate an IObjectContentModifiedEvent in the File._setData method and not the view classes? Cheers, Uwe Dr. Uwe Oestermeier Institut fr Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Missing ObjectContentModifiedEvent
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 are more like descriptive metadata (e.g. modification time). The distinction however is not clear cut because content objects can be much more complex than simple files and metadata can also be stored in annotations. In my use case, however, it makes sense to draw such a distinction because I'm using the filesystem to store versions. Content in this sense is simply that what can be edited by opening and writing files. Since Zope3 supports WebDAV and FTP something similar is probably needed for other systems too. But I could also live with ObjectModifiedEvents only. I've to check all aspects of an object anyway, because the non-content parts of an object are versionable too. Currently I loop over all versionable attributes (which are provided by special adapters) and try to detect all differences between new and old versions of an object. A more radical approach would be to specify in each ObjectModifiedEvent which aspects of an object changed. By aspect I mean the schema and the modified field within the schema: class IPerson(Interface) : age = Attribute(The age of the person) class Person(object) : implements(IPerson) person = Person() person.age = 42 zope.event.notify( ObjectModifiedEvent(person, aspect=IPerson[age])) File content then could be handled as a special case : file.data = ""> zope.event.notify( ObjectModifiedEvent(person, aspect=IFile[data])) With this extension the ObjectModifiedEvents would be more informative and a loop over all versionable attributes in my application would become unnecessary. This would also make updates of catalogs more efficient. Regards Uwe Oestermeier ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
