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=66712&view=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] 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
[Zope3-dev] EuroPython sprint?
Hi, the sprint schedule on http://wiki.python.org/moin/EuroPython2006 lists a Zope3-sprint. The details seem to be very unclear. Can anybody confirm that the sprint will take place before the conference? Thanks, 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] 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] 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] 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] Proposal for optimized Blob handling
Christian Theune <[EMAIL PROTECTED]> schreibt:
>This is how the dance looks like to do the link():
>
> >>> 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.path.exists(d.name)
> False
> >>> os.path.exists('/tmp/asdf')
> True
> >>> open('/tmp/asdf').read()
> 'Test'
Yeah, but as Dieter said the temp file should be better renamed or moved
to a save location.
It is likely that a temp file disappears.
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 "", 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] IKeyReference for files
Martijn Faassen <[EMAIL PROTECTED]> schreibt: >Now I'm hoping I'm missing some kind of strategy and perhaps someone >will have a luminous idea to make this work without the creation of a >separate index. Or if not, at least I can give up looking and just go >and write that index. Does anyone have any suggestions? Hi Martijn, I have experimented with the inodes of files, which are a good candidate for IKeyReferences for files. Using inodes solves the problem that the ids should remain stable across moves. They are also a good basis for a detection of moves which happen outside the control of Zope. The problem that a lookup requires a directory walk can perhaps be reduced if one keeps hard links to the target files in a separate directory. If the hard links use the ids as filenames one could efficiently access the file contents without search. I have never tested this idea, but perhaps it may be worth a try. 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
[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] State of zope.fssync
Jim Fulton <[EMAIL PROTECTED]> on Mittwoch, 2. Mai 2007 at 14:34 Uhr +0100 wrote: >fssync isn't included in releases, so I don't think it matters. I >suggest you *move* these two packages out of the Zope 3 tree to their >own projects. There's no need, IMO, to leave externals behind. There are already two separate projects zope.fssync and zope.app.fssync which have been created for eggification. I will move the code to these places. zope.xmlpickle seems to be used only by zope.fssync. Shall I move this package too? 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] Upcoming Zope3 Sprint 9-11 Nov.
Hi all, the Bebop Team would like to invite Zope3 developers to the second NeckarSprint at the Knowledge Media Research Center, Tuebingen, Germany. The meeting will start on Friday, November 9 and end on Sunday, November 11. This time the focus of the sprint will be on code maintenance, cleanup of dependencies, etc. Be warned! It will be the most boring sprint that ever happened: no exiting new ideas, no new killer features, no social events :) If you are interested in spite of my warnings consult the WikiPage at http://wiki.zope.org/zope3/NeckarSprint2007 Please add yourself to the participants on the Wiki or send me an email if you cannot edit the page. Hope to see you in Tuebingen, 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: 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] 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 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
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
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
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: > 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) revealed that there are only a few places were these events are actually fired. Most usages occur inside tests. ObjectModifiedEvents are fired in 1. app.form.browser.add (in a _set_after_add hook together with a list of fields) 2. app.form.browser.editview (after a call of applyWidgetsChanges) 3. app.form.browser.editwizard (after a call of applyWidgetsChanges) 4. app.fssync.committer (after a call of adapter.setBody) 5. zope.app.workflow.stateful.definition (in _publishModified, seems to be related to container events) 6. zope.app.container.contained (in setitem and uncontained) An ObjectAnnotationsModifiedEvent is used in 7. zope.app.dublincore.browser.metadataedit (for dc.title and dc.description) ObjectContentModifiedEvents are currently not used, as already mentioned. According to the intrinsic/extrinsic distinction 1-4 are clear cases for ContentModifiedEvents (or ValueChangedEvents), 5 & 6 indicate modified containers, which are presumably ContentModifiedEvent according to the intrinsic/extrinsic distinction. 7 is the only clear case for an extrinsic usage. Therefore one should use ObjectContentModifiedEvent for 1-6, and an ObjectAnnotationsModifiedEvent for 7. As far as I see, 4. becomes redundant, if File._setData fires the event. But the general question is, whether the adapter or the adapted interface should send the event. 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) are probably sufficient: 1-3: ObjectModifiedEvent(obj, interface=schema, attr=field, oldvalue=old, newvalue=new) 4: ObjectModifiedEvent(obj, interface=IObjectFile, attr="setBody") 5: ObjectModifiedEvent(obj, interface=IContainer, attr="__setitem__") 6: ObjectModifiedEvent(obj, interface=IContainer, attr="__delitem__") 7: ObjectModifiedEvent(obj, interface=IZopeDublinCore, attr="title") Since the keywords are optional, these changes could be easily made in a backward compatible way. 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
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 propose to use pluggable modification utilities. The container related events are already fired by only two functions (setitem and uncontained). If we introduce a third one for object modification (e.g. update or modify and an additional annotate if needed), we can replace these functions with callable utilities, which are responsible for performing the changes and firing the events. It's then up these components which events are actually used. Direct calls of ObjectModifiedEvents can then be marked as deprecated to ensure that all applications will use these pluggable modifiers. Regards, Uwe The following code should make clear what I mean: #! python import doctest, unittest, zope from zope.app import zapi from zope.interface import Interface, implements from zope.app.event.objectevent import ObjectModifiedEvent from zope.app.event.interfaces import IObjectModifiedEvent class IPluggableModifier(Interface) : """ A pluggable modifier can be used to replace the existing modification mechanism in Zope. It should be used in all places where other systems are notified about changes. The implementation must ensure that at least one IObjectModifiedEvent is fired if an object's state has been changed. """ def __call__(self, obj, interface, **kw) : """ Performs the update and fires an IObjectModifiedEvent. It's up to the plugin which specialization of IObjectModifiedEvent is actually used. Returns the modified object or None if the object could not be modified. """ class DefaultModifier(object) : """ Implements a default behavior that mimics Zope3's current modification event handling. Setup : >>> from zope.component import provideUtility >>> provideUtility(DefaultModifier(), IPluggableModifier) >>> events = [] >>> zope.event.subscribers.append(events.append) >>> class Sample(object) : pass Usage : >>> modify = zapi.getUtility(IPluggableModifier) >>> sample = Sample() >>> result = modify(sample, None, title='Test', description='Example') >>> result == sample True >>> IObjectModifiedEvent.providedBy(events[0]) True >>> sample.title 'Test' >>> sample.description 'Example' """ implements(IPluggableModifier) def __call__(self, obj, interface, **kw) : """ Modifies an object and fires an IObjectModifiedEvent. """ if interface is not None : obj = interface(obj) for key, value in kw.items() : setattr(obj, key, value) zope.event.notify(ObjectModifiedEvent(obj)) return obj class ValueChangedEvent(object) : """ A modification event that keeps additional information about the used interface, the old and new values. """ def __init__(self, object, interface, key, old_value, new_value) : self.object = object self.interface = interface self.key = key self.old_value = old_value self.new_value = new_value class BetterModifier(object) : """ Implements a modification behavior that fires more informative events for more efficient versioning and reindexing. Setup : >>> from zope.component import provideUtility >>> provideUtility(BetterModifier(), IPluggableModifier) >>> events = [] >>> zope.event.subscribers.append(events.append) >>> class Sample(object) : pass Usage : >>> modify = zapi.getUtility(IPluggableModifier) >>> sample = Sample() >>> result = modify(sample, None, title='Test', description='Example') >>> result == sample True >>> sample.title 'Test' >>> sample.description 'Example' >>> for x in events : print x.__class__.__name__ ValueChangedEvent ValueChangedEvent ObjectModifiedEvent """ implements(IPluggableModifier) undefined = object() def __call__(self, obj, interface, **kw) : """ Modifies an object and fires an IObjectModifiedEvent. """ if interface is not None : obj = interface(obj) for key, value in kw.items() : old = getattr(obj, key, self.undefined) if old != value : setattr(obj, key, value) event = ValueChangedEvent(obj, interface, key, old, value) zope.event.notify(event) zope.even
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: What is modification, and why do we care? (was Re: [Zope3-dev] Missing Object
[EMAIL PROTECTED] wrote: > >- A persistence or versioning system wants to know when objects > have changed so that they can save new versions of the object. > > This needs to be pretty much fool proof. To do this, I think you > really need to do something like what the ZODB persistence > mechanism does. Perhaps for versions, once could hook into > this mechanism somehow. Yes, that's an alternative I'm considering. It would be nice to have an explict API for getting the modified objects of a transaction and I remember that this was discussed on another list months ago. Is there such an API already? I didn't find one. > >- Record, as meta data, the time that an object changes. > My original thought was that this would track only > data, not meta-data changes. This is not what we are doing now. > For example, updating an object's DC title changes it's modification > time. > > I'm not sure what we should do here. In my view this depends on the use case. For instance, currently I'm working on a blog system that uses DC title and description together with the body of the blog entry as parts of a searchable text. The whole blog entry with title, description, and body appears to the user as a unit. In this case it seems ok, that the modification date is changed if one part of the searchable text is changed. But I'm also using DC effective as publication date and there it would be misleading if a change of the publication date also changes the modification date. So we have at least two types of annotations here. This was one reason, why I proposed a pluggable mechanism for event notification. We cannot know in advance what kinds of events are really needed and which distinctions will be necessary in the future. But I agree with you, that the use of a utility is not very Pythonic, although the proposed modify(obj, key1=value1, key2=value2, ...) syntax was borrowed from dict.update. > >- Update indexes (and other cache-like data structures) > > There is a thought that perhaps the generated event could > contain enough information to eliminate some indexes from > use. This is (mostly) an optimization. ... > > 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. Yes, not from outside. But as a programmer I know which interfaces I use. To use the blog example again: given that the used interface+attribute is recorded in the modification event it's not to difficult to write a subscriber that listens to changes of the body, the title or description, and fires an additional modification event for ISearchableText["getSearchableText"] if a change of a part is detected. The problem of computed attributes has to be solved anyway. If I have an object schema that promises an attribute and the value is computed from the state of other objects we have chains of dependent modification events, or we cannot rely on the event mechanism any longer. It is probably easier to write and understand such chains if the events describe in detail what happens. > > >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. That might be, but what remains from the idea of loosely connected components that communicate via events if we need hooks into the transaction machinery for versioning, a special dependency checker for indexing and caching, and application specific modification events even for a simple blog implementation? > > >Thoughts? The container events are much more specific and contain enough information to undo/redo the described operation. Why are modification events treated differently here? Wouldn't it be a usefull rule of thumb, that all events should carry enough information to be able to undo/redo them? I agree with Dieter that efficiency will become important as soon as Zope3 has to cope with office documents and user expectations. I'm not sure whether all optimization issues should be left to the applications. This will result in applications that use hooks, direct update calls, etc. instead of events and it will become difficult to use them in combination. > >Are there other applications for modification events that >I haven't considered? I'm using modification events in a wxPython app with a MVC architecture. Zope3 events are a very clean way to keep models and their views in sync. There are of course other ways to avoid unnecessary flicker, but the most easy way to update only the affected parts of a view is to specify the changed part of the model. That was also a motivation behind my proposal to use a pluggable modification mechanism. -- Uwe > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-
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
"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 be 'better', but if the framework is flexible enough to capture typical use cases like versioning and indexing in an efficient way this is 'better' than the current state. > > >- What new burdens does this place on application developers? Does Zope >core now have to keep track of what "extra" information is conveyed in >various scenarios? What about library vendors? As far as I can see, the extra burden is relatively small. The additional explictness makes debugging and testing probably easier. Zope core should not keep track about scenario specific modification descriptions, but new ones should be defineable. > > >I've viewed the current ObjectModifiedEvent as being appropriate for >simple interfaces like the ZMI. In many cases, this simple event model >works perfectly. Different applications are free to layer new event >models on top of that. >The way to add new event models (at least in my experience) is to create >new event types -- not embed "extra" information in an otherwise clearly >defined data structure. > >It seems to me that we're trying to make the ZMI anticipate >application-specific requirements without knowing that those might be. > >I'd rather see something like this: > >- If a utility (or some other pluggable component) uses specific >information from an event, it should provide an event interface that >describes what it needs. > >- An application that's aware of that component type can fire an event >that provides that interface. As far as I can see, this is still possible and works probably fine within one application. But if we want to combine different apps (e.g. a groupware with a versioning system with a special text index), changes are high that application specific events will not work together in the long run, because each application developer has to keep track of new event types, changes in the interface, etc. of other applications. For a framework, I prefer more complex but reusable events over simple but application specific events. In my application I was quite satisfied with Zope3's container events from the beginning, and I'm quite sure that this is due to their higher informativity. All in all, the current proposal combines simplicity (AnnotationModifiedEvent and ContentModifiedEvent are obsolete) with optional modification descriptions. It is at the same time easy to integrate in the current framework and still open to application specific events. > 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
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 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. > >This information would be a hint that subscribers could use, or not use >as appropriate. > >We could change the form machinery in an obvious way to generate >attribute descriptions. ___ 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] Heads up: zope.app.intid and zope.app.keyreference are now opt
[EMAIL PROTECTED] wrote: >The fact that you can't get key references for persistent objects is a >real >pain. I've thought a lot about that, but haven't come up with a good >solution. >(Phillip Eby suggested using GUIDs at one point. I've always been a bit >suspicious of GUIDs myself.) What's the problem with GUIDs? Many systems use them (e.g. the Chandler repository, SVN) to solve similar problems. Doesn't WebDAV locking require GUIDs anyway? 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] Heads up: zope.app.intid and zope.app.keyreference are now op
[EMAIL PROTECTED] wrote: >They aren't guaranteed to be unique. They are statistically >very unlikely to conflict, but that chance of a conflict makes >me nervous. We tend to create a lot of these, so I think the chances >for conflict are higher than in many other applications. >A major component of variablility in guids is Mac or IP >address, which wil lbe constant on servers that may need to generate >millions of ids. You know probably Leach & Mealling's discussion of possible solutions: http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt > >Certainly, it should be possible to implement GUID-nased key >references, although you will need to store GUIDS on the objects. >Feel free to try it. I'd be interested to see how well it works over >the long run. We are using GUIDs with combined IP address, timestamp, and random numbers in our application since three years without problems. But that's no sufficient evidence. Are there other list members that use GUIDs? Has anybody ever recognized problems of uniqueness? 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
[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
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
Re: [Zope3-dev] Re: RFC: Rename "principal" to "participant"
Martijn Faassen wrote: > >I ended up creating a first class User object too. See also my note >about being able to access these in content space. > The same holds for my project. Shouldn't they be part of the framework if so many applications need them? Whether these user objects are placed in the content space or under ++etc++ is another question. Perhaps it would be best to have both options. -- 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
[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] zope3 website report?
Martijn Faassen wrote: >I'm very curious to see what work was done on a Zope 3 website at the >Neckar sprint. Can someone send a report to the list? We (Dominik Huber, Tonico Strasser, Gregoire Weber, and I) set up a zope3org package (http://svn.zope.org/zope3org/) with the following parts: wikification - A wiki view that transforms sets of HTML documents within in a nested folder structure into a Wiki. We defined no special content types. We decided to use only files and folders to be able to work via ftp, fssync etc. as much as possible. comment - A simple comment implementation that stores list of comments in an object's annotations. kupusupport - An integration of Kupu into Zope3. Defines an editor that can be selected from the ZMI menu. We started that from an older version of the IsarSprint and still have to do some work to support the current 1.3.1 version of Kupu. importer - a wget like tool that allows to import existing Wiki pages or other HTML documents from any URL. The pages can be post- processed to extract the content and strip out navigation, etc. This tool Unfortunately we did not manage to plug all parts together, but I hope that we can bring up a demo site soon. Especially the view with the integrated Kupu editor and a complete navigation has still to be assembled. We will also document things in more detail on the NeckarSprint page. Cheers, 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: zope3 website report?
[EMAIL PROTECTED] schreibt: >Hi Mikhail, > >the outline is nice, but contains items that we do not have already; for >example it has a huge documentation section with lots of items, but none >of >this type of documentation exists and you cannot expect it to magically >appear. It would be really nice to have this stuff, but I do not see how all the content can be produced in the near future. > >Having said this, I really wish someone would take ownership in >developing our >zope3.org site. Unfortunately I have not heard from Uwe anymore, but >someone >should contact him and see what's going on. I continued the work on the wikification and the Zope2.org importer. At least in principle we can take over most of the existing Zope3Dev wiki automatically (without comments at the moment). But without a review of what is outdated and still important this does not make sense. So this may be a starting point for someone who is willing to work on the content of the new site. > > >With that much interest I would hope that a steady developer group around >zope3.org would form. Is that possible? IS someone willed to take the >lead? Due to my other duties I'm only willing to continue the things we started at the Sprint (I hope to be able to add ReST editing until the end of the next week), and may also coordinate other technical issues but I'm certainly not able to coordinate community and marketing issues. > 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: 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
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] Ajax in Zope 3
Hi Tarek, > > >Before starting it up, I was thinking that it would be nice if the whole >Z3 community would be using the same toolkit, and maybe, even integrate >it into Z3 itself. a toolkit that is shared by the whole Zope community would be great, independent of the question whether it should be part of Z3 core or not. As an alternative http://svn.zope.org/zope3org could also be a place where all contributors could access and maintain such a library. > >If this sounds like a good Idea, I would like to start a Z3 proposal on >this topic, and contribute on its integration in Z3. +1 on a proposal. I would like to contribute to such a package too. > > Regards, Uwe ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
