RE: [Zope3-dev] RE: OQL
it is undoubtedly a demonstration of your broadmindedness -Original Message- From: Chris Withers [mailto:[EMAIL PROTECTED] Sent: vendredi 9 décembre 2005 19:21 To: Fabrice Monaco Cc: zope3-dev@zope.org Subject: Re: [Zope3-dev] RE: OQL Fabrice Monaco wrote: I must perpare the migration of all applications in zope2 to zope3. it is the moment to decide if I contiue in technology zope3/python or another technology example : or Linux/Apache/Python/Postgress is nice... with Firefox+Xul or Windows/ASP.net c# http://www.dotnetnuke.com/ I am thus not wedged Cool, I wholeheartedly urge you to move to one of these other platforms, and quit pestering these mailing lists with your insistence on replying to digests and your inability to reply in the context of the mail you're replying to... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope common criteria certification
Good news, today I'm starting my funded work on the common criteria certification for Zope 3. I'm targeting to get Zope 3.3 certified. If I (we) do not achieve that, we should forget about the certification. But I'm expecting Zope 3.3 to be fit for certification. This week, I will create a proposal for the functionality we need to include in Zope 3.3, make a task list (more or less for myself, but publicly visible) what needs to be done on the documentation and will familiarize myself with the current security policy and the one Jim proposed to include to make a decision about which one should be certified. Depending on the amount of time left, I'll start working on the tasks on the list for documentation. I'll continue the work in January by completing the documentation and starting to work on the functionality. After January there will be a break where the evaluation body will check the documents. I'll be at PyCon to spend 2 days of the sprint working on the functionality and explaining certification issues to whoever is interested. In late April/May I'll join the effort to make Zope 3.3 happen, especially regarding the security functionality and to make it fit for evaluation of the TUV. I'm interested in any feedback you have. Cheers, Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Wiki subscription on mailing list?
Is it intentional that the mailinglist is subscribed on the wiki? I find it quite convenient to update the pages while I'm working on it, but that generates a _lot_ of traffic on the list... Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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: Wiki comments
Am Montag, den 12.12.2005, 13:26 +0100 schrieb Philipp von Weitershausen: Christian Theune wrote: I propose to disable the comment functionality on the wiki pages for the Zope 3 developer Wiki. +1 Do you have any idea how that works? :) -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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: Wiki subscription on mailing list?
Am Montag, den 12.12.2005, 13:29 +0100 schrieb Philipp von Weitershausen: AFAIK the list isn't subscribed but individual people. They only get spammed :). I inspected the headers of the notifications I received and saw they contained the list headers. By the way, I prefer editing things in a proper text editor (read: emacs) first and then copy it back to the text area. I think there's even a Mozilla plugin that automates that now. Hmm. Right. I just saw the external editor function actually works, so I can use my favorite editor as well. At least it will only save to the server when closing the editor then. -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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: Wiki subscription on mailing list?
Am Montag, den 12.12.2005, 13:36 +0100 schrieb Christian Theune: Am Montag, den 12.12.2005, 13:29 +0100 schrieb Philipp von Weitershausen: AFAIK the list isn't subscribed but individual people. They only get spammed :). I inspected the headers of the notifications I received and saw they contained the list headers. Oh man. No. I just was confused. The wiki creates those headers and they look partially the same as the ones for zope3-dev. You're right. Everyone gets spammed on his own request ... ;) -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Locale-specific Text Collation
Jim Fulton wrote: When presenting users with ordered text (e.g. sorted lists of options), simply sorting Unicode strings doesn't provide an ordering that users in a given locale will find useful. Various languages have text sorting conventions that don't agree with the ordering of Unicode code points. (This is even true for English. Generally, users prefer to see text sorted without regard to case.) A proposal to address this problem is here: http://dev.zope.org/Zope3/LocaleSpecificTextCollation Comments are welcome. +1 I especially like the easy handling of this adapter, given Python 2.4's improved sorting API (that one went totally unnoticed by me up until now!). See http://wiki.python.org/moin/HowTo/Sorting for a nice howto. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Twisted Publisher and Zope 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: On Mon, Dec 12, 2005 at 07:18:05AM -0500, Jim Fulton wrote: | We should proceed by getting Z2 and Z3 to use a common | publisher, presumingly based on the Z3 publisher. This common | publisher should: | | - Be well documented and tested. | | - Use WSGI for HTTP | | - Be backward compatible with Both Z2 and Z3 | | - Should be highly customizable through components. This will | hopefully allow z2-stype and z3-style publication to coexist in | a single app server. | | Again, I expect that the Z3 publisher will be the best starting point. | | Note that the Z3 publication framework splits functionality | currently provided by the Z2 publisher into a publisher and a | publication object. An initial step might be top come up with | a Z2 publication object that works with the Z3 publisher. You haven't said anything about the server. I assume this Z3/Z2 publication object hybrid would run with with the Z3 server instead of the Z2 ZServer. If WSGI lives up to its promise, then the WSGI-compliant Z2-Z3 hybrid would be publishable as a WSGI application from any WSGI server, including perhaps mod_python-based servers. Ob. note: the performance characteristics of such servers (including twisted) are not well understood in the context of Zope, until some brave soul actually rolls out a high-volume production site and reports success or failure. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDnXQh+gerLs4ltQ4RAjzbAJ4+5SAPXcxnbo3IY7tWODabMuLajgCgyNFK mW6JmvMV9vcc0xq/xKOyOdM= =flX1 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Locale-specific Text Collation
Hi, Am Freitag, den 09.12.2005, 08:58 -0500 schrieb Jim Fulton: When presenting users with ordered text (e.g. sorted lists of options), simply sorting Unicode strings doesn't provide an ordering that users in a given locale will find useful. Various languages have text sorting conventions that don't agree with the ordering of Unicode code points. (This is even true for English. Generally, users prefer to see text sorted without regard to case.) A proposal to address this problem is here: http://dev.zope.org/Zope3/LocaleSpecificTextCollation Comments are welcome. I wondered whether the method key will always be computable, but discussing that with zagy I found out that doing __cmp__ requires one to be able to normalize the string for a different comparison anyway, so they key method would be the one doing that. Eventually you might want to mention that the key() method would be useful to implement as basis for __cmp__ anyway as it does the normalization work, so __cmp__ should in any case be possible to derive from key() ... So, from me as well: +1 Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RE: [Zope3-checkins] SVN: Zope3/trunk/src/zope/app/ Try to fix the zpkgdependency info for zope.app.content_types.
Hi is it possible to change the package name: zope.app.content_tpye to zope.app.contenttype And remove the underscore like described in PEP 8? at: http://www.python.org/peps/pep-0008.html Regards Roger Ineichen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Sutherland Sent: Monday, December 12, 2005 3:00 PM To: [EMAIL PROTECTED] Subject: [Zope3-checkins] SVN: Zope3/trunk/src/zope/app/ Try to fix the zpkgdependency info for zope.app.content_types. Log message for revision 40723: Try to fix the zpkg dependency info for zope.app.content_types. Changed: U Zope3/trunk/src/zope/app/PACKAGE.cfg U Zope3/trunk/src/zope/app/file/DEPENDENCIES.cfg -=- Modified: Zope3/trunk/src/zope/app/PACKAGE.cfg === --- Zope3/trunk/src/zope/app/PACKAGE.cfg 2005-12-12 13:38:55 UTC (rev 40722) +++ Zope3/trunk/src/zope/app/PACKAGE.cfg 2005-12-12 14:00:03 UTC (rev 40723) @@ -40,9 +40,8 @@ component container content -# We should convert content_types.py to a package and include it via -# the dependency mechanism. -content_types.py +# We should include content_types via the dependency mechanism. +content_types copypastemove # Maybe convert to a package as well. datetimeutils.py Modified: Zope3/trunk/src/zope/app/file/DEPENDENCIES.cfg === --- Zope3/trunk/src/zope/app/file/DEPENDENCIES.cfg 2005-12-12 13:38:55 UTC (rev 40722) +++ Zope3/trunk/src/zope/app/file/DEPENDENCIES.cfg 2005-12-12 14:00:03 UTC (rev 40723) @@ -1,6 +1,7 @@ persistent transaction zope.app +zope.app.content_types zope.app.onlinehelp zope.interface zope.publisher ___ Zope3-Checkins mailing list [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope3-checkins ___ 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-checkins] SVN: Zope3/trunk/src/zope/app/ Try to fix the zpkgdependency info for zope.app.content_types.
On Monday 12 December 2005 10:10, Roger Ineichen wrote: is it possible to change the package name: zope.app.content_tpye to zope.app.contenttype +1 Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: Twisted Publisher and Zope 2
On Monday 12 December 2005 07:59, Tres Seaver wrote: If WSGI lives up to its promise, then the WSGI-compliant Z2-Z3 hybrid would be publishable as a WSGI application from any WSGI server, including perhaps mod_python-based servers. Right, I think there have been success stories with mod-python and Zope 3's WSGI implementation already. Ob. note: the performance characteristics of such servers (including twisted) are not well understood in the context of Zope, until some brave soul actually rolls out a high-volume production site and reports success or failure. Itamar and I did some early and non-scientific performance testing and it turned out that twisted is just a tiny bit slower than zserver, almost not enough to detect it in comparison to the time the publisher takes. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Stephan Richter wrote: On Monday 12 December 2005 02:53, Philipp von Weitershausen wrote: Basically, it now proposes to go one step further: Layers and skins will always be simple interfaces extending IBrowserRequest. The only difference between skins and layers is that only skins are registered as local utilities under a human readable name whereas layers are plain old boring interfaces with no extra marker (it's not needed at all). Hold on, but skins and layers can also still extend other skins and layers (as they do now), right? Sure. I should have said: Layers and skins will always be simple interfaces **directly or indirectly** extending IBrowserRequest. The indirectly means by inheriting from some other skin or layer interface. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Wiki cleanup
On Sunday 11 December 2005 09:37, Christian Theune wrote: a) Can we agree on a target group for the Zope 3 wiki? Can it be core developers only? Okay, fine with me, though documentation is clearly interesting to anyone. Maybe we should split the Wiki into two sections, core developers and regualr developers. b) What do we do to old/outdated/historic information? I'd just hide it in the HistoricalPages page. Yep, that's what it is for. c) SubProjects/Proposals ... isn't that actually almost the same? What's the difference? Nope. A proposal is a suggestion for change with a very focused, narrow objective that is well understood and can be implemented in a controlled time frame. Sub-projects are much more open-ended and might produce many proposals. Sub-projects are also used to host other developer info, such as the language dictionaries. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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?
Summary: 1. Why not a zope2.org site? 2. Tentative, shaky suggestion on maintenance of website Hi, Sorry for this post from someone not contributing at all. My only contribution to zope ( apart from making a hundred or so people aware of it and a couple of dozens attempt to adopt it on a few projcts) has been regular visits to zope.org at least once a week from 1999, and almost daily since 2004. This discussion, coupled with the discussion on separating the zope3 repository, is extremely motivating and also very educating to technologically challenged people like me. 1. zope2.org Since both zope2 and zope3 are live projects in their own right, and at this point both have something to offer individually to the development community and more importantly to each other, and since (probably, hopefully) ZOPE as a brand is more important for both, why not have a zope2.org site in addition to zope.org and zope3.org? The main zope.org site could address a common vision and focus on commonalities and common concerns, while the individual sites could focus on issues specific to them. I have just now discovered that zope2.org as a domain name is available and have requested it to be booked. How do I transfer it to the zope community, if it gets booked at all? 2. Maintenance: Is this a way? As far as maintenance is concerned, I could suggest to a few developers -maybe not very experienced- ( from Mumbai, India) that they help part time. In that case, could they get guidance from the community seniors through email? I would also appreciate if someone can guide me on the hardware, software and connectivity infrastructure needed for this. Hopefully, over a period, capability will get built locally. I would also like to explore the possibility of persuading Science/ Engineering students to develop in/ for zope as part of their academic project work. Any suggestions? I take this opportunity to thank all those involved in Zope. Thanks Milind Khadilkar G2, Radha Bhuvan, Hanuman Cross Road No. 1, Vile Parle (E), Mumbai 400057. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZRS version 2?
[Chris Withers] ... Was ZRS 2 ever implemented? Not yet, no. We still talk about it, but it hasn't burbled to the top of anyone's priority list yet. If you want to see it, buy lots of copies of ZRS 1 ;-) ___ 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-checkins] SVN: Zope3/trunk/src/zope/testbrowser/ fix bug caused be impedance mis-match between Mechanize and zope.testbrowser
Chris Withers wrote:
Benji York wrote:
In this case we'd have to mark all characters but the space as safe.
This isn't the normal type of URI quoting issue, this problem arises
because nothing else in the call chain quotes the spaces
Ah, okay, nice to have would be a docstring to avoid people like me
misinterpretting what the method is for.
Two of the three lines of _quote are comments about why the method
exists, is there something that you'd like added? Perhaps it shouldn't
be a method at all, but refactored to be inline (with comments).
(Mechanize or urllib) because they don't need to, but HTTPCaller does
a .split() on the first line of the request so there can be no
unexpected spaces. Any other character is acceptable.
Hmm, is it correct for HTTPCaller to do a split like this?
Maybe a .split(' ',3) or whatever would be better?
That, specifically, wouldn't work, but no matter; the RFC is pretty
clear that there can be no more than 2 space characters in the first
line of the request, so I don't really think anything different should
be done.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
On Mon, Dec 12, 2005 at 09:19:39AM -0500, Jim Fulton wrote: | | Note that the Z3 publication framework splits functionality | | currently provided by the Z2 publisher into a publisher and a | | publication object. An initial step might be top come up with | | a Z2 publication object that works with the Z3 publisher. Here's a status report: I've started a Z2 publication object in the 'publication-refactor' branch of Zope 2. I am not 100% sure this is what you had in mind, but basically i've broke down the 'publish' method from ZPublisher.Publish into the methods of IPublication, and it seems to have mapped quite well with some minor exceptions. I haven't gotten around to implementing the traverseName method, which will need some deep surgery on ZPublisher.BaseRequest. Now, what I have in mind moving forward is to replace the code in ZPublisher.Publish and ZPublisher.BaseRequest to use the Zope 2 IPublication instead of duplicating code once I'm done with implementing the interface. My only fear so far is that there might be some issues with the request object itself being not 100% backwards compatible, but I think we can have backwards compatibility implemented as an adapter from the Zope 3 request to Zope 2 request. How does that sound? -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
Another update: On Mon, Dec 12, 2005 at 04:18:48PM -0200, Sidnei da Silva wrote: | I haven't gotten around to implementing the traverseName method, which | will need some deep surgery on ZPublisher.BaseRequest. This is done now. | Now, what I have in mind moving forward is to replace the code in | ZPublisher.Publish and ZPublisher.BaseRequest to use the Zope 2 | IPublication instead of duplicating code once I'm done with | implementing the interface. This is done too. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/app/content_types - ported OFS.content_types from Z2 to Z3 (which is the most recent maintained code)
Andreas Jung wrote: Log message for revision 40683: - ported OFS.content_types from Z2 to Z3 (which is the most recent maintained code) As a result of a recent sprint, ZC has a package (zope.mimetype) that would probably be more useful to people interested in such things. I put it and another package that depends on it (zope.file) into the .org repository as top-level projects today. Perhaps efforts can be directed toward integrating zope.mimetype (and zope.file) into the core. That'll require a proposal; we'll wait until people have had a chance to examine/use the code first. As always, feedback is welcome. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
Philipp von Weitershausen wrote: (http://dev.zope.org/Zope3/SimplifySkinning) yet another overhaul. Basically, it now proposes to go one step further: Layers and skins will always be simple interfaces extending IBrowserRequest. The only difference between skins and layers is that only skins are registered as local utilities under a human readable name whereas layers are plain old boring interfaces with no extra marker (it's not needed at all). Along with that we can get rid of the browser:skin / and browser:layer / ZCML directives and simply reuse existing, much simpler directives from the standard Component Architecture (interface / and utility /). This is not only a good step towards reducing the ZCML directive proliferation, it's also a reflection of what's going on under the hood. If we simplify under the hood, the Zope 3 developer should benefit from that simplification as well. That's now happening. The rest of the changes deal with small harmonizations that should make the understanding of certain patterns easier (if they're always the same). Looking-for-comments-as-usual-ly +1 in general, but two cosmetics-change-requests. 1. The brand *skin* and *layer* are fairly common and they are reflecting two logical uses cases. At a first glance the usage for a layer type is not given, but the layer concept is still interesting to build modular skins. The layer audience could be the developers which like to share layer specific informations. IMO an use case for an Browser Layer Names utility could be a corresponding online-documentation within the api-doc. I would suggest to register the layers like skins using a ILayerBrowserType interface: interface interface=.interfaces.I18NFeatures type=zope.publisher.interfaces.browser.IBrowserLayerType / 2. I liked the naming ISkinType and ILayerType much more (instead of IBrowserSkinType/ IBrowserLayerType), because this browser-specific differentiation is already given by the package hierarchy and those ILongCamelCaseWordingsThatTriesToExplainEverything are hard to type and at the end they confuse newcomers even more than the simple ones. Please keep the naming also simple and stupid like the skinning simplification itself :) Regards, Dominik begin:vcard fn:Dominik Huber n:Huber;Dominik email;internet:[EMAIL PROTECTED] tel;work:++41 56 534 77 30 x-mozilla-html:FALSE version:2.1 end:vcard ___ 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-dev Digest, Vol 29, Issue 9
its good for specific application deployments, as intimately tied to the appserver its bad, since it dictates deployment requirements to have a xul capable client, ie. non standard, defacto or otherwise. -kapil On Tue, 06 Dec 2005 07:26:30 -0800, Fabrice Monaco [EMAIL PROTECTED] wrote: For the backend (manage) this isn't problem. i have just one suggestion FireFox+xul+Zope is good ? -Original Message- From: Chris Withers [mailto:[EMAIL PROTECTED] Sent: mardi 6 décembre 2005 16:07 To: [EMAIL PROTECTED] Cc: zope3-dev@zope.org; Fabrice Monaco Subject: Re: [Zope3-dev] RE: Zope3-dev Digest, Vol 29, Issue 9 Stephan Richter wrote: On Tuesday 06 December 2005 09:44, Fabrice Monaco wrote: Why not XUL? Because it sucks and is browser-specific. Be careful, or you'll have Paul in tears ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/hazmat%40objectrealms.net -- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] xml import / export in z2 z3
fwiw, we're working on doing this in plone land, utilizing the non standard, fast, incremental, validating XmlReader interface from libxml and pluggable namespace handlers. the xmlreader iface is very SAX like. http://svn.plone.org/view/archetypes/Marshall/branches/k_vertigo-pluggable-ns/ -k On Wed, 07 Dec 2005 06:33:46 -0800, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: Martijn Faassen wrote: Andreas Jung wrote: I'm about to write an xml importer for importing simple data (properties, dictionaries). Exporting is easy, importing is trickier because a parser is required. Is there any prefered framework for doing such things in zope3 (zope2)? Sax or DOM...it depends on the usecase and the algorithmic approach you take. Sax is fast but you have to build your own datastructures, DOM is slow, takes a lot of memory but it gives you a tree to perform any fancy operation on it.. DOM is also not particularly Pythonic (neither is SAX, but it is relatively simple at least). You could also look into ElementTree (or lxml, which implements that API too). ElementTree (though not yet lxml) also introduces iterparse, which is a kind of streaming version of the ElementTree API. ElementTree's API is a much nicer way to work with XML from Python than DOM. Also it's more lightweight than even MiniDOM. Regards, Martijn thanks for the info Martijn, I'm going to look at it. I've done some work with ElementTree for CPSIO, and I haven't found it very easy to use because of all the extra namespace URI, and xpath stuff used for the tree navigation (xpath_findall, ..) which seem to get in the way. Also it could be that I find the DOM approach easier since I'm used to it in javascript already. the question is also about being able to reuse parts of the export/import code of CMFSetup / GenericSetup and possibly simplify the zope2 - zope3 migration of existing applications. best /JM ___ 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-checkins] SVN: Zope3/trunk/src/zope/app/content_types - ported OFS.content_types from Z2 to Z3 (which is the most recent maintained code)
Am 12.12.2005 um 21:34 schrieb Benji York: Andreas Jung wrote: Log message for revision 40683: - ported OFS.content_types from Z2 to Z3 (which is the most recent maintained code) As a result of a recent sprint, ZC has a package (zope.mimetype) that would probably be more useful to people interested in such things. I put it and another package that depends on it (zope.file) into the .org repository as top-level projects today. Reading with interest the code of zope.file I saw, that although the iterator is used for the delivery of the data, the data is first read into memory completly. Also the storage in the zodb is done as one big chunk. Actually it is copied twice before it is wrapped in the iterator. data = context.open(rb).read() self.headers += (Content-Length, str(context.size)), self.body = bodyIterator(cStringIO.StringIO(data)) Is this done on purpose? Or is this implementation meant as a basic one, which will be replaced by something like a filesystem storage or the new zodb-blob support in the upcoming next version? With regards, __Janko ___ 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-checkins] SVN: Zope3/trunk/src/zope/app/content_types - ported OFS.content_types from Z2 to Z3 (which is the most recent maintained code)
On 12/12/05, Janko Hauser [EMAIL PROTECTED] wrote: Is this done on purpose? Or is this implementation meant as a basic one, which will be replaced by something like a filesystem storage or the new zodb-blob support in the upcoming next version? Our intention is to support the ZODB blobs directly in zope.file when that becomes available. The API is designed to make that reasonable. The current implementation is meant to be a low-investment implementation that can be replaced without changing the API when blobs become available, and allow applications to be written now to get all the benefits of using blobs once that is available. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ 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-checkins] SVN: Zope3/trunk/src/zope/app/content_types - ported OFS.content_types from Z2 to Z3 (which is the most recent maintained code)
Am 12.12.2005 um 23:56 schrieb Fred Drake: On 12/12/05, Janko Hauser [EMAIL PROTECTED] wrote: Is this done on purpose? Or is this implementation meant as a basic one, which will be replaced by something like a filesystem storage or the new zodb-blob support in the upcoming next version? Our intention is to support the ZODB blobs directly in zope.file when that becomes available. The API is designed to make that reasonable. The current implementation is meant to be a low-investment implementation that can be replaced without changing the API when blobs become available, and allow applications to be written now to get all the benefits of using blobs once that is available. Thanks for confirmation :-), so I will look more on the API side now. If I may ask one more question how is the setting of cache headers supported by this or possibly another API? with regards, __Janko ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
On Mon, Dec 12, 2005 at 04:53:11PM -0500, Jim Fulton wrote: | I am not 100% sure this is what you had in mind, but basically i've | broke down the 'publish' method from ZPublisher.Publish into the | methods of IPublication, and it seems to have mapped quite well with | some minor exceptions. | | Cool. It should. IPublication was designed by insoecting all | the odd hooks in Zope 2. Yeah, the biggest difference seems to be exception handling from what I can tell. | My only fear so far is that there might be some issues with the | request object itself being not 100% backwards compatible, but I think | we can have backwards compatibility implemented as an adapter from the | Zope 3 request to Zope 2 request. | | Possibly. Note that the request itself is pluggable. Zope 3 has a | notion of request factories. When you set up a particular server, | you can specify which request factory is used. It would be nice though | of Zope 2 and Zope 3 requests could be handled by the same server | (host/port). | | Adaptation may be a good way to start, although arranging for the | adaptation to happen could get interesting. | | It might be better to see if we can come up with a request that provides | both Z2 and Z3 request APIs, if possible and then start a process of | deprecation of features we don't want in the future. This might | be easier and simpler than adaptation. Sounds good to me. By quickly looking Zope 3's requests have mostly the same methods and features from Zope2's. However sems like most methods were renamed for consistency (eg: supports_retry - supportsRetry). The greatest lacking functionality in Zope 3 seems to be the lack of a 'lazy' namespace, which is used primariliy for the 'SESSION' object in Zope 2. How do people feel about adding that to Zope 3? -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
Sidnei da Silva wrote: ... Sounds good to me. By quickly looking Zope 3's requests have mostly the same methods and features from Zope2's. However sems like most methods were renamed for consistency (eg: supports_retry - supportsRetry). There are a number of things I can think of off the top of my head: - getting request-based URLs. For example request/URL/1 vs request/URL1 - Z2's equivalence of item and attribute access :( - Z2's request.__setitem__, other, and a general tendency to try to colapse namespaces. The greatest lacking functionality in Zope 3 seems to be the lack of a 'lazy' namespace, which is used primariliy for the 'SESSION' object in Zope 2. How do people feel about adding that to Zope 3? I'm not familar with this. Where is it documented? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
Sidnei da Silva wrote: On Mon, Dec 12, 2005 at 06:25:53PM -0500, Jim Fulton wrote: | Sidnei da Silva wrote: | ... | Sounds good to me. By quickly looking Zope 3's requests have mostly | the same methods and features from Zope2's. However sems like most | methods were renamed for consistency (eg: supports_retry - | supportsRetry). | | There are a number of things I can think of off the top of my head: | | - getting request-based URLs. For example request/URL/1 vs request/URL1 Uh, Zope 3 has the first I guess? Yup. These should be easy enough to combine. ... | The greatest lacking functionality in Zope 3 seems to be the lack of a | 'lazy' namespace, which is used primariliy for the 'SESSION' object in | Zope 2. How do people feel about adding that to Zope 3? | | I'm not familar with this. Where is it documented? Here's what is in the docstring for HTTPRequest: - Lazy Data These are callables which are deferred until explicitly referenced, at which point they are resolved and stored as application data. Haven't found much else documentation. Are these basically lazy computed request keys/attributes then? There's a 'set_lazy' method in HTTPRequest, and that's what the session machinery uses to bind 'getSessionData' as 'SESSION'. This specific case sucks though, because as 'SESSION' appears when doing request.keys() is pretty common to create sessions implicitly by iterating through the request. Yeah, explicit is better than implicit. I don't want to add this to Z3, but it should be included in the new combined z2/z3 request. We really need to take a look at the combined API and decide what we want in the long run. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Simplify Skinning Redux
On Monday 12 December 2005 16:29, Dominik Huber wrote: 1. The brand *skin* and *layer* are fairly common and they are reflecting two logical uses cases. At a first glance the usage for a layer type is not given, but the layer concept is still interesting to build modular skins. The layer audience could be the developers which like to share layer specific informations. IMO an use case for an Browser Layer Names utility could be a corresponding online-documentation within the api-doc. I would suggest to register the layers like skins using a ILayerBrowserType interface: interface interface=.interfaces.I18NFeatures type=zope.publisher.interfaces.browser.IBrowserLayerType / 2. I liked the naming ISkinType and ILayerType much more (instead of IBrowserSkinType/ IBrowserLayerType), because this browser-specific differentiation is already given by the package hierarchy and those ILongCamelCaseWordingsThatTriesToExplainEverything are hard to type and at the end they confuse newcomers even more than the simple ones. Please keep the naming also simple and stupid like the skinning simplification itself :) Two good points I agree with. I wanted to write a similar response as 1., but did not have a good argument. Dominik just gave it. I think it is important to keep a registry of all layers, especially for TTW development, an area I really want to put some effort in for 3.3. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted Publisher and Zope 2
On Mon, Dec 12, 2005 at 07:14:08PM -0500, Jim Fulton wrote: | Here's what is in the docstring for HTTPRequest: | | - Lazy Data | | These are callables which are deferred until explicitly | referenced, at which point they are resolved and stored as | application data. | | Haven't found much else documentation. | | Are these basically lazy computed request keys/attributes then? Yes. | There's a 'set_lazy' method in HTTPRequest, and that's what the | session machinery uses to bind 'getSessionData' as 'SESSION'. This | specific case sucks though, because as 'SESSION' appears when doing | request.keys() is pretty common to create sessions implicitly by | iterating through the request. | | Yeah, explicit is better than implicit. | | I don't want to add this to Z3, but it should be included in the | new combined z2/z3 request. We really need to take a look at the | combined API and decide what we want in the long run. So we are shooting for a z2 request implemented in terms of a z3 request. Sounds like an adapter to me :) -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] View lookup changes in Zope 3.2?
Today I finally got around to installing Zope 3.2b1 and started testing one of our sites against it. I'm running into a few problems, some of which are my fault, some that I don't quite understand, and one that is really bad. We have been basically rolling a custom CMS in Zope 3, and the content management skin that we made has been working wonderfully in Zope 3.1. One of the key parts of our CMS's user interface is a custom contents view that uses MochiKit for javascript/DOM based table sorting (easy sorting on item name, title, and size), and uses MochiKit's AJAX support for inline renaming/retitling of items in the container. That's registered as 'contents.html' for our own base contentcontainer interface. We've also made a custom metadata view that allows editing of keywords (subjects). In Zope 3.1.0 both of those worked fine. In Zope 3.2b1, I'm getting the Rotterdam or default contents view, wrapped up in our template. The same goes for the custom '@@+' view I've made for the same objects, which is used to filter certain Zope entries out of the add menu. For our container objects, I'm also getting the Zope meta-data view, but on some of our custom content objects I get our replacement view. I use our own menu, 'cms_views', for tabs, and have contents and EditMetaData registered as actions. If I rename my 'contents.html' view to 'contentsplus.html', I can see it fine. Here's my skin setup: from zope.publisher.interfaces.browser import IBrowserRequest from zope.publisher.interfaces.browser import IDefaultBrowserLayer from zope.app.rotterdam import rotterdam class CMS(IBrowserRequest): The `cms` layer. class ContentManagement(CMS, rotterdam, IDefaultBrowserLayer): The Skin configure: layer name=example.cms interface=example.cms.skin.CMS/ skin name=example.cms.ContentManagement interface=example.cms.skin.ContentManagement/ and the contents.html view starts with: view name=contents.html for=example.cms.interfaces.IContentContainer permission=example.cms.ManageContent layer=example.cms.skin.CMS I'm referring to the layer with its interface path in ZCML, always. If I moved 'rotterdam' out of the base interfaces for the ContentManagement skin and set it as the base for the CMS layer object, the same behavior still shows up. This setup works as I expected it to in Zope 3.1, but breaks in Zope 3.2. FWIW, I opened up a debugzope session in both Zope 3.1 and 3.2 in this same configuration just to check the list of providedBy(obj) for the same folder in each site, to see if the interface resolution order might have changed, but the lists appear to be identical. Bug? Or did I do something wrong in my Zope 3.1 implementation that Zope 3.2b1 has fixed? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] publishTraverse method in viewmeta.py
In zope/app/publisher/browser/viewmeta.py, I found the following comment. # This should go away, but noone seems to remember what to do. :-( I don't know what this comment means, but the publishTraverse methods can be rewritten by natural way. Please test this code and include into the original if it works well. replace line 280-304 to the following. def publishTraverse(self, request, name, pages=pages, getattr=getattr): if name in pages: return getattr(self, pages[name]) return super(self.__class__, self).publishTraverse(request, name) replace line 433-437 to the following class simple(BrowserView): implements(IBrowserPublisher) def publishTraverse(self, request, name): view = zapi.queryMultiAdapter((self, request), name=name) if view is not None: return view raise NotFound(self, name, request) Tadashi Matsumoto [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
