[Zope3-dev] Re: [Checkins] SVN: z3c.extfile/ initial import of the z3c.extfile package
On 10 Aug 2006, at 18:28, Bernd Dorn wrote: Log message for revision 69391: initial import of the z3c.extfile package Does this package tie into the transaction manager? I couldn't see any reference to transactions. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: [Checkins] SVN: z3c.extfile/ initial import of the z3c.extfile package
On 10 Aug 2006, at 19:39, Bernd Dorn wrote: On 10.08.2006, at 19:09, Florent Guillaume wrote: On 10 Aug 2006, at 18:28, Bernd Dorn wrote: initial import of the z3c.extfile package Does this package tie into the transaction manager? I couldn't see any reference to transactions. short answer - no files are stored based on their sha digest, so it does not matter if the transaction fails after the file is saved, because we do not have to delete it immediatly. concurrency is also possible, because when the file is commited, it is moved to its final location, if another process uploads the same file and the same file exists (hash), it gets silently deleted, because a file only has to exist one time on the system. i plan to implement some kind of pack mechanism, which searches for such properties in the zodb and then deletes all files which are not used anymore IMHO it would be better and more efficient to register a data manger with the transaction when a file operation is done, and cleanup when the transaction commits/aborts. But then I'm not the one coding this :) Flornet -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: OT: pytz
Stuart Bishop wrote: Ignas Mikalajunas wrote: Thanks. I'd seen localize() in the README but all the examples have an explicit is_dst passed which I didn't want. I didn't realize that without it it would guess the right one (except during the 1h ambiguous period). Florent The is_dst parameter is more like If it is ambiguous prefer DST, even when calling localize without passing the parameter it will not do any guessing as is_dst is set to False by default. If you want localize to warn you about ambiguous time you should pass is_dst=None which will raise an exception instead of assuming that you prefer non DST times in ambiguous cases, I've been wondering if making pytz work like this was a correct decision. It seems that people who know enough to care about DST transition periods generally work in UTC anyway What makes you say that? Any application where datetimes are user-entered and user-visible will certainly *not* want to store them in UTC, as users will want dates displayed as they were entered (meaning holding their original timezone, even if the timezone is not displayed). If my French user say this expires 15 aug 2006 at 16:00 I want them to see 15/08/2006 16:00 in the document metadata, even though it's stored as 2006-08-15T16:00:00+0200. If the document is exported to another system, I want the timezone kept. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: OT: pytz
Marius Gedminas wrote:
On Mon, Jul 24, 2006 at 01:08:39AM +0200, Florent Guillaume wrote:
Sorry about the offtopic, but can anyone shed some light on this:
import pytz
from datetime import datetime
tz = pytz.timezone('Europe/Paris'); print datetime(2006, 7, 1,
tzinfo=tz).utcoffset()
0:09:00
I expected 1 hour, not 9 minutes???
Read pytz/README.txt. You're not supposed to pass tzinfo to datetime.
You're supposed to write
tz = pytz.timezone('Europe/Paris')
print tz.localize(datetime(2006, 7, 1))
2:00:00
As you can see, in summer the offset is 2 hours due to daylight savings.
Thanks. I'd seen localize() in the README but all the examples have an
explicit is_dst passed which I didn't want. I didn't realize that
without it it would guess the right one (except during the 1h ambiguous
period).
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: zope.testing/branches/stub-testSetUp_in_layer/src/zope/testing/testrunner Implement layer.testSetUp and layer.testTearDown support
Stuart Bishop wrote: Log message for revision 68689: +def testSetUp(self): +A layer may define a setup method to be called before each +individual test. + +for layer in reversed(self.layers): +if hasattr(layer, 'testSetUp'): +layer.testSetUp() Ah cool, pretty useful thanks. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/branches/3.3/ - fix for issue 517: intid might generate long instead of int which conflicts with btrees
Christian Theune wrote: Log message for revision 68700: --- Zope3/branches/3.3/src/zope/app/intid/__init__.py 2006-06-17 03:29:43 UTC (rev 68699) +++ Zope3/branches/3.3/src/zope/app/intid/__init__.py 2006-06-17 04:10:29 UTC (rev 68700) @@ -47,7 +47,10 @@ implements(IIntIds) -_v_nextid = None +_v_nextid = None + +# Used for testability of random function +__randint__ = random.randint You should avoid such __names__, they are supposed to be reserved. Here, __randint would have been quite enough I believe. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: IEndRequestEvent question
Thierry FLORAC wrote: On Tue, 2006-06-06 at 13:32 +0200, Philipp von Weitershausen wrote: My goal is to use request annotations to reference several objects that should be treated after the main request process is done, and then to subscribe to this event to fire these final modifications (so that, for example, IObjectModifiedEvent is not fired too many times). Is it the good approach ? Why are you concerned about IObjectModifiedEvent being fired too many times? Thanks for your previous explanations : it's clear in my mind, now ! My first idea with this problem was to say : a content object can be modified several times during a request execution, sometimes by other content objects and not only by simple editing forms (which automatically fire IObjectModifiedEvent), and I want some kind of expensive application logic (for example, reindexing) to be applied only once, when all modifications are done. So the IEndRequestEvent was, to me, a good place to handle this kind of methods ; but your previous explanation show that I was wrong. I also thought about using some kind of request annotations or volatile attributes, but as event handlers are fired synchronously, I thing that I can't know if there are more modifications to come before the end of the request or not. In fact, I thing that what I should need is a kind of IBeforeEndRequestEvent, an event which would be fired before the end of the request, but when transactions and local utilities are still available... Of course, any kind of complement would as always be very welcome... You could use another publication object that subclasses the afterCall() method (the original one is in zope.app.publication.zopepublication, and is where the transaction is committed). But the base one should really send an event there. How about adding a IAfterCall publication event? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: TALES PathExpr doesn't call old style classes
Philipp von Weitershausen wrote: Hi there, I've filed an issue in the collector outlining a problem with old style classes and TALES traversal: http://www.zope.org/Collectors/Zope3-dev/635 In particular, I'm looking for comments on problem #2. Well, following the mantra of explicit is better than implicit I'd rather have ZPT never call things magically, but I know that's not the problem at hand and it poses backward compat problems anyway... Too bad though. For #2 I'd just do a check that type(C) is classobj, even though this doesn't take care of proxied old-style classes (who uses those anyway?). BTW your comment in the patch about getattr(ob, '__call__', _marker) triggering acquisition isn't really true, as attributes starting with '_' are never looked up by an implicit acquisition wrapper (although you can still ask for them explicitely by using aq_acquire). Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: TALES PathExpr doesn't call old style classes
On 25 May 2006, at 00:38, Philipp von Weitershausen wrote: just to get this straight: I'm not going to discuss in this thread what changes we might do to TALES in the future. I'm strictly concerned about this release cycle, not a future one. That doesn't I won't be interested in discussing these matters in the future... Are there really usecases where something can go wrong if we use the proposed PEP? Calling something that may or may not be callable can yield at least two different exceptions: TypeError or AttributeError (on __call__). That means we'd already have to catch two pretty common exceptions and therefore eat exceptions that might occur inside the called routine. This would make debugging very hard. It also isn't mentioned in the spec currently that TypeErrors and AttributeErrors would be eaten silently, so we'd really be changing the behaviour. There *is* a way to check whether the error resulted from the current frame or a lower frame. Introspections like these have the tendency to be or become hacks, but then again, we use frame inspections in other places, too. Yes, I was about to suggest using the standard PJE trick used elsewhere in Zope 3 (to check for deep ImportErrors), namely: try: ob() except (TypeError, AttributeError): if sys.exce_info()[2].tb_next is not None: raise # here we know the exception was not deep # so the object isn't callable Florent If no one objects, I will fix Zope 3's PathExpr to check for a __call__ method using getattr() (as documented in the collector issue, http://www.zope.org/Collectors/Zope3-dev/635) and additionally check whether the object might be an old style class, as suggested by Florent. We will have to result to different measures in Zope 2 anyways, for BBB reasons. Philipp -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: __contains__ and acquisition problem?
Jim, as the author of the Acquisition classes, could you comment on this? Thanks, Florent Florent Guillaume wrote: Could anybody shed some light on what's happening here: from Acquisition import Implicit class Impl(Implicit): ... pass class C(Implicit): ... def __getitem__(self, key): ... print 'getitem', key ... if key == 4: ... raise IndexError ... return key ... def __contains__(self, key): ... print 'contains', repr(key) ... return key == 5 The class by itself behaves as expected: c = C() 5 in c contains 5 True 3 in c contains 3 False Let's put c in the context of i: i = Impl() i.c = c Now why is the following happening? Why is __contains__ not used? 3 in i.c # c.__of__(i) getitem 0 getitem 1 getitem 2 getitem 3 True 5 in i.c getitem 0 getitem 1 getitem 2 getitem 3 getitem 4 False -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: __contains__ and acquisition problem?
On 19 May 2006, at 15:36, Jim Fulton wrote: Florent Guillaume wrote: Jim, as the author of the Acquisition classes, could you comment on this? Uh, sure. What does this have to do with Zope 3? Well, I couldn't find a better list :) Anyway, the acquisition wrapper implementation hasn't been updated to handle many slots that were added in recent years, including __contains__. Ok, thanks. Florent Could anybody shed some light on what's happening here: from Acquisition import Implicit class Impl(Implicit): ... pass class C(Implicit): ... def __getitem__(self, key): ... print 'getitem', key ... if key == 4: ... raise IndexError ... return key ... def __contains__(self, key): ... print 'contains', repr(key) ... return key == 5 The class by itself behaves as expected: c = C() 5 in c contains 5 True 3 in c contains 3 False Let's put c in the context of i: i = Impl() i.c = c Now why is the following happening? Why is __contains__ not used? 3 in i.c # c.__of__(i) getitem 0 getitem 1 getitem 2 getitem 3 True 5 in i.c getitem 0 getitem 1 getitem 2 getitem 3 getitem 4 False -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] __contains__ and acquisition problem?
Could anybody shed some light on what's happening here: from Acquisition import Implicit class Impl(Implicit): ... pass class C(Implicit): ... def __getitem__(self, key): ... print 'getitem', key ... if key == 4: ... raise IndexError ... return key ... def __contains__(self, key): ... print 'contains', repr(key) ... return key == 5 The class by itself behaves as expected: c = C() 5 in c contains 5 True 3 in c contains 3 False Let's put c in the context of i: i = Impl() i.c = c Now why is the following happening? Why is __contains__ not used? 3 in i.c # c.__of__(i) getitem 0 getitem 1 getitem 2 getitem 3 True 5 in i.c getitem 0 getitem 1 getitem 2 getitem 3 getitem 4 False -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/trunk/src/zope/wfmc/ Preparations for persistent WFMC,
Adam Groszer wrote: Log message for revision 67734: Preparations for persistent WFMC, as discussed at the SwissSprint Changed: U Zope3/trunk/src/zope/wfmc/process.py U Zope3/trunk/src/zope/wfmc/xpdl.py Hi Adam, Please keep in mind that discussion at a sprint does not replace discussion in the list, and that changes to Zope need to follow a proposal-based model. Could you detail what your plan is? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Reminder: Feature Freeze May 1
Jim Fulton wrote: Don't forget that the feature freeze for the June release is May 1! That is only 10 days away! New features should be check in in a *stable* form by then. While we won't necessarily do a beta release then, anything checked in for the new release must be ready for a beta release when it is checked into the trunk. What's the ETA for merging the various branches? Yours in Z3, Phil's in Z2, maybe Five... ? I'd rather have them sooner than later. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Update: The browser:page compromise
Philipp von Weitershausen wrote: If people don't like the 'browser2' prefix, I'm open to other suggestions. For all I care, the three directives I suggested could be on the 'browser' namespace, only browser2:page and browser:page clash. So perhaps browser2:page should be named something else. I can't seem to come up with good alternatives, though. I haven't looked closely, but can't we have one browser:page whose behaviour changes according to what attributes it has? If old attributes are provided, a deprecation message is sent but the old code is used. Otherwise the new behaviour is in effect. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Update: The browser:page compromise
Philipp von Weitershausen wrote: Thanks to everyone who commented on the first versions of this proposal. People seem to object changing the old directives. I respect that. I've therefore changed the proposal to introduce *new* directives. See http://dev.zope.org/Zope3/TheBrowserPageCompromise once again. If this will be the recommended way of doing things, I'd hate to have a browser2 forever or even for the next year. This is just ugly. I'd prefer to user either a clean new prefix, or a new name in the browser namespace, for example browser:publish. Note that I'm not mentioning deprecation of the old directives which doesn't mean I want to do it. Here is a poll: * Should the old directives be deprecated? (I think so) Yes. * When should that happen? (I'd say now, meaning Zope 3.3) ASAP. Dynamic class generation sucks. * When should they disappear? (I'd say in Zope 3.5) 1 year after deprecation as usual. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] container preconditions inheritance
If I have a container interface IFoo with a __setitem__.precondition, and if IFoo inherits from IBar that also has one, shouldn't the inherited precondition also be checked by zope.app.container.constraints.checkObject? I don't see that in checkObject's code.. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: eggifying zc.resourcelibrary, zc.table and others
Tres Seaver wrote: * the setup.py I'll create will only work with setuptools installed; is this a problem? Not from us. You'd maybe get even more warm fuzzies from people by making it not require setuptools, but that limitation doesn't bother us. Okay, good. Warm fuzzies are nice, but I won't worry too much about that. There is some support for kickstarting an eggifying project. E.g.: $ export ZSVN=svn+ssh://svn.zope.org/repos/main $ svn cp -m Eggify $ZSVN/productsupport/trunk/project-template \ $ZSVN/zope.foopackage Note that such a svn cp will make it quite painful to dump the repository later on using svadmin dump and then filtering the dump using svndumpfilter to keep only this package. (We've been bitten by that.) I'd suggest doing instead a svn export of the project-template, then svn import as your new package. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Doctests for IObjectModifiedEvent
Sorry, I was on vacation. Without a traceback I'm not sure what you really mean. Anyway Stefan already answered. You should also read http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ 2005_11_10_object-event-dispatching to get an understanding of how event dispatching works. Florent On 8 Mar 2006, at 21:18, Egon Frerich wrote: Hello, I want to have doctests which document the correctness of an handler for an IObjectModifiedEvent. But the 'notify' triggers a TypeError, because the handler 'takes exactly 2 arguments (1 given)'. Two arguments are correct. I have searched the tests in zope.app.event. The Doctests do notify but I don't see any handler for IObjectModifiedEvent (and a proof the handler does it right). Egon -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
Benji York wrote: Gary Poster wrote: What if we still deprecated browser:layer but kept a redefined version of browser:skin? Then your zcml-- interface interface=.interfaces.ShanghaiSkin type=zope.publisher.interfaces.browser.IBrowserSkinType / utility component=.interfaces.ShanghaiSkin provides=zope.publisher.interfaces.browser.IBrowserSkinType name=ShanghaiSkin / could become browser:skin component=.interfaces.ShanghaiSkin name=ShanghaiSkin / Even though it's longer, I still like the interface/utility version. I think it really helps the developer understand what's going on and that it's not magic. The decreased brevity is of secondary concern to me. Helping the developer understand what's happening is laudable, but that's ultimately the job of documentation. When line count reduction is as drastic as the above, I really don't have a problem with having shortcut ZCML directives. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
Philipp von Weitershausen wrote: Yet again looking for comments, this time at: http://dev.zope.org/Zope3/OneNamespaceForZCML. Let me add my -1 to this. I'm all for reducing the number of namespaces in the standard directives, and reducing the number of directives too, but getting rid of namespaces, as others have pointed out, removes clean ways of extending ZCML for third-party frameworks. For example CPS currently has a cps:upgradeStep directive: cps:upgradeStep title=Upgrade catalog from Zope 2.7 handler=.upgrade.upgrade_catalog_Z28 checker=.upgrade.check_upgrade_catalog_Z28 sortkey=-10 / cps:upgradeStep title=Clean catalog of broken objects source=3.3.4 destination=3.3.5 handler=.upgrade.upgrade_334_335_clean_catalog / Now you could have a CpsUpgradeStep directive, but I hope everyone agrees that prefixing names is a poor man's way of doing namespaces. You could also maybe provide the same info using two or three other standard directives, but that would be very inconvenient. Maybe a simple zope 3 component doesn't need to provide extensions to ZCML using a namespace, but any *framwework* on top of it will quickly need them. Finally -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Deploying WSGI Apps with Zope 3.2+
Sidnei da Silva wrote: On Thu, Jan 26, 2006 at 06:30:02AM -0500, Jim Fulton wrote: | Sidnei da Silva wrote: | On Wed, Jan 25, 2006 at 05:28:14PM -0500, Jim Fulton wrote: | | There are a bunch of issues to be resolved, like the fact that it's | | not possible to access the initial ZConfig options object because it's | | thrown away, so, in order of priority: | | | | 1. It's not possible to find where the INSTANCE_HOME is. | | | | Why is this necessary? | | So the config file for paste.deploy can be in INSTANCE_HOME/etc/paste.ini | | Hm. I don't have the time to think hard about this right now, | but I suspect the model you are following isn't quite right. Rather than | implicitly looking for a paste file in a magic location, I suspect that you | should name the paste file in your ZConfig file or possibly extend the | ZConfig | schema with components that reproduce what's normally found in a paste | config | file (app definitions, server definitions, etc.). Of course, either of | these | options requires updating the ZConfig schema which is a real pain, so I can | understand why you wouldn't want to do that. And you're right to the point. My original intention was to put the config file location in the ZConfig schema, but that's *wy* too painful right now. I thought Tres had added to ZConfig the possibility to have arbitrary key/values for arbitrary additional products. Or was this only in the context of Zope 2 ? Florent OTOH, it does seem to work pretty reasonably right now to serve as a prototype. I have other concerns than if the config file location is magic or not at the moment. I mean, it's probably better that it's hardcoded to 'INSTANCE/etc/paste.ini' than configurable at this point. I don't think one would need *more than one* paste.deploy configuration file anyway, so changing it's name would be pretty pointless. I think we can slowly progress from here, solving the ZConfig problem, then the server-type-always-takes-db-argument and eventually end up with zope.paste in the main tree and having the default wsgi server be configured using paste.deploy. BTW, I've updated the README.txt to include a more extensive description of how to use it right now: http://svn.zope.org/zope.paste/trunk/README.txt?rev=41449view=markup Thoughts? -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: ZConfig and other formats for ZCML
Dieter Maurer wrote: What I like with ZConfig is its schemas and especially the ability to define datatypes. I hope that similar things can be achieved with ZCML. Of course it can, ZCML is defined in terms of Zope 3 schemas. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: ZConfig and other formats for ZCML
Sidnei da Silva wrote: On Mon, Jan 23, 2006 at 04:26:05PM +0100, Lennart Regebro wrote: | | But | | yadayada | xmas hohoho | easter bunny | /yadayada | | Where is the logic in that format? It starts out looking like | somethingML, but then isn't. I suspect ZConfig was designed after the apache config format. I also suspect you haven't configured much Apache yourself. Heh, I have always found apache's format quite braindead. I'm not even speaking of the semantics... Why they didn't switch to pure XML with the move to Apache 2.0 still eludes me. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: small proposal: a monitor api on live requests
Tarek Ziadé wrote: Solution Add somewhere a table that keeps infos about all live requests, like: - the current state: receiving | processing - additional infos: receiving - amount to receive / amount received processing - what's beeing done (_last_obj_traversed, etc..) and a few apis to get these infos this could be hooked in the publisher's request classes in `processInputs()`, where we get the stream from twisted IIRC That's interesting, assuming we can put the right hooks in place. Risks Could slow down the publisher There's another risk to take into account: security. You'll have to find a way for the server to make sure it doesn't divulge sensitive information to the second thread querying it. The server should only give information to the second thread about any other thread that is trusted with that information. One way to ensure this would be to have some token passed by the first thread to the server that would also have to be presented by the second thread, if it wants info back. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: full closure of group membership
Gary Poster wrote: Primary problem: We frequently want to know the full closure of group membership. The groups attribute of zope.security.interfaces.IGroupAwarePrincipal is a list of groups to which the principal directly belongs. The full closure--including the groups to which the principal's groups belong, for instance--must be calculated by any piece of code that needs it. Secondary problem: The description of zope.security.interfaces.IGroupAwarePrincipal.groups does not sufficiently clarify that it is *not* a full closure. Consideration: zope.security.interfaces.IGroupAwarePrincipal has been around for awhile, and probably should not be materially changed (i.e., to redefine or add an attribute). Solution: 1) Clarify the zope.security.interfaces.IGroupAwarePrincipal.groups description: change from List of ids of groups the principal belongs to to List of ids of groups to which the principal directly belongs 2) Add an additional interface to zope.security.interfaces interface. class IGroupClosureAwarePrincipal(IGroupAwarePrincipal): allGroups = interface.Attribute( 'a readonly iterable of the full closure of the principal's groups.') 3) Make the principals in zope.app.authentication implement IGroupClosureAwarePrincipal. First cut of 'allGroups' would probably be to make it be a lazy property, returning a tuple of the full closure. Risks: Some might be unhappy that allGroups is not a hook point, but a convenience: that is, it will be a full closure, not an opportunity to be clever to redefine how group membership is calculated. +1, a long time ago I suggested something similar because in the CPS framework of groups we need knowledge both of direct membership and transitive closure (we have a getGroups method that's the direct groups, and a getComputedGroups that's the transitive closure and is used for instance when we have groups of groups). I'm still not using the zope 3 principal framework but at some point I know I'll need it in zope 3 too :) Do you think your interfaces fit the need of computed groups? I'm not sure if the meaning of computed is clear but I can expand on that if it's not (for instance, it could be for the case where groups exist dynamically according to some computation on the prinicpal's properties). Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mini-proposal: zope.app.authentication group events
Gary Poster wrote:
On Jan 12, 2006, at 2:11 PM, Gary Poster wrote:
def IPrincipalAddedToGroup(interface.Inteface):
group = interface.Attribute('the group to which the principal was
added')
principal = interface.Attribute('the principal added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group = interface.Attribute('the group from which the principal
was removed')
principal = interface.Attribute('the principal removed')
Small change: clarify that these are ids, and allow multiple principals
to be specified.
def IPrincipalAddedToGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group to which the
principal was added')
principal_ids = interface.Attribute('an iterable of one or more ids
of principals added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group from which the
principal was removed')
principal_ids = interface.Attribute('an iterable of one or more ids
of principals removed')
+1
But why the ids and not the objects themselves? Wouldn't it allow for
more flexibility?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mini-proposal: member-aware group interface
Gary Poster wrote:
Problem:
We need to be able to iterate over the members of a group, given a
group id. With the interfaces in zope.security, the only way to do
this is to iterate over all principals known to the system, check their
`groups` attribute, and if the group id is in the list then include
it. This is obviously problematic.
If we constrain ourselves to the pluggable authentication utility in
zope.app.authentication, we have some help, but it is pretty
inconvenient and conceivably problematic. The following (untested
sketch of a) approach is a good try for the common case, but won't
handle nested authentication utilities, and relies on an interface not
in an interfaces.py:
from zope import component
from zope.app.authentication import interfaces
import zope.app.authentication.groupfolder
group_id = 'foo'
auth = component.getUtility(interfaces.IPluggableAuthentication)
for name in auth.authenticatorPlugins:
plugin = component.queryUtility(
interfaces.IAuthenticatorPlugin, name, context=auth)
if zope.app.authentication.groupfolder.IGroupFolder.providedBy
(plugin):
try:
principals = plugin.getPrincipalsForGroup(group_id)
except KeyError:
pass
else:
break
else:
raise RuntimeError('Not Found')
Or something like that. As I said, this doesn't even handle some of
the more complex cases. Whew!
Solution:
Add a new interface to zope.security.interfaces:
class IMemberAwareGroup(IGroup):
members = interface.Attribute('an iterable of members of the group')
Then make the groups that the zope.app.authentication.groupfolder
plugin generates implement the new interface.
I think I'm for it, but in some cases even though groups may be able to
list all their members it may (if they're dynamically computed) turn out
to be a huge list. I guess in that case you could simply not advertise
that the group implements the interface.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] testrunner layers
On 21 Dec 2005, at 16:04, Jim Fulton wrote: Florent Guillaume wrote: I didn't find the info I was looking for in the unit tests and docs for the testrunner: How are layers defined? This is definately a hole in the testrunner docs. Are they just a class with a setUp and tearDown classmethod? Is it enough to provide a layer attribute in the layer class? A layer attribute is not part of the api for layers. Is there a use of a 'base' attribute or is it just the unit tests for the testrunners that have it (they are full of # Internal to samples. Not part of layer API so it's hard to know). Layers are objects with setUp and tearDown methods and __bases__, __module__, and __name__ attributes. Classes with class methods are a common and convenient implementation approach. In addition, a layer's tearDown method is allowed to raise NotImplementedError to indicate that the layer doesn't support tear down. This is actually documented in testrunner-layers-ntd.txt. It is also a requirement that layers must be available for import using their __module__ and __name__. The __bases__ attribute indicates that a layer builds on other layers. In that case, the base layers will be setUp before the layer and torn down after the layer (assuming that the layer and base layers support tear down.) How does a test class reference a layer? Just by setting the layer attribute to the dotted name of the class? Or to the class itself? A test or test suite indicates it's layer through it's layer attribute, which must be either the dotted name of a layer or the layer itself. Along what algorithm does the --layer directive match layers? Is it an exact match, or a substring? A prefix? How does the base come into play? A regular expression match is used. This is documented in the testrunner-layers.txt file, although that documentation doesn't make clear whether a regular expression or substring match is used. The options help does say that this is a regular expression. Also, what's the intent behind no-tearDown layers? To support layers that can't be torn down. :) Most notably, changes made by ZCML can't be torn down. See the layer defined in zope.app.functional for an example of a ZCML-defined layer. Contributions to the documentation would be welcome. In particular: - The command line help should provide a pointer to the text files. A lot of people haven't realized that there was extensive documentation for the test runner. (We should also apidoc bookify these files.) - We need a chapter on writing layers. - It would be good to clarify, where necessary in the text when regular expressions are used. I won't have time to do this myself this year. Thanks. I'll write some doc when I get the hang of using layers (not this year either :)). Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Certification: SupportingResidual InformationProtection in Zope 3
Tres Seaver wrote: A fairly drastic one, unfortunately -- catalog all role and permission assignments and run a query as soon a user is removed. CMF does this for local roles, and Jim is already on record as disliking it. I am pleased with the *result*, which also allows the catalog to filter normal content results efficiently based on the user's roles (the original eason for the index). OTOH, the *implementation* is grotty. FYI in addition to the CMF 'allowedRolesAndUsers' index that Tres is alluding to her, in CPS we added an index 'localUsersWithRoles' exactly for the use case of being able to find quickly where someone (or some group) has a local role, to be able to remove it. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: rdb: Disappearing Connection
Jim Washington wrote: Spelunking a bit in the code, zope.app.rdb.ZopeDatabaseAdapter.isConnected() looks at whether _v_connection is present, not whether the connection is actually alive. If we fix this here, isConnected() perhaps should handle the case where the connection might be reaped by the back end db. Frankly anything that uses _v_ attributes is asking for trouble because it relies on low level behaviour of the ZODB and persistence mechanisms. They can disappear at unpredictable times. Avoid them. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: undeprecate auto-message id translation
Martijn Faassen wrote: Current (deprecated) behavior of Zope 3 If a message id is defined in python, such as _(Foo), it gets translated by the page template engine automatically when it enters through a tal:content, tal:replace, or tal:attributes. No i18n:translate is needed. [...] My proposal is to recommend the use of i18n:translate for ZPT translation only, and let the ZPT engine automatically translate messages when they come from Python. +1. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: undeprecate auto-message id translation
Martijn Faassen wrote: Zope 2.8 *is* actually interpolating and translating message ids correctly *without* i18n:translate already. I think that this is the same as Zope 3's (deprecated) behavior. The problem is when 'structure' is used in TALES. If this isn't used, translations happen normally. If it is used, translations suddenly break, as do_insertStructure_tal is used instead of do_insertText_tal. I can see that this makes sense if you structure in large pieces of HTML -- they won't have translations. It does however break a usecase where your message ids contain HTML. This isn't really clean, but very handy for translators sometimes, especially if they want to use HTML entities and the like. You can then use i18n:translate= explicitly on the structure, which will cause the *string* to be translated, without interpolation happening. This put me on the wrong track initially, not realizing the impact of 'structure' on the functioning of the TAL interpreter. I agree that the use case of having translations containing HTML is important, and thus that we'll have to make sure do_insertStructure_tal also does correct interpolation when faced with a MessageID. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Ajax in Zope 3
Tarek Ziadé wrote: Hi all, Some UI works have been done lately around and in Zope 3. I am thinking about the work that has been done at Neckar sprint (Zope3.org website, Viewlets, etc..), and on projects like CPSSkins for Z3 at ECM. I am planning to work on UI things as well, and on Ajax things in particular, both for Zope 2 and Zope 3 applications, and trying to choose the right Javascript toolkit for this. 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. This would allow developers to start some js things today under Z2/Five and port them. This would also probably lead into a Z3 way to do ajax and javascript things. What people think ? 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. Myself I absolutely love the approach taken by CrackAjax (http://www.aminus.org/blogs/index.php/phunt/2005/10/06/subway_s_new_ajax_framework) I'm sure lots could be improved like improving python-javascript translation, allowing for explicit javascript when really needed, improving the testability, etc. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.configuration and ImportErrors
Florent Guillaume wrote:
Today it's very hard to debug ImportErrors raise inside modules
referenced through a zcml directive, because the ImportError is
swallowed an no traceback comes back to the user. Just a
ConfigurationError: ('Invalid value for', 'class', Couldn't import
some.class, cannot import name somename)
which doesn't point anywhere useful.
I'd like to modify zope.configuration.config to something like:
try:
mod = __import__(mname, *_import_chickens)
except ImportError, v:
+if sys.exc_info()[2].tb_next is not None:
+# ImportError was caused deeper
+raise
raise ConfigurationError, (
Couldn't import %s, %s % (mname, v)
), sys.exc_info()[2]
Instead of the simpler code that was there (this nice trick is by PJE,
and is used ).
Done: http://svn.zope.org/?rev=40527view=rev
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.configuration and ImportErrors
Rocky Burt wrote:
Today it's very hard to debug ImportErrors raise inside modules
referenced through a zcml directive, because the ImportError is
swallowed an no traceback comes back to the user. Just a
ConfigurationError: ('Invalid value for', 'class', Couldn't import
some.class, cannot import name somename)
which doesn't point anywhere useful.
I'd like to modify zope.configuration.config to something like:
try:
mod = __import__(mname, *_import_chickens)
except ImportError, v:
+if sys.exc_info()[2].tb_next is not None:
+# ImportError was caused deeper
+raise
raise ConfigurationError, (
Couldn't import %s, %s % (mname, v)
), sys.exc_info()[2]
+1 for any fix.
+1 for this fix :)
Ok I'll try to check this in during the weekend.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ObjectMover events
Florent Guillaume wrote: I dont' know if this affect the events itself but there is also a problem in the ObjectMover. If you use the ObjectMover from copypastemove on IDependable (registered) objects, it's not possible to move a object because of the order the move process is implemented. --- target[new_name] = obj del container[orig_name] Doh. I hadn't looked at that code. if the ObjectAdded Event will add a dependency to the object we can't delete them in the container. If this should be fixed, I'm not sure if the ObjectMover should copy dependable objects, then the order should be: --- del container[orig_name] target[new_name] = obj This means the events order in this usecase looks like: IObjectRemovedEvent IObjectAddedEvent IObjectMovedEvent Where the IObjectMovedEvent notifies about the sucessful move. Anyway, add a object to a container where is at the same time in a second container is a bad idea in my point of view. I think ObjectMover doesn't care about events but it should. It should do whatever is necessary so that only one IObjectMovedEvent is generated. I'll look at that. Actually the ObjectMover code is correct, it doesn't send the events you say it sends. I added a test for this: http://svn.zope.org/?rev=40445view=rev Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Contained events interface inheritance order
On 30 Nov 2005, at 20:20, Tres Seaver wrote: Florent Guillaume wrote: On 30 Nov 2005, at 17:04, Jim Fulton wrote: Florent Guillaume wrote: On 30 Nov 2005, at 13:17, Jim Fulton wrote: (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) This is the delsp parameter of rfc3676, which apparently only Apple Mail implements, I've no idea why the other mailers haven't followed suit. Perhaps because it is really annoying? Only because Mozilla doesn't implement that RFC :-). Otherwise you'd be able to see perfectly wrapped messages and non-broken URLs. I don't think RFC 3676 intends to wrap URLs; it is about signalling soft line breaks, which aren't normally found within tokens: - From http://www.faqs.org/rfcs/rfc3676.html, section 4.2 Regardless of which technique is used, a generating agent SHOULD NOT insert a space in an unnatural location, such as into a word (a sequence of printable characters, not containing spaces, in a language/coded character set in which spaces are common). If faced with such a word which exceeds 78 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the 78-character limit on line length. Well I don't want to appear to defend Apple Mail too much here, but splitting a URL after a / can be seen as a natural location. And in any case this wouldn't be a problem if Mozilla coders weren't lazy :-) (decoding rfc3676 (which is nearly 2 years old now) is trivial when you already do rfc2646 (format=flowed)) Or just buy a Mac ;) Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Apple's mailer is annoying ( was Re: [Zope3-dev] Contained events interface inheritance order)
On 30 Nov 2005, at 21:03, Jim Fulton wrote: Florent Guillaume wrote: On 30 Nov 2005, at 17:04, Jim Fulton wrote: Florent Guillaume wrote: On 30 Nov 2005, at 13:17, Jim Fulton wrote: (Is there some reason for the urls you give to have spaces in them? It makes them harder to follow. It appears that this is a mac thing. It's rather annoying.) This is the delsp parameter of rfc3676, which apparently only Apple Mail implements, I've no idea why the other mailers haven't followed suit. Perhaps because it is really annoying? Only because Mozilla doesn't implement that RFC :-). Otherwise you'd be able to see perfectly wrapped messages and non-broken URLs. I don't see how. Here's an excerpt of the raw source of your message: From the archives I can find this was decided after: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ SimplifyObjectLifecycleAndLocationEvents but without motivation for this part. I'm still looking for the There is no way for my mail client to know that http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/; and SimplifyObjectLifecycleAndLocationEvents should be clued together. URLs often end in /s. Implicitly joining text following a / is fairly likely to lead to invalif URLs. Actually in the raw source there's a space after the / and before the CRLF. When delsp=Yes (which is the case in the original headers Apple Mail sends), and when the line is deemed flowed (which is the case here because the line ends with a space), the lines should be joined and one space character removed. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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
Hi, On 29 Nov 2005, at 08:27, Dominik Huber wrote: Florent Guillaume wrote: Excuse my insistence, but the only thing I *added* was a modification event when you reorder the children of an ordered container. Before attacking it, please undestand what I checked in. Excuse the confusion of my mail. I was to tired yesterday. I try it another time :) zope.app.container.contained.py, line 594 def setitem(container, setitemf, name, object): ... if event: notify(event) notifyContainerModified(container) But Dominik, before my modification, the code was: if event: notify(event) modified(container) Where `modified` is defined in zope.app.event.objectevent and does: def modified(object, *descriptions): notify(ObjectModifiedEvent(object, *descriptions)) So I didn't introduce a redundant event, it's always been there. This method is called every time when an item is set to a container. Isn't it? Therefore additionally to the object moved resp. object added event newly an container modified event is notified. The second notification is kind of redundant information to the framework, because we can get all the information from the first event. The only problem - and there I'm with you - is that the subscription for handlers that applies to the container itself is cumbersome (- Use case A, for example modification handlers for containers). The solution you have choosen to solve use case A brings two disadvantages to my applications: 1. I'm not able to make batchwise additions to a container and notify afterward a single modification event of the container anymore (Anology: Modification event within the form framework are notified by views (adapters) - The model itself notifies never an modification, because those events would be to granular (an event for each edited attribute) 2. For complex event proceeding of components I sometimes use a single handler that is registered to different events. This brings the advantage that you can bundle event-specific code within one handler (omit redundant and distributed logic - more understandable). Now the disadvantage is that those handlers get invoked twice during the same logical transaction (once by moved event and right afterward by the modified event). This additional event is cluttering, because once the container modified event is notified to handle an additional container state (- Use case B, for example ordered containers) and once a only state that is already covered by the moved event. The container modified event covers two use cases (A and B), but is not able to model them semantically. These are two very valid use cases, and I believe they are answered by pre-setting __parent__ and __name__ on the object before adding/ moving/removing it -- again, code I didn't introduce. Please read the docstring for containedEvent() and uncontained(). Florent Other solution would be... Use Case A:... to dispatch the moved event using a similar mechanism like dispatchToSublocations-handler (- dispatchToParentHandler) without notifying a second modified event. Use Cas B: as you proposed or modification descriptors Mixture Use Case A and B: We could use modification descriptors to stuff the semantical lack of the container modified event, but then... ;) I think I understand your intention. The only thing I realy defend is the fact that we should not implement different approaches (models of a containment hierarchy) using the same events, because we have no change to differ those point of views within our event handlers. Therefore it is very important that we notify only one event (IObjectModifiedEvent.isOrExtends (event)), because we don't have a chance to check for redundant event informations that affects different logical systems. I'm realy tired of this hick-hack-thread. IMO the correct way would be a proposal for such a fundamental change. I'm always for a good dicussion thread when things have to be explained. But here I think there's a big misunderstanding. I hope I could lighten the msiunderstanding a little bit. Regards, Dominik dominik.huber.vcf -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.configuration and ImportErrors
Today it's very hard to debug ImportErrors raise inside modules
referenced through a zcml directive, because the ImportError is
swallowed an no traceback comes back to the user. Just a
ConfigurationError: ('Invalid value for', 'class', Couldn't
import some.class, cannot import name somename)
which doesn't point anywhere useful.
I'd like to modify zope.configuration.config to something like:
try:
mod = __import__(mname, *_import_chickens)
except ImportError, v:
+if sys.exc_info()[2].tb_next is not None:
+# ImportError was caused deeper
+raise
raise ConfigurationError, (
Couldn't import %s, %s % (mname, v)
), sys.exc_info()[2]
Instead of the simpler code that was there (this nice trick is by
PJE, and is used ).
Also I need to fix zope.configuration.xmlconfig, today it has a bare
except:
try:
self.context.begin(name, data, info)
except:
if self.testing:
raise
raise ZopeXMLConfigurationError, (
info, sys.exc_info()[0], sys.exc_info()[1]
), sys.exc_info()[2]
Shouldn't it just catch ConfigurationError?
With both changes I get much nicer error report: just a traceback
with the correct info.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Event fixes
Dominik Huber wrote: The modification descriptiors were introduced by Uwe Ostermeier to handle the versioning and cataloging stuff. I'm not an expert in that field, but in my understanding the modification descriptors are more general and your case is a subset that could be handled with them. As a developer, I would still prefer one concept, because it's easier to adapt. Sufficiently fundamental cases are always a shaky discrimination to differ two concepts for future implementation decisions. If you don't feel that containment boundaries are a sufficiently fundamental concept, then we have a strong disagreement. I stand by what I checked in. And BTW with modification descriptions I couldn't write a simple adapter for this. I'd have to have a generic adapter for IObjectModifiedEvent, then iterate over all the descriptions and filter by hand. Yuck. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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
On 28 Nov 2005, at 22:09, Dominik Huber wrote: Florent Guillaume wrote: On 28 Nov 2005, at 19:30, Dominik Huber wrote: Florent, But at least the event notifications within the setitem function is kind of redundant. An add-, move- and remove- event is a part of the container framework. Therefore we can assume that the underlying container referenced by the event.object.__parent__ has changed too. file: zope.app.container.contained.py: def setitem(container, setitemf, name, object): ... if event: notify(event) notifyContainerModified(container) If you don't have this container notification, then when you want to know when a given container object is modified you have to listen to all add, remove and move events, and then introspect their oldParent and newParent. Doh. The object event framework promises you that if there is something happening to an object, you get notified of it directly. That's what I'm doing here, I'm notifying that the container object was modified, because it was. If you have a problem with that event, then you should have a problem with the whole concept of event dispatching to sublocations, which are also redundant but which we want to make explicit nevertheless, for the benefit of subscribers. Dispatching does not mean redundant event information! IMO, there are three use cases mixed up: 1. Notification if the *order* of container was changed. 2. Notification if the content of a container was *moved* (add- and move events). 3. Notification if the *content* of a container was changed (Mechansim to inform super (parent) objects) Yes there are certainly several problems intertwinned. 1. A subtype of IObjectModifiedEvent could make sense, because only the state of the container changed. (Here is our dispute wether we implement such an event as subtype or be the general object modified event and modification descriptors.) Yes that's where I thought our dispute was all along. I appreciate your point of view here, even though I don't agree with it. We'd want external opinions. Jim appeared to say that the subtype-based approach had merit, and that the description-based approach had merit too but wasn't adequately worked out. 2. A subtype of IObjectModifiedEvent is cluttering because of redundant modification events. The modification is caused by the containment. Regularly the dispatching related to the containment hierarchy tries to emulate an information flow from *parent - child*, because children should be informed if the location information has been changed. But the other way around you need *never* a notification, because the container is aware of changes related to the container framework! Here an more adequat solution would be an internal container framework event that derives from IObjectEvent but not from IObjectModifiedEvent, because otherwise we would notify the same modification using two redundant modification events. Here you lost me. I changed the type of event sent to a subclass of what it was before. Before, it was IObjectModifiedEvent. So all you're saying applies to code that's been there *forever*. Yes, there are multiple events dispatched for a single operation. It's always been like that. Please reread my checkin: http://svn.zope.org/Zope3/trunk/src/zope/app/container/contained.py? rev=40368r1=39759r2=40368 There was already code before that sent an event about the container. That I didn't add. 3. IMO you are introducing something like a dispatchToParentLocations information flow from *child - parent* I didn't introduce any fundamental concept, I only specialized an event. similar to the dispatchToSublocations (*parent - child* ). I like this idea, but I would generalize it: It might be interesting for parents to be informed if the state of a containment has changed. def dispatchToParentLocations(object, event): parents = IParents(object, None) if parents is not None: for parent in parents : for ignored in zapi.subscribers((parent, event), None): pass # They do work in the adapter fetch subscriber for=zope.app.location.interfaces.ILocation zope.app.container.interfaces.IObjectMovedEvent handler=.contained.dispatchToParentLocations /subscriber But then we would have the problem, that we could not differ child- parent and parent-child handlers... Florent, excuse my insistence, but I'm afraid that we mess up the notification mechanism. Excuse my insistence, but the only thing I *added* was a modification event when you reorder the children of an ordered container. Before attacking it, please undestand what I checked in. I think I understand your intention. The only thing I realy defend is the fact that we should not implement different approaches (models of a containment hierarchy) using the same events, because we have no change
[Zope3-dev] Re: Event fixes
Stephan Richter wrote: On Thursday 24 November 2005 07:13, Florent Guillaume wrote: I'd like to do a few simple fixes to events in Zope 3.2 before it's too late: - Add the source to IObjectCopiedEvent, per http://www.zope.org/Collectors/Zope3-dev/478 I believe I received a +1 on this - Make OrderedContainer.updateOrder send an IObjectModifiedEvent. Today when you change the order no event at all is fired, this is wrong. Eek, +1 definitely. - Finally I'd like to make all containers send a specific subclass instead of just an IObjectModifiedEvent (I propose naming it IContainerModifiedEvent), because it makes it possible to isolate change to an object that only affect the 'containment' aspect of it. Subscribers can then have specific optimizations, for instance a catalog would want to isolate this because it only affects containment boundaries and not the content of the object. (This is a concrete use case BTW, in CPS's event model we have this distinction and it's useful.) +1. This shouldn't affect existing subscribers at all, because they'd be subscribing to IObjectModifiedEvent and this would still match. Exactely. Please give me your opinion on this quickly, unless you're too busy flaming :) So, +1 for the proposal. I've checked in all that. I didn't follow Dominik's suggestion of using IModificationDescription because I feel this a case sufficiently fundamental that we really want a subclass. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Reunite Zope 2 and Zope 3 in the source code repository
Stephan Richter wrote: On Thursday 24 November 2005 00:41, Philipp von Weitershausen wrote: At least no one is expecting to make such big changes by yourself. Being stubborn and refusing to do further contributions, be they large or small, isn't going to get us anywhere. The people who are so far backing up this proposal have nothing but support to offer and you know that. I am as stubborn refusing this proposal as you are pushing it. Right now there are more -1 votes than +1 votes. My vote is a +1 too. Maybe it is time retract the proposal? Furthermore, I have yet to see contributions for Zope 3 from people using Five. We are not even getting bug reports. Maybe because the small part of Zope 3 they use through Five is well tested? Frankly if someone refactors Zope 3 and this causes tests breakage in Zope 2 or Five tests, a Zope 2 or a Five developer will be happy to fix them very quickly, and there's a 50% chance that it will reveal something missed in the Zope 3 tests. Also I've seen some comments that the Zope 3 base will become polluted, that's nonsense, there will always be pure packages of Zope 3 out there without the Zope 2 part. Remember this is a proposal about merging repositories only, so that lots of time is not wasted setting up sandboxes, merging stuff left and right, and running tests in some forgotten area that also matters. And if Zope 3 developers don't want to run the Zope 2 tests because they're costly in time, it's trivial to do so. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Event fixes
I'd like to do a few simple fixes to events in Zope 3.2 before it's too late: - Add the source to IObjectCopiedEvent, per http://www.zope.org/Collectors/Zope3-dev/478 I believe I received a +1 on this - Make OrderedContainer.updateOrder send an IObjectModifiedEvent. Today when you change the order no event at all is fired, this is wrong. - Finally I'd like to make all containers send a specific subclass instead of just an IObjectModifiedEvent (I propose naming it IContainerModifiedEvent), because it makes it possible to isolate change to an object that only affect the 'containment' aspect of it. Subscribers can then have specific optimizations, for instance a catalog would want to isolate this because it only affects containment boundaries and not the content of the object. (This is a concrete use case BTW, in CPS's event model we have this distinction and it's useful.) This shouldn't affect existing subscribers at all, because they'd be subscribing to IObjectModifiedEvent and this would still match. Please give me your opinion on this quickly, unless you're too busy flaming :) Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: branched Zope 2.9
[Reply-To and Followup-To zope-dev] Andreas Jung wrote: Anyway if we want to go further we need to schedule bug days. One per week, or something like that. Otherwise nobody will set aside the time to discuss, investigate and fix the current bugs. Right, right, but there must be enough people to fix bugs...the last bugs days we had were not sooo successful. Then let's try again :) There is no way to enforce contributors to fix bugs. Speaking for myself I look at bugs from time to time and see what I can fix. There are bunch of bugs where you don't know if it is a bug or a feature...it's basically a question of having time... But having specific days set aside is still a good incentive. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Object event dispatching in Zope
I've posted a blog entry about object event dispatching which tries to details that complex process: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ 2005_11_10_object-event-dispatching Also on Monday I posted an entry detailing how these object events can be used through Five in Zope 2.9: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ 2005_11_08_events-in-zope-2-9 Comments welcome. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] _notifyOfCopyTo
Zope 2, when it copies/moves an object, calls ob._notifyOfCopyTo to allow it to veto the copy *before* it is done if it doesn't like the destination container. In Zope 3, is it worthwhile to have a kind of ObjectWillBeCopied/ Added event for that, or do you guys feel that this kind of vetoing should be done by simply subscribing to ObjectAddedEvent or one of its friends? I'm asking because I'm in the middle of converting Zope 2's OFS spaghettis to cleaner event-based code (and deprecating things like _notifyOfCopyTo and _postCopy). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] event before delete
More generally, there's a difference in philosophy between Zope 2 and Zope 3 here: - Zope 2 calls manage_beforeDelete *before* the removal, - Zope 3 sends IObjectRemovedEvent *after* the removal. This will make some porting / compatibility more difficult. I may add an IObjectWillBeRemovedEvent in Five for that, but maybe it makes sense to have it in pure Zope 3 ? Florent Florent Guillaume [EMAIL PROTECTED] wrote: Zope 2, when it copies/moves an object, calls ob._notifyOfCopyTo to allow it to veto the copy *before* it is done if it doesn't like the destination container. In Zope 3, is it worthwhile to have a kind of ObjectWillBeCopied/ Added event for that, or do you guys feel that this kind of vetoing should be done by simply subscribing to ObjectAddedEvent or one of its friends? I'm asking because I'm in the middle of converting Zope 2's OFS spaghettis to cleaner event-based code (and deprecating things like _notifyOfCopyTo and _postCopy). -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: Rename principal to participant
Steve Alexander wrote: Interesting. It looks to me like you're calling a User object what the CMF calls a Member. Sure. Does the CMF have any users who aren't members? The theory is a bit hazy but the practice is quite clear: in CMF all participants are members. The Member object is just a wrapping around the standard User object created during authentication. This wrapping is useful for annotations (email, last_login_time) and other indirections so that Member properties storage is actually dealt with by another tool (the MemberData tool). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Timezones
I'm seeing lots of discussion about timezone handling, but I'm afraid I haven't quite grasped the problem, and why an additional module pytz is needed in addition to the standard datetime, if everyone uses UTC? Is standard python datetime buggy? Could someone do a short writeup of what's at stake and what's recommended? Thanks, Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
Jim Fulton wrote: I think that sources are different than initial value. I really don't see any role that initial value has in an object specification. A schema is a specification for an object that provides the schema. An initial value doesn't constrain or specify the object. If anything, it constrains applications that create the object, but in a rather unclear way. But a schema is useful for more than specifying the values of an object. All notions of schemas I've encountered (CPS Schemas, XML Schemas, Archetypes) use the schema to constrain or validate an existing object, yes, but also to create new objects from scratch (even in the absence of widgets). Being able to specify initial values is quite important there. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Drop-in rich (JS/CSS-dependent) view components: Please review (was Re: Resource Library Proposal)
Gary Poster wrote: On Aug 31, 2005, at 3:55 PM, Benji York wrote: I've added a proposal for Zope 3.2. Read at http://www.zope.org/ Wikis/DevSite/Projects/ComponentArchitecture/ResourceLibrary. WARNING: zope.org exhibiting some serious caching strangeness, so please comment on the list instead of the wiki. Benji posted this last week and we don't have any feedback yet. We would really like some, even if it is to ask us to clarify what the heck it is about. Some of our other code that we want to contribute depends on this. This is very interesting and very needed, big +1. How does the code do the insertion inside the generated browser HTML? Does the ZPT replace=resource_library:my-lib trigger all this? I'd expected to see a browser:something directive to specify that, conceptually you could do the insertion in other outputs beside HTML. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
Jim Fulton wrote: But a schema is useful for more than specifying the values of an object. All notions of schemas I've encountered (CPS Schemas, XML Schemas, Archetypes) use the schema to constrain or validate an existing object, yes, but also to create new objects from scratch (even in the absence of widgets). Being able to specify initial values is quite important there. It's not clear to me that XML schemas specify this. I'm quite skeptical than they do. (They have this mysterious initial value thing that I can't make any sense of.) I can't believe that XML schemas deal with the history of a document, which would seem necessary to give inital value, as we mean it, any meaning. http://www.w3.org/TR/xmlschema-0/#OccurrenceConstraints (2.2.1) says: Default values of both attributes and elements are declared using the 'default' attribute, although this attribute has a slightly different consequence in each case. When an attribute is declared with a default value, the value of the attribute is whatever value appears as the attribute's value in an instance document; if the attribute does not appear in the instance document, the schema processor provides the attribute with a value equal to that of the 'default' attribute. Note that default values for attributes only make sense if the attributes themselves are optional, and so it is an error to specify both a default value and anything other than a value of 'optional' for 'use'. An instance document is comparable to our object, it is what is being validated/filled by the processor. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RDFLib and Zope 3
Gary Poster wrote: On Aug 23, 2005, at 8:07 PM, Michel Pelletier wrote: On Tue, 2005-08-23 at 18:04 -0400, Gary Poster wrote: The relationship between ZODB content objects, their int id as provided by the pertinent intid utility, and a (theoretical) corresponding RDF URI is what I'm having a hard time not making hacky in my mind. I'll think about it some more. They might not be that hacky, this might be the wrong direction to take but URI's don't have to be visually meaningful, blank nodes, for example, are usually just '_:' concatenated to a random opaque string. If the URI were 'zope:' (maybe path/to/intid/util:) that would work just as well, it would also be trival to transform into a feasible join key if the URI was also a URL that looked up, instead of some network resource, an intid. Actually being able to trivially transform an intid to an rdflib URI might be something to think about. Thinking about it more, the current Zemantic uses the physical path of the object as the rdf:about= URI when an object adds itself, because honestly I could think of no other URI in Zope. This is obviously wrong, but I didn't have a better answer in paris. Why not use the `intid` plus some URI sugar? If the URI and the intid can be easily converted from one to the other then that should solve the whole problem, no? Here's another way to work with intids that I think could work: In rdflib in some backends like IOMemory, and internal id is found for a subject (or predicate or object) to use in the internal storage datastructures. rdflib uses some randid() for that. I propose that instead of calling randid(), it called self.assignid(subject) which would be pluggable. By default this would be the default randid, but you could allow Zope to create a graph with an assignid that assigned ids based on the intid service. Then if a subject or object passed to rdflib is an integer instead of a URI, it would be used directly. In effect you'd give access to the internal ids. (There are more details to solve (assignid needs to check for collisions sometimes), but I think that's a good starting point). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: file objects and formlib
Martijn Faassen wrote: [quotes reordered] - for an add form, if something goes wrong and the form is redisplayed with some validation errors, the uploaded file information is lost. This is bad because for a required file field, it requires multiple uploads where one should suffice, and for a non-required file field, it's even worse, as a user would have no motivation to re-upload the same file after validation failure and redisplay of the form, resulting in no file being uploaded at all. I've already solved [this] problem by storing files in a session temporarily. This isn't efficient, but I *also* developed something that will lick that problem and that I'll present in a lightning talk at the Plone conference. Yes that's a generic HTTP problem, and you *have* to use some kind of session to deal with it. There's no way around. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Philipp von Weitershausen wrote: Julien Anguenot wrote: I got a problem with the standard macros use and the XML header. I've a view defined like the one below : ?xml version=1.0 encoding=UTF-8? html xmlns:tal=http://xml.zope.org/namespaces/tal; xmlns:metal=http://xml.zope.org/namespaces/metal; body metal:use-macro=context/@@standard_macros/page !-- content -- /body /html And there, I got the following error when Zope's trying to render it : [snip] (`macroName`, `mode`), self.position) METALError: macro u'context/@@standard_macros/page' has incompatible mode 'html', at line 6, column 3 If I remove the xml header the error disappears. It sucks, don't it? Has anyone tried removing the macro mode check (in TALIntepreter.do_userMacro)? What would break? At least I think it wouldn't be a problem to allow inclusing of a XML macro in an HTML slot (or maybe the other way round -- I guess one of them works, as one is always stricter than the other). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Florent's O-R blog entry
Hi folks, I've just returned from vacation, I'll read your numerous emails and try to provided detailed answers ASAP :) Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/trunk/src/zope/app/testing/dochttp.py only append ... line to cleaned redirect test if there is a non-empty
Modified: Zope3/trunk/src/zope/app/testing/dochttp.py === --- Zope3/trunk/src/zope/app/testing/dochttp.py 2005-08-09 18:33:26 UTC (rev 37819) +++ Zope3/trunk/src/zope/app/testing/dochttp.py 2005-08-09 20:00:55 UTC (rev 37820) @@ -129,13 +129,15 @@ print ' print http(r' print ' ...', '\n ... '.join(request.lines())+')' if response.code in (301, 302, 303) and clean_redirects: +content_length = None if response.headers: for i in range(len(response.headers)): h, v = response.headers[i] if h == Content-Length: +content_length = int(v.strip()) No need to strip(), int() does that by itself. Florent response.headers[i] = (h, ...) lines = response.header_lines() -if lines: +if lines and content_length: lines.append(...) else: lines = response.lines() -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: security frustrations
Does it work to just set __parent__ to the container? Or does the zopesecuritypolicy require more accurate context? Florent Martijn Faassen wrote: Hi there, In working with Zope 3 to build an application, I repeatedly run into the following situation: * user gets a local role on a container * object is created * after object creation but before the object is added, various things are done to the object. * authorization error: user cannot access various attributes. Now, the user would've had access to this after the object is added to the container, as then the role would've been acquired. In this latest the container the object is added to is actually *dependent* on the state of the object, though. Besides, sometimes one wants to mess with object attributes *before* adding it and thus getting it, say, cataloged. Now in Zope 2 this is: * normal as everything needs to be acquisition wrapped * not a problem as filesystem code is trusted In Zope 3, filesystem code is not trusted, and now this actually bites me more than it ever did in Zope 2. This is frustrating. I can hack around it by sprinkling removeSecuritProxy throughout the codebase, but that's certainly not pretty. Zope 3 is usually very nice about context not being dependent on location (I see now why getSite() is very nice), but the security case is an exception. I don't have a concrete proposal about what should be done. I guess the paradox is that on the one hand I *want* acquisition of role information from the container (as the security model this application has is quite involved), and on the other hand I keep getting bitten by it. My problem is only with zopesecuritypolicy. At first I thought about implementing my own security policy for this application, but this got quickly very hairy, so I decided to stick to Zope's. I guess this also ties in to Steve Alexander's ongoing campaign against location (as opposed to site) dependence in Zope 3. Maybe he has a better idea how to resolve this... Regards, Martijn -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Problem with zope.app.security._protections for tests
Fred Drake wrote: On 8/8/05, Gary Poster [EMAIL PROTECTED] wrote: lol. eek. yuck. :-) Yep. Not sure what the best way to avoid this would be, either. Make a fake zope.app.security._protections module in sys.__modules__ ? (The solution to a yuck *can* be a super-yuck!) Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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/wfmc/process.py Developed nicer, human-readable representations of several classes. Hope
Stephan Richter [EMAIL PROTECTED] wrote: Log message for revision 37434: Developed nicer, human-readable representations of several classes. Hope you like it! :-) Cool. BTW I tend to use ... %r ... % foo.__name__ instead of ... '%s' ... % foo.__name__ though, just for the cases where the name is Unicode... (I've been bitten before by UnicodeDecodeError displaying objects reprs or tracebacks or things like that.) Florent --- Zope3/trunk/src/zope/wfmc/process.py 2005-07-26 20:22:04 UTC (rev 37433) +++ Zope3/trunk/src/zope/wfmc/process.py 2005-07-26 20:29:49 UTC (rev 37434) @@ -162,6 +162,10 @@ self.outgoing += (transition,) else: self.outgoing = self.transition_outgoing + +def __repr__(self): +return ActivityDefinition '%s' %self.__name__ -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] interaction between LocationProxy and IIntId utility
Benji York [EMAIL PROTECTED] wrote: Jim Fulton wrote: We don't want to *require* objects to provide ILocation. I don't know what the right answer is here. I'll think about it. I'd love some good suggestions. Perhaps an ILocation adapter that would keep the __name__ and __parent__ information in a separate place (attribute annotations, or a BTree somewhere). So, instead of things getting proxied when they don't provide ILocation, they would instead be adapted. I was about to propose that too, just do object = IContained(object) and let adapters do what's needed. That may be too naive, I don't know... Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ILocation vs IContained
I'm having a hard time grasping the reasons why we have both ILocation and IContained. class IContained(ILocation): Objects contained in containers. But ILocation provides a __parent__ already, which seems to imply that it's contained in it. No? What use case makes us differentiate between the two? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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/intid/ Revert changes to IIntIdsSet interface.
Hi Dominik, Dominik Huber [EMAIL PROTECTED] wrote: Log message for revision 30706: Revert changes to IIntIdsSet interface. Could you expand a bit in the checkin message on the motivations behind your changes? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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\app\container\contained.py
E. Frerich [EMAIL PROTECTED] wrote:
line 545 of zope\app\container\contained.py contains a testcase
setitem(container, container.__setitem__, 'hello ' + chr(200),
item) which should give back a traceback: Traceback (most
recent call last):
...
TypeError: name not unicode or ascii string
but the name parameter is correct:
max=unicode('hello ' + chr(200))
That shouldn't work. You're running with a non-default system default
Oh - what is a non-default system default? The naked Python has
'ascii' as default but you can customize the default for a Python site.
Yes but this is highly unadvised. It's more a band-aid for lazy apps
than anything else.
So my Python site has the default encoding 'cp1252'. All applications
- not only Zope 3 - use this encoding.
Which means that all your applications are written with an implicit
assumption about the default system encoding. And they will break on
platforms with a different choice.
IMO Zope 3 should accept other default encodings.
Zope has to be conservative so that it knows it can run everywhere.
And then this test is not helpful.
It ensures that Zope works with minimal standard python settings.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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
Jim Fulton [EMAIL PROTECTED] wrote: Based on the discussion so far, I'm convinced that something like this would be useful, at least as an optional feature, as you suggest. I suggest we generalize this a bit. I suggest that the ObjectModified event could accept one or more modification 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. That looks good to me. Especially because, using interfaces, we could theoretically express more than just a set of attributes that have changed on an object. I'm thinking of: - having the interface itself add semantics to what a subscriber could want to do about the change (i.e., it could recognize IZopeDublinCore and decide to delay its work), - having the interface express more complex object structure than just a set of attributes (I'm thinking about XML Schema-derived / XForms interfaces, where you can represent deep structures). That's all science-fiction of course. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Dicts for faster membership testing
Stephan Richter [EMAIL PROTECTED] wrote: On Friday 22 April 2005 10:32, Dmitry Vasiliev wrote: Old code (with lists): [29.604110019569525, 29.467640440335295, 29.480704670565679] New code (with dicts): [29.188246830253565, 29.027186136785541, 29.018876700809741] A 1% increase; not bad. Definitely noticable for large apps. Hm I'd have said: A 1% increase, never worth the bother, will be drowned in other noise anyway. However in this case I agree that using dicts for membership testing *is* good practice. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] release numbering
Martijn Faassen [EMAIL PROTECTED] wrote: The only non-standard part left in the release name if we drop the double 3 is the X. The X is a bit of a bother and will get us into trouble anyway eventually if a Zope 3 proper is ever released, as I can't see how we'd avoid situations where we'd have to say: Zope 3.1 is actually Zope X3.4 + Zope 2 compatibility extensions 0.7, which sounds less than ideal. I personally wouldn't mind if we just dropped the X. Yes, IMHO it'd be simpler to rename Zope X3.4 to Zope 3.4, and when the real Zope-3-with-Zope-2-compatibility arrives, either call it 3.6 or whatever is the current numbering, if it makes sense to have it in the same branch (which I understand may not be the case), or simply go to Zope 4. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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/doc/security/SecurityTarget.txt - removed rst document in favor of latex
Gh Why oh why ? The document is now totally unreadable, except by reading a generated .ps or .pdf. That's not the way to go for documentation :( Florent PS: also the add/remove should be in the same svn changeset. Christian Theune [EMAIL PROTECTED] wrote: Log message for revision 30036: - removed rst document in favor of latex Changed: D Zope3/trunk/doc/security/SecurityTarget.txt -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Persistent schemas
Stephan Richter [EMAIL PROTECTED] wrote: On Wednesday 06 April 2005 16:52, Dieter Maurer wrote: For new projects, you should investigate the new options. Product development will get much simpler with Zope3 technology (and its schemas and views). Currently, there is no TTW (Through The Web) development in Zope3 land, but that is planned. In about 2 to 4 years, we may have new ZClass like functionality implemented with Zope3 technology. And I am quite confident that the old ZClasses will live til then... Note that I prototyped such functionality a couple years ago. One could create TTW (Persistent) schemas and then declare a Content Component Definition based on this schema. People could then create instances of those content components. The Content Component Definition utility took care of doing all the security and basic menu/view setup. One can then write views and adapters for the content component to give it functionality. Unfortunately, persistent schemas got broken at some point, so the code is not that useful anymore. I really need to get together with Jim and force him to fix the problem with me, since I constantly forget what the problem is. ;-) I'll need to work on persistent schemas very soon. Could someone recap what the problem is ? ISTR that there was a problem with the way the are cached by the interface machinery, and maybe a pickling problem. Does someone have a bit more details (without going into great lengths, I'll be looking at it in any case). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
