[Zope3-dev] Re: [Zope-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Jim Fulton wrote: Any objections? This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. +1 from me :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Lennart Regebro wrote: On 10/4/07, Michael R. Bernstein [EMAIL PROTECTED] wrote: This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. +1 +1 What about retiring #zope3-dev IRC channel and only using #zope ? No. #zope is roughly the equivalent of the main zope list. There is no #zope-dev channel. Renaming #zope3-dev to #zope-dev would make sense to me though. +1 from me too :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Known working sets
Jim Fulton wrote: On Sep 5, 2007, at 10:48 AM, Chris Withers wrote: Jim Fulton wrote: I'm very much against making setuptools *more* complicated than it already is. Indeed, but surely managing known good sets of components comes under its remit of version management? Sure. It does this via requirements. Ok, forgive me for being dumb then, but why are we looking to add similar to zc.buildout? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Known working sets
Martin Aspeli wrote: Jim Fulton wrote: I'm very much against making setuptools *more* complicated than it already is. Indeed, but surely managing known good sets of components comes under its remit of version management? Sure. It does this via requirements. Ok, forgive me for being dumb then, but why are we looking to add similar to zc.buildout? We're talking more about a general pattern in zc.buildout. The deficiencies of using setup.py for this alone are described well in the original proposal. Yup, and this was the reason for my original question to Jim: why do something in zc.buildout rather than fixing the problems with setuptools? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Known working sets
Jim Fulton wrote: I'm very much against making setuptools *more* complicated than it already is. Indeed, but surely managing known good sets of components comes under its remit of version management? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Known working sets
Philipp von Weitershausen wrote: As far as I understand your use case, i twould already be covered by my original proposal: you always have the option to locally override what's specified in the working set. I think Dieter may have meant something like: [grok-0.11] grok = 0.11 ZODB = 3.8.0-3.8.4 zope.component = 3.4.0,3.5.1,3.5.2 I'm still a bit disappointed that we can't get this kind of support from distutils. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: A thought on backward compatibility and minimum versions
Tres Seaver wrote: Another feature I'm not sure is already in setuptools: - I *don't* want dev releases to replace production ones implicitly: no package should be able to install a non-released version without explicit callout. If this isn't already the default behavior, then I'd like syntax for spelling it. +lots... I haven't been paying huge amounts of attention, but I've noticed what seemed to be a few people complaining about dev eggs stomping on their production eggs :-S Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: How to deal with major versions?
Jim Fulton wrote: I don't see how this helps one say that they want to depend on a minimum version of a major version. That is, how does it prevent dependencies like: foo =1.0 1.999 ? I'm wondering how Gentoo got *that* right. I wonder if the package should have something in it's setup.py that says I won't be compatible with anything expecting version 2.0 ? This would end up as metadata on pypi or in the egg/.tar.gz and setuptools could do the hard work of resolving the dependencies... It also removes the burden of specifying maximum revision numbers on the consuming packages and puts it where it belongs: on the maintainer of the package who knows if it's going to be backwards compatible or not.. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: egg version numbers and zope releases
Benji York wrote: Even if developers remembered, it would be icky to have to spell out something like =3.4 =3.99 on everwhere. Not as icky (IMHO) as having distribution names with embedded major version numbers. I'm interested in other people's opinions here. I'm definitely in agreement here. Everytime I type BTreeFolder2 I feel like someone's killing a kitten somewhere. It's a shame setuptools doesn't take care of this properly :-/ (where my definition of properly is that major releases like 2.0, 3.0 are assumed to be backwards incompatible such that 3.0 won't satisfy a =2.0) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
Marius Gedminas wrote: * distros splitting the Python profiler into a separate package due to licencing problems, with a helpful stub that prints an informational message (go apt-get install python-profiler) instead of raising ImportError. On this one, I raised it with the package maintainer and I think this is now fixed... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] Using Zope3 components outside Zope
Andrew Groom wrote: Thanks for your reply. I have seen references on how to set up adapters in code, but I was trying avoid having to duplicate things that have already been defined in zcml. However, if there's no other way around it, then that's what I'll have to do. Well, you could always install zope.configuration as well and then just use the zcml, but provideAdapter is pretty lightweight and is what the zcml stuff ends up calling under the hood anyway... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what dependency to use for zope 3
Bernd Dorn wrote: for my projects however i just directly set all zope.* dependencies in setup.py explicitly, see the various z3c.* on svn.zopeorg packages as examples I guess that makes sense if the satellite projects start getting their own release cycles, which I think would be a good thing. I dunno, do we actually need an offical big zope 3 release anymore? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] adapter lookup question
Hi All, I want to lookup a multi-adapter using the following code: getMultiAdapter((obj1,obj2),ISomething) I also wanted to have a backstop adapter so that the above would never fail, which I tried to register as follows: adapter for=* * provides=ISomething factory=.something.Something/ ...however the getMultiAdapter call still failed with a ComponentLookupError :-( I had to change the registration as follows: adapter for=* .module.BaseClassOfObj2 provides=ISomething factory=.something.Something/ ...to get the getMultiAdapter call to work. Why do I need to do this? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Separating projects
Christian Zagrodnick wrote: On 2007-04-27 02:43:10 +0200, Fred Drake [EMAIL PROTECTED] said: [...] Since I expect the giant checkout to rapidly fall out of favor, I'm all for moving code to the satellite projects. Then Zope 3 will be free to become a swarm of nano-projects that can be assembled into useful but also lean and maintainable applications. Which is what we really care about. Yes! I'd very much like that. That makes it also easier to get the dependencies right. +1 from me. One of the main things stopping me doing zope 3 development is the need to do a monster checkout. Of course, the only slightly risk is that when you change a satellite project, you cause test breakage in other satellite projects. How do people feel about that? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Community opinion about search+filter
Adam Groszer wrote: Somehow relevant to the subject I just found an article on Wickert's site: http://www.wiggy.net/ , Using a seperate Data.fs for the catalog The win here is actually partitioning the object cache... Similar wins could be achieved without making backup/pack/etc more complicated by making the object cache more intelligent: - based on size of objects, not just number - memory limiting (including intra-transaction) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Bare excepts in z3c.zalchemy
Jürgen Kartnaller wrote: The fact that you get an error there is an indication that something in your tests still has a file open in some way, you should fix that ;-) The something was/is sqlite ! I don't know what that's supposed to mean, since I have little context on the tests, but if a test has managed to get sqlite to open a file, then it should make sure that file gets closed again, surely? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Bare excepts in z3c.zalchemy
Jürgen Kartnaller wrote: Yes these stupid except's are because of windows :( I wrote the first version on windows and had the problem that windows didn't let me delete the files. It is possible to do this right, I've had to in the past... The fact that you get an error there is an indication that something in your tests still has a file open in some way, you should fix that ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Bare excepts in z3c.zalchemy
Philipp von Weitershausen wrote: I would offer my help if I knew enough about SQLAlchemy and what kind of things can go wrong in those cases. Either way, I'd feel better using and recommending zalchemy if it didn't have those bare except clauses... There's never a good excuse for bare excepts ;-) Take 'em out and see what happens would be my recommendation... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Why is the testrunner running with the --profile option ?
Michael Haubenwallner wrote:
Here is the patch that made it break:
+--- Lib/hotshot/stats.py~2001-10-15 22:18:53.0 +
Lib/hotshot/stats.py2006-04-21 18:39:17.691461512 +
+@@ -1,7 +1,14 @@
+ Statistics analyzer for HotShot.
+
+-import profile
+-import pstats
++try:
++import profile
++import pstats
++except ImportError, msg:
++import sys
++sys.stderr.write('ImportError: %s\n' % str(msg))
++sys.stderr.write('please install the python%s-profiler package\n'
++ % sys.version[:3])
++sys.exit(1)
+
+ import hotshot.log
Wow, that's pretty evil.
Who's the appropriate Ubuntu person to take this up with?
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Why is the testrunner running with the --profile option ?
Andrew Bennetts wrote: Chris Withers wrote: Michael Haubenwallner wrote: Here is the patch that made it break: +--- Lib/hotshot/stats.py~2001-10-15 22:18:53.0 + Lib/hotshot/stats.py2006-04-21 18:39:17.691461512 + [...] Wow, that's pretty evil. Who's the appropriate Ubuntu person to take this up with? Matthias Klose, but the best way to report this would be via: https://bugs.launchpad.net/ubuntu/+source/python2.4/+filebug done: https://bugs.launchpad.net/ubuntu/+source/python2.4/+bug/88960 cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: run-time adapter registration and un-registration
Philipp von Weitershausen wrote: Interesting. plone.portlets actually uses the Component Architecture and a persistent registry as the underlying plugin system, it just provides a fancy UI on top of this to manipulate the registry. Is this an adapter registry, a utility registry or both? What about subscribers? Does it still get the same performance optimisations as the global registries? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] run-time adapter registration and un-registration
Hi All, I'd like to build a UI that allows a user to changing what adapters (views in particular) are assigned to an interface through a web interface. The sounds like it's going to require runtime assigned and un-assignment of adapters. Has anyone tried this before? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
Philipp von Weitershausen wrote: Okay, how about the config parser registers the utility: The config parser (ZConfig) is generic Well, it runs of a schema which uses handlers specific to the project, so I don't see what your point is here... the component architecture. The main() program in zope.app.appsetup, which makes use of the zope.conf configuration, would have to do it. ...it sounds like Zope 3's ZConfig schema creates an inert source of information, unlike Zope 2's, which instantiates things as it parses the config. Is that the case? Right, but the whole point of factoring it out to a utility is to gain the ability to override things. If it's registered using z.c.provideUtility(), it'll be hard to impossible to override it using overrides.zcml. True, but if this happens in parsing zope.conf, you don't want to be able to change it later... That's why I suggested we use named utilities because the we don't need to work with overrides.zcml. I'm still struggling with why they need to be named, no doubt I'll find out why if/when I make a start on this ;-) If so, what bad things could happen if the zodb sections in zope.conf were made optional and a later zcml statement provided the utility? utility factory=myIRootObjectProvider / Yeah, but how would you implement myIRootObjectProvider w/o having access to the ZODB? I'd envisage myIRootObjectProvider would be the thing which opened the zodb... You don't know which ZODB you're going to get the root object from because that's decided *at runtime* in the main() program by reading zope.conf. I thought you said the ZCML was processed after the main() stuff? Because I'm not sure how persistent objects behave in a global registry. I'd imagine the root would just be a factory that opened a new connection/etc on traversal, or when it was requested by the publication, or some such... Right now in the Zope default publication, the root object is gotten *after* opening the DB. If we'd register the (persistent) root object in the global registry, it might exist w/o any ZODB connections open. Not sure if that's every going to occur, or if that's going to be a problem, etc. I would hope to keep the semantics of getting the root object after opening the db in the same way... Anyway, I think I've tried to give as many pointers as I could. I'm sure some of the things discussed here will come up when you'll implement this :). Yep, I think it's time to start cutting code... eep... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
Philipp von Weitershausen wrote: What I meant: Since is we have things like zope.paste which work fine as 3rd party packages already, perhaps the Zope 3 core just needs to *support* this separation of server configuration and application definition, but doesn't necessarily need to *do* it. True. Why named? If only so you can register many of them, then I call yagni. Like a unix file system, a zope instance should only have one root :-) Sure. But the use of named utilities would make it a tad easier because you wouldn't need ZCML overrides. Let's say Zope 3 defines an IRootObjectFactory utility called 'zope.app.appsetup'. So, a default zope.conf would look like this: # root-object-factory -- name of an IRootObjectFactory utility that the # publication will use to create the root object. # # Default: root-object-factory zope.app.appsetup Why would this be in zope.conf at all? I would have thought just having a normal zcml setup for a single, global IRootObjectFactory utility would be fine... Also, why the factory? Why not just IRootObject? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
Philipp von Weitershausen wrote: Why would this be in zope.conf at all? I would have thought just having a normal zcml setup for a single, global IRootObjectFactory utility would be fine... Well, actually, you can't register it through ZCML because ZCML knows nothing about the ZODB. Okay, how about the config parser registers the utility: from zope.component import provideUtility provideUtility(IRootObject,MyZODBRootThingy) Of course, I don't see any reason for the config parser to _have_ to do so... something just needs to register an IRootObject before the first publication gets instantiated, right? If so, what bad things could happen if the zodb sections in zope.conf were made optional and a later zcml statement provided the utility? utility factory=myIRootObjectProvider / Also, why the factory? Why not just IRootObject? I guess just IRootObject is ok, the factory would have been a bit more generic because then you're not registering a specific root object for all times but could actually incorporate some logic into the root-object-finding-process. Why would you want to do that? There should be only one root, if it then wants to do interesting things, then either it can, or traversal adapters that start with it can. Why would you want any more complexity? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
Philipp von Weitershausen wrote: Perhaps there's not a need for that separation in the Zope 3 core with packages like zope.paste around... Sorry, you lost me... there's what a need for what seperation? I thik we can stick with ZConfig for now, even though Jim doesn't like it... *wink* ;) I love ZConfig, so I'm okay :-) Yes, the publication in Zope 3 (which was written at an very early stage with a lot of Zope 2 background) has a method getApplication, but all it does is return the root object. So let's reflect that name in the utility. Right, okay, my mistake, that's what I was referring to... It just occurred to me that we could make those IRootObjectFactory things named utilities. Then you cna register as many of them at the same time and just choose which one you want using a switch in, say, zope.conf. Why named? If only so you can register many of them, then I call yagni. Like a unix file system, a zope instance should only have one root :-) (anything else can be wired in below that...) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.twisted.main?
Philipp von Weitershausen wrote: As Jim pointed out in an earlier discussion [1], we would rather like to separate server configuration from the application definition (ZODB, logs, etc.). That sounds like any work I do here will help... - make twisted/zserver interchangeable through a zope.conf setting Like Jim, I would rather like to see (at least the HTTP) server definition thru something that's more general, such as paste.deploy. I don't know paste.deploy and I don't have time or inclination to learn it. However, any work I do will be aiming to make it simpler to slot in different bits in different roles. What does paste.deploy do? I was toying with the idea of trying to have an IConfiguration utility such that ZConfig could be switched out, is that what you're talking about? - refactor so that as much code as possbile is shared between zope.app.twisted.main and zope.app.server.main +1 I'd say that this should result in a general main() program that *can* (but doesn't have to) read the application definition from a zope.conf file, Indeed. and does server setup (at least HTTP) through a general framework like paste.deploy. Well, I'll try and make this code encapsulated... I would assume that this also results in a separate configuration file for paste. Yay! More config files, just what we need ;-) - explore ways of seperating some of the publication concerns +1 For one, I suggest factoring the whole root object issue out of the publication (e.g. introduce an IRootObjectFactory utility that, when called, will return the root object; How about just making an IApplication utility, or is IApplication too specific? the main() program, if it has a zodb configuration, would register such a factory that would talk to the DB; others could do SQL or whatever). Yeah, this is exactly what I'm after :-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] development checkout
Hi All, It's been way too long since I did that, but how do I go about getting an svn checkout of Zope 3 that I can develop with? Is there a how-to somehwere? I'd imagine it goes something like: 1 - checkout svn url you wish to develop with 2 - do some kind of inplace build 3 - point your mkzopeinstance-created instance at the checkout 4 - develop 5 - run tests How do I do 2 and 5? For 2, how do I do a suitable in-place build on Linux? Are there still up-to-date pre-built binary bits for Windows that I can unpack? If so, where do I get them from? For 5, how do I run tests for a module in the checkout with the testrunner, as opposed to tests for a module in the instance? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] customizing accesslog format
Sascha Ottolski wrote: Hi, it appears as if the format for the access log is somewhat hardcoded. I see that there exists (at least) zope.app.server.accesslog zope.app.twisted.accesslog zope.app.twisted.log and twisted.web2.log ouch... From discussions I found it seems as if the latter would be the place to hack the actual logging format (like suggested in http://mail.zope.org/pipermail/zope3-dev/2006-January/017771.html). I'm wondering, is patching twisted really the way to go? It's a shame that the python logging framework isn't used by either twisted or zope3 from what you're saying :-( I wonder if they could be made to do so and if the respective communities would welcome that? Would it be feasible to make the acceslog format be customizable via a zope.conf entry, in a way similar to what possible with apache co.? Indeed, it should just be another logger section... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.twisted.main?
Stephan Richter wrote: On Thursday 01 February 2007 02:42, Chris Withers wrote: Is there a non-twisted main.py of does zope.app.twisted.main get used for all Zope 3 instances? zope.app.server.main How do you switch between the two? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.twisted.main?
Is there a non-twisted main.py of does zope.app.twisted.main get used for all Zope 3 instances? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
All the following are great, especially the (SF) ones ;-)
Tres Seaver wrote:
from zope.interface import Interface, Attribute
from zope.interface import implements, directlyProvides
from zope.component import provideUtility, provideAdapter, adapts
class IFoo(Interface):
... name = Attribute(u'Name')
class FooUtil:
... implements(IFoo)
... def __init__(self, name):
... self.name = name
fooUtil = FooUtil('default')
provideUtility(fooUtil)
fooUtilNamed = FooUtil('named')
provideUtility(fooUtilNamed, name='named')
class FooAdapter:
... implements(IFoo)
... adapts(None)
... name = 'default'
... def __init__(self, context,*args):
... self.context = context
class FooAdapterNamed(FooAdapter):
... name = 'named'
provideAdapter(FooAdapter)
provideAdapter(FooAdapterNamed, name='named')
Now the usage. Things which *don't* work today are marked '(SF)'.
Interfaces called with *no* context argument return
utilities, not adapters (SF)::
u_default = IFoo() # return the default utility
u_default.__class__.__name__, u_default.name
('FooUtil', 'default')
Named utilities can also be looked up (SF)::
u_named = IFoo(name='named')
u_named.__class__.__name__, u_named.name
('FooUtil', 'named')
Default adapter lookup works as expected::
context = object()
a_default = IFoo(context)
a_default.__class__.__name__, a_default.name
('FooAdapter', 'default')
But we can also do named adapter lookup (SF)::
a_named = IFoo(context, name='named')
a_named.__class__.__name__, a_named.name
('FooAdapterNamed', 'named')
I'll note that none of these appear to do contextual lookup.
Would we want a spelling like this which worked with contextual lookup?
One thing I think I mentioned before would be the ability to use
calling the interface to get a multi-adapter:
provideAdapter(FooAdapter,adapts=(None,None))
a_default = IFoo(objects=(context,context))
a_default.__class__.__name__, a_default.name
('FooAdapter', 'default')
One other thing, where is the code that gets called when you do
ISomething(..etc...)? I had a look in interface.py and couldn't find
anything :-S
I'd be interested in knocking the above set of extras up on a branch and
seeing what people think...
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] calling interface returns object, calling queryAdapter returns None?
Hot on the heels of my multi-adapter problem: http://mail.zope.org/pipermail/zope3-dev/2007-January/021600.html ...which I'm still waiting for guidance on, I now find that queryAdapter and calling an interface behave unexpectedly differently in the case where an object directly implements an interface: from zope.interface import Interface,implements class ITest(Interface): pass ... class Test: ... implements(ITest) ... t = Test() ITest(t) __main__.Test instance at 0x01C6E300 from zope.component import queryAdapter queryAdapter(t,ITest) How come calling the interface returns t but queryAdapter returns None? Should I log this and my previous multi-adapter example as bugs in the collector? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
Laurence Rowe wrote: From the Interface.__call__ docstring: If an object already implements the interface, then it will be returned queryAdapter is looking in the adapter registry. You have not registered any adapters. So this looks like the expected behaviour to me. Documented maybe, expected no. queryAdapter, for me, is starting with the supplied object, get me something that implements the supplied interface and return None if no such object can be obtained. If there's another function which does this, fine, if not, then I maintain the current behaviour is not correct... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
Jim Fulton wrote: If there's another function which does this, fine, if not, then I maintain the current behaviour is not correct... Chris, documented behavior is not incorrect just because you expect otherwise. Indeed, sorry, that's not what I meant, although I can see it came across like that. Apologies... Les try this again: what's the canonical way to find out if an object either implements a given interface or can be adapted to it? cheers, Chris PS: still looking for confirmation as to whether what I demonstrate in http://mail.zope.org/pipermail/zope3-dev/2007-January/021600.html is a bug or if I'm missing something? -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
Fred Drake wrote: On 1/24/07, Chris Withers [EMAIL PROTECTED] wrote: queryAdapter, for me, is starting with the supplied object, get me something that implements the supplied interface and return None if no such object can be obtained. o = IFoo(ob, None) if os is not None: Ah, now that's what I was looking for, thanks :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 without ZODB
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2007-1-22 13:51 +0100: ... I think the ZConfig argument was largely due to misunderstandings. I would be surprised if people really cared whether to Zope used ConfigParser or ZConfig (except Fred, perhaps ;)) And, as so often, me. Me too, and I don't often get to say that in reply to Dieter ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 without ZODB
Philipp von Weitershausen wrote: (Note that in my original reply to ChrisW, I tried to be pragmatic. Of course, if ChrisW has the resources to go into this refactoring, by all means, let's do it). No resources, sorry :-( Just a desire to see this done right :-S The pragmatic approach is just to make like Sidnei and have a zodb with only one root object in it... There are two parts of your question. Making it simpler to plug in a different application root, and dealing with ZConfig. This is true... while I'd love to have config have nothing to do with the problem at hand, I guess, as you point out, it's currently woken in. I guess a start would be to make it simpler to *not* use ZConfig but use a.n.other configuration method. I have memories of Jim having a proposal about this? In order to implement a simpler security mechanism for grok, we had to re-implement every single publication (though of course subclassing was still possible, but we had to create a new variant of every publication class). That shouldn't be necessary. Yeah, I'm guessing there's a few places where: -getting the root object -setting up the component achitecture -setting up the servers -setting up the security policy ...all run into one and maybe now's the time to burst them open? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3 without ZODB
Hey All, I'm still continuing poking around (when I have the chance) to see how I'd get Zope running without ZODB. Does the following line: db = zope.app.appsetup.appsetup.multi_database(options.databases)[0][0] ...from: http://svn.zope.org/Zope3/trunk/src/zope/app/server/main.py?rev=71011view=markup ...mean that Zope 3 is currently hard-coded to need a ZODB? If so, how should we go about making this optional? (I am willing to put the work in to make this happen if people give me some hints...) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 without ZODB
Philipp von Weitershausen wrote: We would check if options.databases if empty. If that's so, we could set 'db=None'. The 'db' object (the database) gets passed a long to the ServerTypes which pass it along to the WSGIPublisherApplication which then passes it along to the request/publication factory. This way, when a new request is created and a publication object with it, the publication has the database to start traversal off of. As far as I can see it, the publication is the only component in that whole chain that expects the 'db' object NOT to be None. So, you'd have to write your own publication that wouldn't use the 'db' object for a traversal root but your own custom object, e.g.: class MyPublicationMixin(object): Mix this in with BrowserPublication, HTTPPublication, etc. def getApplication(self, request): stack = request.getTraversalStack() if '++etc++process' in stack: return applicationControllerRoot myroot = RootObject() return ProxyFactory(myroot) Ouch, what this code seems to imply is that I'd have to create new publications of all types :-S It strikes me that I shouldn't have to mixin and create new publications of every type just because I don't want a ZODB ;-) Is there an IApplication? If so, could whatever calls getApplication (which I guess must somehow get passed db) rather adapt db to an IApplication? zope.conf could then return things other than ZODB db's from it's db section and everything would be great provided there was an adapter from the object returns to IApplication, where IApplication is the interface that describes whatever getApplication above should return? cheers, Chris PS: I'm aware the above is hand waving in some senses, I don't have the time I'd like to dig in and research this properly right now, but I want to try and get a feel of things for when I do... -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 without ZODB
Jim Fulton wrote: ...mean that Zope 3 is currently hard-coded to need a ZODB? That depends on what you mean by Zope 3. If you define Zope 3 as zope.app.server.main, or zope.app.twisted.main, then yes, it is. I wouldn't define it that way, although I can see how others might. :) Well, for me, a Zope 3 instance is what you get when you run mkzopeinstance. If there's other alternatives to that, I'd be interested in exploring them :-) If so, how should we go about making this optional? You would need to write a different main program that did something else. Has anyone else attempted this? Does grok have one of these? You would need to understand how the publisher framework worked and plug in an alternate publication that traversed to non-ZODB objects. I touched on this with my reply to Philip, but surely the publication type should just be operating on objects that implement an interface? It seems odd, at least to me, that I'd need to rewrite publications that know about things like http, ftp and webdav just because the object I want to publish come from a file system or relational database rather than a zodb... do this. It isn't very complicated. I have a strong itch to write such a document, but I don't know when I'll get around to scratching it. I don't know if any of books get into this. I'll be blunt here, I'm more into app frameworks than server frameworks so I'm far from best placed to do this work, but I do what to see more freedom in where data served by zope 3 comes from and especially I'd to find a way to have a zope 3 not rely on a zodb being present at all. Don't get me wrong, I love zodb, but it runs into problems of political acceptance on the one hand and lack of support for high write volumes... (I am willing to put the work in to make this happen if people give me some hints...) Other people have already made this happen. I don't know if any of their code is public or if they have written up what they've done. This is a bit cryptic... are you saying there is an alternative zope 3 that already has alternatives to zope.app.server.main or zope.app.twisted.main? If so, where are they to be found? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 without ZODB
Jim Fulton wrote: I would *much* rather see us open this up by making this part of Zope 3 more modular and putting more emphasis on explaining what is going on and how one would do something different. big +1 from me... Here's what I'd like to see: 1. Separate server definition from application definition. They are way too interwoven now. I'd like to see us move to Paste Deploy (or something based on the framework it defines). Is this the seperation of what objects are being served from what protocols are being served that I mentioned in my other reply? In my dreams, it'd be great if I could just wire in a different IApplication utility to get the root of the object tree and just leave the zodb section of zope.conf empty. How hard would that be to achieve? (the 2nd bit of it is important, I don't want zodbs opened, especially if they're never going to get used) 2. Document how to use the zope.publisher framework to define web applications. It isn't very complicated, it just needs some documentation. I made a beginning of of this in my aborted bobo project. A good start for examples would be a hello-world app, the existing zope 3 app, and, I assume, Grok. Yes, I'm curious about Grok too here, I hope someone who knows from that project will pipe up. Would the hello-world app be akin to the stuff I was nosing around in zope.app.appsetup? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] wildcard adapter
Marius Gedminas wrote: There's a slight difference, I think. In the Zope 3 world, there's usually one style that is considered to be the best way of doing stuff. Only it varies with time and with individual Zope 3 developers. ;-) I do wish it would stop varying... If you pass the adapts/provides arguments to provideAdapter (or the ZCML directive), the values you specify override the defaults declared by the adapter itself. Right, so provideAdapter is still king? ;-) Does your favoured methodology actually register the adapter? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wildcard adapter
Marius Gedminas wrote: Now when you try to adapt anything to ITest, zope.component will call your ``adapter`` function and then check the return value. A return value of None means the adapter is not available, and results in a TypeError you see here: Yes, apologies, both you and Philipp are correct, I was trying to show a simple version of a problem and oversimplified. Here's what I really meant: from zope.component import provideAdapter from zope.interface import Interface from zope.component import getMultiAdapter class ITest(Interface): pass ... def adapter(*args): return args ... provideAdapter(adapter,adapts=(None,),provides=ITest) ITest(1) (1,) Yay, as expected... getMultiAdapter((1,),ITest) (1,) Good, still works... provideAdapter(adapter,adapts=(None,None),provides=ITest) getMultiAdapter((1,1),ITest) Traceback (most recent call last): ... zope.component.interfaces.ComponentLookupError: ((1, 1), InterfaceClass __main__.ITest, u'') Oh dear, what have I done wrong here? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wildcard adapter
Tres Seaver wrote: provideAdapter(adapter,adapts=(None,None),provides=ITest) getMultiAdapter((1,1),ITest) Traceback (most recent call last): ... zope.component.interfaces.ComponentLookupError: ((1, 1), InterfaceClass __main__.ITest, u'') Oh dear, what have I done wrong here? The order of your adapter registration is *one*, Does the following not register for an order of two? provideAdapter(adapter,adapts=(None,None),provides=ITest) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] wildcard adapter
Marius Gedminas wrote: BTW passing interfaces to provideAdapter/adapts is out of fashion. This stuff is getting almost perl-ish in it's there's many ways to do it, pick the style you like nature.. I prefer using zope.component.adapts and zope.interface.implements (or zope.component.adapter and zope.interface.implementer, when my adapter is a function rather than a class). I often register the same adapter factory for several different types or objects / interfaces. How would I do that with your favoured spelling? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wildcard adapter
Philipp von Weitershausen wrote:
If it is, then which of the following should I use to register a
generic adapter for any single object to an interface:
provideAdapter(...,adapts=(None,),...)
This one.
Given that you can register adapters for any class, whether or not it
implements any interface, this doesn't work as it should:
from zope.component import provideAdapter
def adapter(*args): pass
...
from zope.interface import Interface
class ITest(Interface): pass
...
provideAdapter(adapter,adapts=(None,),provides=ITest)
ITest(1)
Traceback (most recent call last):
...
TypeError: ('Could not adapt', 1, InterfaceClass __main__.ITest)
class test: pass
...
ITest(test())
...
TypeError: ('Could not adapt', __main__.test instance at ...,
InterfaceClass __main__.ITest)
I have no idea what a generic adapter is, but the zope.component API
docs (== interfaces) are certainly complete in this sense. There are
also doctests.
Where can I find the docs and interfaces you mention above? I looked
through both zope.interface and zope.component and obviously missed them :-(
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Idea: Failure to lookup adapters
Philipp von Weitershausen wrote: Code like this won't be run with python -O (which is what you'd obviously use in production). obviously... not. How many people actually do this? I wonder whether a different approach could be taken. The APIDOC code does already a registration analysis. Maybe we can use the registrations in a away that they simulate the adapter registry. Thus you could provide APIDOC (via the Web UI or Python) with a component or instance and it tells you how it tries to look up the adapter. Clearly that would be much slower, but okay for inspection. Sounds good. I like the explainAdapter() suggestion. Me too... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] wildcard adapter
Hi All, I was wondering if someone could give me a definitive explanation of what the following means: adapter for=* ISomething * ... ...means? Is the following equivalent: provideAdapter(...,adapts=(None,ISomething,None),...) ? If it is, then which of the following should I use to register a generic adapter for any single object to an interface: provideAdapter(...,adapts=(None,),...) provideAdapter(...,adapts=None,...) I'm not having a lot of joy registering generic adapters so I thought I'd come and check my understanding here ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
Martijn Faassen wrote: That's what I do too... See my post elsewhere in the thread for an example of why this is Not Good. Luckily Twiddler is still less than version 1.0 ;-) When someone reports it as a bug, I'll fix it. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Idea: Failure to lookup adapters
Stephan Richter wrote: My major concern is speed here. Any debug handling will make the registry slower; I am using adapters very heavily in my code and any slow-down of one lookup would be multiplied many times. + sys.maxint. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode
Dieter Maurer wrote:
A halfway intelligent parser would accept Unicode when it gets it
and concentrate on the remaining part of its task: either reporting
structural events or building a parse tree.
The trivial fix I use in Twiddler is as follows:
if isinstance(source,unicode):
source = source.encode('utf-8')
Of course, this assumes a heading of either ?xml version=1.0
encoding=utf-8? or a missing encoding attribute, in which case the
xml spec states that the string must be utf-8 encoded.
The problem comes when someone sends you something like:
u'?xml version=1.0 encoding=something-else?node /'
What should be done then?
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote: None of this should be taken as any sort of edict. I'm also not trying to name anything. While I'd love to spur discussion, I hope not to start any arguments. :) On that front, I'll note that I've seen 3 patterns emerge in the projects I work on: 1. Development: lots of distinct projects per machine, each using their own zope version, products and/or python libraries, and data. For me, the Zope 2 instance home model and Zope software installed in, for example, /zope/2.9.5, works perfectly 2. Production with multiple projects in an instance. Here's there are often multiple websites mapped through an Apache front end to several data sets / software sets, each in their own folder. This is the class Zope 2 model where each site uses a combination of products, zodb scripts and templates and data stored in objects within the top level folder. Again the Zope 2 instance home model works well for this, but you only tend to end up having one instance on the box, so maybe it'd be easier on sysadmins and the like if things were different in this case, although I find having everything in a sub-tree of the file system pretty compelling. 3. Large production setups with one project spread over multiple machines. Each machine has a set role, usually involving several almost-identical app servers. I think this is the case you cover well and I completely agree with the things you've said. Have other people experienced these patterns? If so, which do we want to support and how? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] using zope.testing without zope
Jim Fulton wrote: The easiest way is with the buildout zc.recipe.testrunner recipe. There are lots of examples of this in the repository, including ZODB, zc.buildout, zc.ngi, zc.recipe.rhrc, among many others. Are there high level docs for building things out like this? I'm somewhat intimidated by the whole buildout/eggs/distutils thing :-S Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Dieter Maurer wrote: Someone already worked on this and reported success. He integrated a ZEO client via mod_python. Yep, that was Philipp. I wonder where that project ended up? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
Martijn Faassen wrote: Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. I've really grown to hate attribute-based languages over the years. Macros in ZPT now make me cry. If we're going to get out of the server business we could also consider getting out of the template language business. :) Well, as someone who's got myself firmly into the template language business, I'd agree. That said, I'm pretty passionate about Twiddler. It's now feature complete and if people can give me metrics showing that it's slow or has bugs, I'll be pretty eager to fix them. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Martijn Faassen wrote: It would be very nice if we could make that work! Zope as a drop-in Apache extension would certainly help wider adoption. Yes indeed :-) We're not a normal pythonish Apache thing though, 'cos we need to rigidly limit the number of app server threads because of the zodb object cache. That said, I'm pretty sure Apache could be tickled to support this... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Jim Fulton wrote: Does the Zope 2 server need that much work? It seems to do a pretty good job... I don't know. It does seem to do a pretty good job. But I'm not aware of any one else who's in a position to fix it if it breaks or needs to be enhanced. Anyone else apart from who? I'm sure if there was a need, volunteers (or people made volunteers out of necessity) would likely soon dive in... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Jim Fulton wrote: We have performance and reliability expectations which come from running mission-critical applications. Lots of the rest of the folks interested in servers don't have those requirements (yet, anyway), and hence aren't motivated to address them in their externally-maintained server implmentations. I find it impossible to believe that others don't have such mission-critical requirements. Maybe they hand off the hard bits too Apache? Could we? If we find that WSGI is inferior to the Zope 2 server, then I certainly think that abandoning our various Zope 3 efforts is a reasonable alternative, although unattractive, since I'm not aware of anyone actively maintaining the Zope 2 server. I'd much rather leverage a larger effort. Does the Zope 2 server need that much work? It seems to do a pretty good job... What's stopping Zope 3 from using it? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Core topic in Collector
Jim Fulton wrote: Chris Withers wrote: Jim Fulton wrote: The Zope3 collector isn't actually *that* bad in this respect. IMO, it could do without the topic and version info fields. Topic I'd agree with, but I would have thought version info would be pretty useful? Sure, but it could go in the description along with all of the other information needed to reproduce the problem. I thought the idea of a seperate field was to make it a mandatory dropdown so that at least we know what version of Zope the reporter is using... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Core topic in Collector
Jim Fulton wrote: The Zope3 collector isn't actually *that* bad in this respect. IMO, it could do without the topic and version info fields. Topic I'd agree with, but I would have thought version info would be pretty useful? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Martin Aspeli wrote: Why can't IView (or whatever it is) just specify that the constructor must accept a request, response and a template instance? Because the template may not be passed in, and even if it is, where would it be constructed and how would it be found again? See my currying comment later in the thread. then you may as well not have a 'template' attribute for browser:page If you have it done in ZCML, though, you can get a template-only view without any Python at all, though: browser:page for=* template=mytemplate.pt name=my_view permission=zope.Public / yeah, but I'm talking about the horrificness that currently makes the above work. I'm asking whether it really needs to be that bad or whether it could be more sanely implemented. I guess I should just make a branch and have a play or stfu... The later is likely to win due to lack of time *sigh* Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Martijn Faassen wrote: Chris Withers [EMAIL PROTECTED] wrote: Martijn Faassen wrote: class TemplateView(grok.View): template = unassociated module_info = module_info_ I'm not sure. Debugging becomes a nightmare with generated classes, which is how I ran into these problems in the first place. Can you explain what the what the above code snippet actually does? It generates a view for a template file that doesn't have its own view. Okay, but isn't this just a currying problem? If so, there's all the usual python currying solutions, here's one... class ViewFactory: implements(IView) def __init__(self,klass): self.template = PageTemplateFile(klass.template_name) self.klass = klass def __call__(self,context,request): return self.klass(template,context,request) class MyView: template_name = '' provideAdapter(ViewFactory(MyView),(IContext,IRequest),IView) Possibly. It's not that bad right now. The difficulty is that I do need to generate a class, not an instance, as I can only initialize the instance when the view is initialized because the context and request are needed. There's something to be said for circumstances where creating an adapter each time it's asked for is sub-optimal, but I don't have a good enough feel for the problem in its generic sense to make any suggestions... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope3 instance with no zodb
Jim Fulton wrote: Yes. You have to configure an alternate publication object. Okay, any clues how to do that? Where's the default configuration done? What interfaces do I need to implement? Launchpad does this. Cany any Launchpad'ers present tell me where to look in your source repository? other things, controls object traversal. The default publisher uses a database object as a starting point for traversal. An alternate publisher could use something else, including allowing multiple root objects. Cool :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Martijn Faassen wrote: dynamically generated class for templates that don't have classes of themselves. I know you were there when we created this one. :) class TemplateView(grok.View): template = unassociated module_info = module_info_ of course the instances of this class do nothing the developer has to interact with. As soon as the developer provides a view class of their own, there's no dynamically generated class anymore. I think that this is an acceptable use of the pattern. I'm not sure. Debugging becomes a nightmare with generated classes, which is how I ran into these problems in the first place. Can you explain what the what the above code snippet actually does? I've done it too recently in the form support. The *real* formlib-level form class is dynamically created for each grok-level form: class RealEditForm(form.EditForm): form_fields = get_form_fields(factory, context) actions = actions_ This one is a bit more scary, as the end-user interacts with an *instance* of this class; the form attribute on grok-level forms is one. There must be a nicer way :-S cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope3 instance with no zodb
Martijn Faassen wrote: Quite a few bits and pieces of Zope 3 also depend on there being a __parent__, including the default security policy. You may therefore either need to establish such a __parent__ relationship, or write a new security policy. I hope this is all documented in interfaces? Chris, when you finish doing this please document it so it'll be an of course for the rest of us too. :) Sure, where would be the best place to put this doc? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Jim Fulton wrote: If you want to specify the name of a template in ZCML, then you'll have to invoke some magic. Why can't IView (or whatever it is) just specify that the constructor must accept a request, response and a template instance? Now I'll go back to ignoring this thread, the desire to do so increased by the sort of extreme over-simplifying remarks made. Not sure what you mean by this... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope3 instance with no zodb
Hi All, I remember Shane asking this a while ago and seem to remember the answer was no, but I'm hoping that's changed. Is it possible to have a Zope 3 instance that has no zodb backing at all? I've been mocking up an app, currently in Zope 2, and have ended up using PostGresSQL as the data store (haven't done an rdb app in ages, foreign key constraints are nice, etc) and it occurred to me that with sqlalchemy, zsqlalchemy and some views that I don't actually need a zodb. Is this possible? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?
Dieter Maurer wrote: The str example shows also that it is not sensible that the adapter registry framework gives the adapter (factory) a way to determine its name (str has nothing where the name could be sticked in). True enough, I guess I'll just have to stick with my hack or Tres' currying suggestion... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?
Benji York wrote: Chris Withers wrote: I don't think it'll be a common pattern, but it doesn't feel right to me that a named adapter (ie: one registered with a specific name) has no way of finding out what name it has been registered with... Because the same adapter can be registered more than once, it would actually need to find out all the names with which it was registered. Really? Now this is a use case I hadn't thought of.. can you give me some examples of where you've run into this? This seems somewhat analogous to a Python object being given multiple names. In that case too, there is no way for the object to know what it's names are. Hmmm, okay, but I'd counter with both Zope 2 and Zope 3 having the notion of an object knowing its own name. Certainly in Zope 2, everything has an id or .getId(). That pattern evolved for a reason ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Can an adapter find out what name it was registered for?
Tres Seaver wrote:
for name in ('vindaloo', 'madras', 'tiki_masala'):
globals()[name] = MNA_factory_maker(name)
and then in ZCML:
adapter for=.interfaces.IChicken
provides=.interfaces.ICurry
name=vindaloo
factory=.adapters.vindaloo /
...but here you have to specify the same info twice and hence duplicate
info and get it identical in two places, which feels icky to me.
Is there a python-only way to register adapters instead of in ZCML and,
if it exists, is it safe to use in conjunction with the normal zcml dances?
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?
Stephan Richter wrote: On Friday 17 November 2006 03:43, Chris Withers wrote: What do you suggest I do when the adapter needs to know the name it was registered for? You can make the name part of the adapter API. Not sure what you mean by this? However, I would suggest revising the design; I have never come across a scenario where I wanted the name of the adapter be known within the adapter. This seems to be a recipe for trouble. I don't think it'll be a common pattern, but it doesn't feel right to me that a named adapter (ie: one registered with a specific name) has no way of finding out what name it has been registered with... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
Tres Seaver wrote: We were discussion a (notional) value adapter, whose factory would have the contract of returning an object of a specific concrete type, rather than on implementing an interface. Right, but the CA supports the use of classes instead of interfaces and that works just fine here... There are reasonable usecases for such adapters, but the CA machinery doesn't permit registering them: it requires that the 'provided' argument be either an interface or None (although the 'required' args can be concrete types). Nah, for both provides and adapts classes can be used in place of interfaces just fine, and I've got this working just how I want it now :-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Dieter Maurer wrote: As Chris example demonstrates, it would have been better to call IZopeDublinCore(myobj) the IZopeDublinCore adaptation of myobj. Agreed, and would have saved me a lot of confusion. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Philipp von Weitershausen wrote: browser:view Note: browser:view always creates new classes on the fly. evil browser:page Registers an adapter where the second adapted object defaults to IBrowserDefaltLayer. Always creates a new class on the fly and mixes in functionality that makes the adapter a *publishable view*. evil. I'm sick of ZCML and its magic and its inconsistency. The typing and the pointy brackets I could live with... ME GROK SMASH ZCML. Yeah, ZCML is the new acquisition :-( It's sad that one of it's main selling points (the ability to turn off configuration made in another package) was never implemented :-( That said, I can live with most of the crap, but these dynamically generated classes... wtf? why? why did that? why are they still breathing?! Whatever happened to explicit is better than implicit et al? I'm trying to register an adapter in such a way that I can do the following in a page template: p tal:content=structure someobj/@@render/ Which of the myriad flavours of view registration should I be using? Inherit from BrowserView Everyone says this, but why is it a good idea? I want these things to be _really_ light, they're going to be used a lot in every page render... and use either a simple adapter / or a view / or a browser:view / directive to register it. Note that this thing won't be publishable via the URL then (which is probably what you want). Correct. Also, why, when zope:view is described as a synonym for zope:adapter, does zope:view support an allowed_attributes attribute, while zope:adapter does not? zope:adapter assumes the provides interface as the allowed_interface. *sigh* Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote: Not sure what official terminology glossary you're basing this on, but we often refer to IZopeDublinCore(myobj) as the IZopeDublinCore adapter of myobj. Whatever is called to instantiate that object we call the adapter factory or adapter implementation. The whole zope.component API (both registration and lookup) reflects this use of the terminology. Right, I see where you're coming from now, and I have to agree with Dieter. IZopeDublinCore(myobj) is not an adapter. It is an instance of the adapter or the adapted object, depending on your point of view. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote: IZopeDublinCore(obj) is a flexible version of ZDCAnnotatableAdapter(obj) Flexible, because a different implementation that ZDCAnnotatableAdapter might be used. That's dispatched through the adapter registry. Right, exactly. IZopeDublinCore(myobj) does an adapter lookup based on the type of 'myobj' That's the lookup in the registry (part 1 of the adapter call) and returns an adapter instance with myobj as context, ready to be used. That's the instantiation a la str(123) (part 2 of the adapter call) Ah, I think this is becoming clearer... So, as another example, I could register the following as a factory for turning instances of DateTime instances into datetime instances: def convert_dates(date): return datetime(year=date.Year(),month=date.Month(),day=date.Month()) The important thing here, for me, is that the adapted value is not an instance of the adapter factory. Am I getting this now? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Jean-Marc Orliaguet wrote: once you have that utility / adapter you should be able to call it like: converter = getAdapterFor(123, type=IToStringConverter) strResult = converter.convert(123) Not quite, what I'm looking to do is more along the lines of: mystr = getAdapter(123,str) (where str is the interface I'm looking for here) PS: calling '123' an adapter is really bending concepts. Yes, this is a mistake, I believe this should always be referred to as the adapted value or the suggestion Dieter made... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] adapter registration - sort of works :-S
Hi All,
Chris Withers wrote:
Jean-Marc Orliaguet wrote:
once you have that utility / adapter you should be able to call it like:
converter = getAdapterFor(123, type=IToStringConverter)
strResult = converter.convert(123)
Not quite, what I'm looking to do is more along the lines of:
mystr = getAdapter(123,str)
OK, less talk, more do... and when I stop worrying about it, it all gets
very easy:
from zope.component import provideAdapter
provideAdapter(str,(int,),str)
from zope.component import getAdapter
getAdapter(123,str)
'123'
Yay! That's _exactly_ what I want. Although it does suggest that 'adapt'
should be provided as an acronym for 'getAdapter'.
Anyway, now all excited, I tried this:
def to_date(value):
... try:
... return DateTime(value)
... except:
... return None
...
provideAdapter(to_date,(str,int),DateTime)
getAdapter('2006/11/16',DateTime)
Traceback ...
...
zope.component.interfaces.ComponentLookupError:
('2006/11/16', class DateTime.DateTime.DateTime at 0x00E73600, u'')
wtf?
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration - sort of works :-S
Philipp von Weitershausen wrote:
from zope.component import provideAdapter
provideAdapter(str,(int,),str)
from zope.component import getAdapter
getAdapter(123,str)
'123'
Yay! That's _exactly_ what I want.
And that's exactly what I meant -- and wrote about half way up the
thread. :)
Yeah, but the words were wrong, so I didn't grok it.
A simple example as above would probably have done it ;-)
provideAdapter(to_date,(str,int),DateTime)
This registers a multi adapter for (a_string, an_integer), like views
are multi-adapters for (context, request). You want to say:
provideAdapter(to_date, (str,), DateTime)
provideAdapter(to_date, (int,), DateTime)
A... okay, I had to guess from this:
help(provideAdapter)
Help on function provideAdapter in module zope.component:
provideAdapter(factory, adapts=None, provides=None, name='')
provideAdapter(str,int,str)
Traceback...
...
TypeError: iteration over non-sequence
I guessed the wrong use of the sequence :-(
Shame provideAdapter doesn't have a docstring ;-)
Okay, so now I can do what I want:
getAdapter('2006/11/16',DateTime)
DateTime('2006/11/16')
...except:
getAdapter('moo',DateTime)
Traceback...
...
zope.component.interfaces.ComponentLookupError:
('moo', class DateTime.DateTime.DateTime at 0x00E73600, u'')
I'm guessing this is 'cos my adapter is returning None and that's a
special value meaning couldn't adapt, right?
How would I _really_ return None from an adapter?
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] wading through zcml...
What's the difference between zope:view, browser:view, browser:page and browser:viewlet? I'm trying to register an adapter in such a way that I can do the following in a page template: p tal:content=structure someobj/@@render/ Which of the myriad flavours of view registration should I be using? Also, why, when zope:view is described as a synonym for zope:adapter, does zope:view support an allowed_attributes attribute, while zope:adapter does not? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] wading through zcml...
Martin Aspeli wrote: Chris Withers wrote: What's the difference between zope:view, browser:view, browser:page and browser:viewlet? I would strongly encourage you to buy Philipp's book when the second edition comes out, and read some of the available existing documents (e.g. worldcookery.com, the Zope 3 wiki thingie). I'm a strong reader of Philipp's book(s) but they don't go into enough detail here... zope:view / is deprecated, I believe, an old spelling for adapter / before adapter / could do multi-adapters. See my previous complaint, they have totally different signatures, I don't see how one can be deprecated in favour of the other. browser:view / is about registering a new view, typically one that doesn't render a page (so think of it analogous to where you may use a Script (Python) in Zope 2) What's the difference between a page and not a page in your mind? browser:page / is about a view typically with an associated template that renders something for the user Then why is the macros view in the following example registered as a page: http://wiki.zope.org/zope3/SimplifyMacroRegistration ? browser:viewlet / is about building viewlets, which are small chunks of HTML that are aggregated into a browser:viewletManager /. The DocTest in zope.viewlet explains it all. Sounds like this is worth a look... I'm trying to register an adapter in such a way that I can do the following in a page template: p tal:content=structure someobj/@@render/ You would use a browser:view with a class deriving from BrowserView (Products.Five.browser.BrowserView) Why do I need to subclass BrowserView? I looked through the code and can't really see what this adds... As I've said before, I don't care about the request, and really don't like the magic appearance of both the request and context attributes. That said, looking at the actual object I appear to get as the view, I'm deeply scared to see so much magic going on (wtf is a Products.Five.metaclass?!) and did its magic in the __call__ method i believe. A more common pattern would be to have a method on the view render that you call: tal:define=renderView someobj/@@render tal:content=structure renderView/renderTheData This all feels way to heavyweight. My IRender has exactly one method, and a lot of objects will be getting rendered on each page... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Can an adapter find out what name it was registered for?
Hi All, Can a named adapter find out the name it was registered with during the adaptation process? This is the only way I can think to do it, but results in the thing calling methods on the adapter passing in the name to every method call to get the information across, which seems a bit clunky to me: for name,adapted in getAdapters((someobj,),ISomething): adapted.doSomething(name) Other ideas greatfully received! cheersm Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote:
...hence the quotes. It's a function in that I want to use it as an
adapter that doesn't need to be instantiated by a factory before being
used.
All adapters need to be instantiated.
Why?
def myStrAdapter(something):
return str(something)
This function adapts strings to integers, why would it need to be
instantiated?
No. You always register a factory which is called upon lookup. That's
because adapters are context-dependent and thus need to be instantiated
every time you look them up.
What if they're not context-dependent as in my example above?
ultimately, I'm looking to replace code like the following:
convertors = {
int:{str:str,datetime:datetime},
str:(int:int,datetime:datetime},
}
def convert(x,y):
return convertors[type(x)][type(y)](x)
...if you see what I mean. Apologies for the trivial examples, but these
are real problems...
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote: Chris Withers wrote: Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a function and a class Nope. It's a class since Python 2.2. ...hence the quotes. It's a function in that I want to use it as an adapter that doesn't need to be instantiated by a factory before being used. Right, as an *input* of the adaption it's ok just to specify a class. But the output obviously always has to be specified by an interface. Otherwise the whole point of using of adaption is perverted... Not really. It's the ability to register the adapter, and change which adapter you choose to use that's important for me here. I think it should be fine to adapt to a class if you can adapt from a class. Is there anything in the implementation that actually prevents this? (which I, for one, would consider a bug) should be: provide=str Wtf? Then why do you need an adapter? See above. I thought you wanted to say IString(1) instead of str(1) to be more flexible...? Hmm, I see your point, but there are other ways to get an adapter than by calling an interface ;-) (and I think I'd need to use those here, since there is no interface) ...and factory=str is wrong for the reasons given above, or, put differently, because str()(1) will tell you that strings aren't callable ;-) Huh? You got that wrong. IString(1) will call str(1) if provideAdapter(str, (int,), IString). right, but factory= registers and adapter factory, not an adapter and provideAdapter registers an adapter directly, correct? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
Tres Seaver wrote: Heh, in this case using 'IString' is really a trussed duck (duck typing with BD) ;) Python's duck typing breaks down with strings, because they can by quack tested like sequences, but you almost *never* want to treat them the same way as other sequences, so you end up with 'isinstance(obj, basestr)' tests to prevent handling them that way. True, and I guess for my uses, I'd be wanting to register adapter both too and from basestr, since that'd cover unicodes too, unless that would be bad ;) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
whit wrote: hello RuleDispatch... What's RuleDispatch? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a function and a class 2. I was to register the function str as an adapter for, say, the class int to the class str, so there's not factory for the adapter, since it's a function Let's create a marker interface that promises everything that 'str' does: class IString(zope.interface.Interface): A marker for the 'str' interface. As discussed elsewhere, you shouldn't need the marker interface, as you can adapt classes. However, given the edge-case nature of this, I can believe there might be bugs to be found here... Now, you can setup your adapter like this: adapter for=int provides=.interfaces.IString factory=str/ Well, that's not right ;-) should be: provide=str ...and factory=str is wrong for the reasons given above, or, put differently, because str()(1) will tell you that strings aren't callable ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] adapter registration question
This is a toy example, but I need to do something similar and can't seem to get the registration right... How can I register the str builtin as an adapter from python int objects to python str objects? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] adaptation based on class rather than interface
Hi All, I find myself often having to define pure marker interfaces for each class that I define, purely so I can register adapters for objects of that class. How do people feel about: - being able to register an adapter as follows: adapter for=.myclasses.MyClass provides=.interfaces.ISomething factory=.adapters.MyAdapter / ..in addition to the normal registration for interfaces. - be able to adapt objects based on their class if no interfaces match: class MyClass: pass obj = MyClass() ISomething(obj) I'm expecting people to say NO! very loudly, but I'm interested in the real reasons for why this is bad. Having to define interfaces purely so an adapter can be registered seems tortological to me... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Jim Fulton wrote: adapter for=.myclasses.MyClass provides=.interfaces.ISomething factory=.adapters.MyAdapter / I think it is a fine idea. That's why it has been supported for a long time. You can register adapters and views (which, of course are adapters) for classes as well as interfaces. Yay! *sound of a million marker interfaces dying* Hmm, is this documented anywhere? Philipp, is this in the new edition of your book? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] layers can't be new style classes?
Hi All, It would appear that Philipp's article is somewhat misleading in that layers can't be new style classes... class MyLayer(object): def setUp(self): pass def tearDown(self): pass ..results in the following when used as a layer: AttributeError: type object 'object' has no attribute 'setUp' Is this a bug in Philipp's article or in the testrunner? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
Stefan H. Holek wrote: IIRC you need @classmethod def setUp(cls): pass @classmethod def tearDown(cls): pass Sorry, braino on my part. Yes, I have the @classmethod's and I still see the error: AttributeError: type object 'object' has no attribute 'setUp' cheers, Chris PS: Has anyone doen the work Philipp aludes to in his article to make ZopeTestCase a series of layers? -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Martin Aspeli wrote: Layers are ... layered. If your test base class has layer X and a test case subclass of that has layer Y, then it will set up X, run all the X tests, then setup Y and run all the Y and XY tests, then tear down Y and then X. I didn't mention subclassing tests. Personally, I think that's evil... I did this in Plone recently, but it completely escapes me where. Maybe I'll have an epiphany after lunch, but look at how the ZCML layer in PloneTestCase trunk works (it sets up all kinds of ZCML) and then try to derive a class from PloneTestCase (or your equivalent) and set layer = myLayer. What layer(s) would the following test be executed in: class BaseX(TestCase): layer = 'X' class BaseY(TestCase): layer = 'Y' class SomeTests(BaseX,BaseY): def test_1(self): pass cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Jim Fulton wrote:
Am I right in assuming that there aren't any good narrative docs for
test layers?
This is obviously in the eye of the beholder. I'm sure the people
who created narratives tried to do a good job. Perhaps you can do better.
I may be missing some then... which narratives are you thinking of?
And yes, I'm hoping to do better unless I've just missed some existing
docs...
I've attached a test file which opened my eyes... how do I go about
weaving this into a doctest?
Now, related to this, say I have content objects X and Y, which are
expensive to set up. I have LayerX which sets up a sample content
object X, and LayerY which does the same for content object Y. This is
fine for tests which need one or other content type, but how do I
write tests which need both?
You create a layer that extends both.
How so?
Here's a sample of why I'm struggling:
class ZODB:
@classmethod
def setUp(cls):
... open zodb connection
... begin transaction
@classmethod
def tearDown(cls):
... abort transaction
... close connection
class LayerX(ZODB):
@classmethod
def setUp(cls):
cls.savepoint = transaction.savepoint()
... create X instance
@classmethod
def tearDown(cls):
cls.savepoint.rollback()
class LayerY(ZODB):
def setUp(cls):
cls.savepoint = transaction.savepoint()
... create Y instance
@classmethod
def tearDown(cls):
cls.savepoint.rollback()
class MyLayer(LayerX,LayerY): pass
class MyTests(TestCase):
layer = '.MyLayer'
def setUp(self):
self.savepoint = transaction.savepoint()
def tearDown(self):
self.savepoint.rollback()
def test_1(self):
pass
Basically, will the above work or will the savepoints become a horrible
jumbled mess and I end up with several ZODB connections as well?
cheers,
Chris
PS: can I use '.MyLayer' as a layer, or do I always need to put the full
dotted path in?
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
from unittest import TestSuite, makeSuite, TestCase
class MyLayer:
@classmethod
def setUp(self):
# do something here
print 'L1 setup'
print self
@classmethod
def tearDown(self):
# undo it here
print 'L1 teardown'
class MyExtendedLayer(MyLayer):
@classmethod
def setUp(self):
# do additional stuff here
# don't call super
print 'L2 setup'
@classmethod
def tearDown(self):
# undo it only the additional stuff here
# don't call super
print 'L2 teardown'
raise RuntimeError('fubar MyExtendedLayer.tearDown')
class T1(TestCase):
layer = 'Products.MyProduct.tests.test_layers.MyLayer'
def setUp(self):
print T1 setup
def tearDown(self):
print T1 teardown
def test_1(self):
print 'T1.1'
def test_2(self):
print 'T1.2'
def test_3(self):
print 'T1.3'
raise RuntimeError('fubar T1.test_3')
class T2(TestCase):
layer = 'Products.MyProduct.tests.test_layers.MyExtendedLayer'
def setUp(self):
print T2 setup
def tearDown(self):
print T2 teardown
raise RuntimeError('fubar')
def test_1(self):
print 'T2.1'
def test_2(self):
print 'T2.2'
def test_3(self):
print 'T2.3'
raise RuntimeError('fubar T2.test_3')
class T3(TestCase):
def setUp(self):
print T3 setup
raise RuntimeError('fubar')
def tearDown(self):
print T3 teardown
def test_1(self):
print 'T3.1'
def test_suite():
suite = TestSuite()
suite.addTest(makeSuite(T1))
suite.addTest(makeSuite(T2))
suite.addTest(makeSuite(T3))
return suite
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
Jim Fulton wrote: A layer is simply an object that has __module__, __name__, and __bases__ attributes and that has setUp and tearDown methods. That's it. You can achieve that any way you want. I regret the use of the __bases__ attribute. It would have been better if I had left it up to layer implementations to call base layers, rather than having the test runner call them automatically. It was a bad automation tradeoff. Is it too late to add an explicit Layer class to zope.testing that deals with this properly rather than confusing n00bs like me? (even if it does involve some BBB if/then/else'ing in testrunner.py...) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] another layers quicky?
Hi (yet) again ;-) class MyLayer: @classmethod def setUp(self): self.app = Testing.ZopeTestCase.Zope2.app() @classmethod def tearDown(self): Testing.ZopeTestCase.close() class MyTests(TestCase): def setUp(self): self.savepoint = transaction.savepoint() self.app = makerequest(?.app) def tearDown(self): self.savepoint.rollback() ... What do I put in place of the ? to get hold of the layer's app? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
Jim Fulton wrote: I may have spoken too soon. It looks like there is code to handle the object-as-base case in the test runner, at least on the trunk. Perhaps the version used by zope3 doesn't handle this case, or perhaps there's a bug that needs to be pursued. That'd explain it, I'm using 2.9.4 ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Jim Fulton wrote: I may be missing some then... which narratives are you thinking of? You cited 3 in your note. I'd like there to be a good narrative that actually ships in zope.testing, I'm willing to do the work to make that happen provided I can get some help on writing the doctest of zope.testing that's required... You create a layer whose __bases__ include LayerX and LayerY. If you're layers happen to be implemented as classic classes, you then could use subclassing. What happens with new style classes? Basically, will the above work or will the savepoints become a horrible jumbled mess and I end up with several ZODB connections as well? That's a good question. I was afraid you'd say that ;-) Looking at the code on the zope.testing trunk, it looks like this should work. I'll give it a try with Zope 2.9 then... if you hear my screams of pain from across the atlantic, you'll know something hasn't worked right... PS: can I use '.MyLayer' as a layer, or do I always need to put the full dotted path in? You have to use a full dotted path. You can also use the Layer object itself. Ah, didn't know you could use the Layer object itself... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: layers can't be new style classes?
whit wrote: there is also a version of ztc by layers for 2.9(see zope2 branches) Which branch exactly? I'm using 2.9.4 and can't see any evidence of layers... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
