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
[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: 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: 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
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
Jim Fulton wrote: Any release tagged as "alpha", "beta", "rc", "pre", or with an SVN revision. I agree with Tres' goal. I think setuptools refers to those as "pre-release tags". And I think anything that has a pre-release tag should be considered unstable. SVN revisions are provided as post-release tags. wow, that's not good... If I'm running a production setup, I'd be mortified if upgrading a library with setuptools suddenly pulled down a load of pre or post release eggs :-S I know buildout lets your feeze egg version numbers, but not doing silly things seems like something setuptools should do ;-) 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
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
[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
[Zope3-dev] new www.zope.org?
On 24.05.2007, at 18:01, Stephan Richter wrote: >> The features within the ``jquery`` and form packages will soon be demonstrated in detail on the new www.zope.org website, which will also be available in code form as ``z3c.website``. So stay tuned! Apologies for the off-topic-ness... there's a new website on the way? Cool! Where can I find out more? 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: System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
Tres Seaver wrote: - Squid3 for ESI. Wow, you actually succeeded to get Squid3 to compile? ;-) 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"
Fred Drake wrote: On 5/11/07, Chris Withers <[EMAIL PROTECTED]> wrote: I dunno, do we actually need an "offical big zope 3 release" anymore? No. What's more, we don't even want to use one anymore. cool :-) My only slight concern here is when people make changes in one satellite project, they break another one and don't realise. But I guess the buildbot should catch that, right? The value of the big release is more for people who are new to Zope 3, and want to take a look. That's not an audience I'm good at judging, either in terms of guessing what they really want, or in what makes them take that first look. Indeed, I'd suggest this is a market best persued by apps like Grok. 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: ...however the getMultiAdapter call still failed with a ComponentLookupError :-( I had to change the registration as follows: ...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] 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] what dependency to use for "zope 3"
Hi All, As a newcomer to the world of setuptools, I'm excited by the prospect of automatic dependency handling. However, with the eggification of Zope 3, this leaves me wondering: if I have a package that relies of a certain version of Zope 3, what do I put in as the dependency in setup.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] testing for configuration loading and skeleton?
Hi All, Where can I find tests that check zope.conf.in and the zconfig schema in zope 3? I'm looking for the equivalent of the tests in Zope2.Startup.tests.test_schema... 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
[Zope3-dev] running zope.testing tests on Windows
Hi All, I tried to run the test for zope.testing on Windows, I got errors (see the attached .txt file for the whole session) Am I doing something wrong or are these genuine failures on Windows? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk C:\LocalSVN\zope.testing\src>python ..\test.py -m zope.testing Running unit tests: Failure in test ..\src\zope\testing\testrunner-edge-cases.txt Failed doctest test for testrunner-edge-cases.txt File "..\src\zope\testing\testrunner-edge-cases.txt", line 0 -- File "..\src\zope\testing\testrunner-edge-cases.txt", line 83, in testrunner-edg e-cases.txt Failed example: try: testrunner.run(defaults) finally: sys.stdin = real_stdin Expected: Running unit tests: --Return-- > ...->None -> pdb.Pdb.set_trace(self) (Pdb) n > testrunner-ex/sample3/sampletests_d.py(NNN)f() -> y = x (Pdb) p x 1 (Pdb) c Ran 1 tests with 0 failures and 0 errors in N.NNN seconds. False Got: Running unit tests: --Return-- > ...->None -> # [XX] Normalize with respect to os.path.pardir? (Pdb) n > testrunner-ex/sample3/sampletests_d.py(NNN)f() -> y = x (Pdb) p x 1 (Pdb) c Ran 1 tests with 0 failures and 0 errors in N.NNN seconds. False -- File "..\src\zope\testing\testrunner-edge-cases.txt", line 103, in testrunner-ed ge-cases.txt Failed example: try: testrunner.run(defaults) finally: sys.stdin = real_stdin Expected: Running unit tests: --Return-- > ...->None -> pdb.Pdb.set_trace(self) (Pdb) n > (3)...() -> y = x (Pdb) p x 1 (Pdb) c Ran 1 tests with 0 failures and 0 errors in N.NNN seconds. False Got: Running unit tests: --Return-- > ...->None -> # [XX] Normalize with respect to os.path.pardir? (Pdb) n > (3)?() -> y = x (Pdb) p x 1 (Pdb) c Ran 1 tests with 0 failures and 0 errors in N.NNN seconds. False -- File "..\src\zope\testing\testrunner-edge-cases.txt", line 124, in testrunner-ed ge-cases.txt Failed example: try: testrunner.run(defaults) finally: sys.stdin = real_stdin Expected: Running unit tests: --Return-- > ...->None -> pdb.Pdb.set_trace(self) (Pdb) n > (3)...() -> y = x (Pdb) p x 1 (Pdb) c Ran 1 tests with 0 failures and 0 errors in N.NNN seconds. False Got: Running unit tests: --Return-- > ...->None -> # [XX] Normalize with respect to os.path.pardir? (Pdb) n > (3)?() -> y = x (Pdb) p x 1 (Pdb) c Ran 1 tests with 0 failures and 0 errors in N.NNN seconds. False -- File "..\src\zope\testing\testrunner-edge-cases.txt", line 146, in testrunner-ed ge-cases.txt Failed example: try: testrunner.run(defaults) finally: sys.stdin = real_stdin Expected: Running unit tests: --Return-- > ...->None -> pdb.Pdb.set_trace(self) (Pdb) n > testrunner-ex/sample3/sampletests_d.py(NNN)f() -> y = x (Pdb) p x 1 (Pdb) c Ran 1 tests with 0 failures and 0 errors in N.NNN seconds. False Got: Running unit tests: --Return-- > ...->None -> # [XX] Normalize with respect to os.path.pardir? (Pdb) n > testrunner-ex/sample3/sampletests_d.py(NNN)f() -> y = x (Pdb) p x 1 (Pdb) c Ran 1 tests with 0 failures and 0 errors in N.NNN seconds. False -- File "..\src\zope\testing\testrunner-edge-cases.txt", line 196, in testrunner-ed ge-cases.txt Failed example: try: testrunner.run(defaults) finally: sys.stdin = real_stdin # doctest: +NORMALIZE_WHITESPACE Expected: Running unit tests: Error in test post_mortem3 (sample3.sampletests_d) Traceback (most recent call last): UnexpectedException: testrunner-ex/sample3/sampletests_d.py:NNN (2 examples)> exceptions.ValueError: > (1)...() (Pdb) p x 1 (Pdb) c True Got: Running unit tests: Error in test post_mortem3 (sample3.sampletests_d) Traceback (most recent call last): exceptions.ValueError: > (1)?() (Pdb) p x 1 (Pdb) c True -- File "..\src\zope\testing\testrunner-edge-cases.txt", line 230, in testrunner-ed ge-cases.txt Failed example: try: testrunner.run(defaults) finally: sys.stdin = real_stdin # doctest: +NORMALIZE_WHITESPACE Expected: Running unit tests: Error in test post_mortem4 (sample3.sampletests_d) Traceback (most recent
Re: [Zope3-dev] Re: Grok sprint 2 reports
Tres Seaver wrote: With something like meld3, we could even get rid of the hairy TALES expressions in the tmeplates, making them purely the domain of the designer. Of course, I'd punt Twiddler into that mix... Gary Poster seems to have taken a shine to it, and I'll do anything I can to get other people to take a look at it, and improve any shortcomings they find... 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 ?
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: 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: 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? 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: 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? 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: 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: 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] Re: zope.app.twisted.main?
Philipp von Weitershausen wrote: Chris Withers wrote: 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? mkzopeinstance creates a twisted instance mkzopeinstance --zserver creates a zope.server instance Surely this should be an option in zope.conf, not hard-wired into the runzope script? Would anyone object if I did some experimental work on a branch to: - make twisted/zserver interchangeable through a zope.conf setting - making zodb "optional" - refactor so that as much code as possbile is shared between zope.app.twisted.main and zope.app.server.main - explore ways of seperating some of the publication concerns 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] 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
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
[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
[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
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: 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?
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
[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: 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
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
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] 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
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
[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=71011&view=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
[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), , 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] 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), , 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
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: 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
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, )
>>> class test: pass
...
>>> ITest(test())
...
TypeError: ('Could not adapt', <__main__.test instance at ...>,
)
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] wildcard adapter
Marius Gedminas wrote: BTW passing interfaces to provideAdapter/ 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] 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
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
[Zope3-dev] wildcard adapter
Hi All, I was wondering if someone could give me a definitive explanation of what the following means: 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
Philipp von Weitershausen wrote: u'' What should be done then? Not sure. We could ignore it or raise an error. I'm inclined to ignore it. That's what I do 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: 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 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''
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
[Zope3-dev] using zope.testing without zope
Hi All, Does anyone have any experience of using zope.testing outside of Zope? I use zope.testing.doctest for the Twiddler tests and I'd like to use zope.testing.testrunner for running the tests in a "plain python" environment. In particular, I'd like to see if all the Twiddler tests pass under Python 2.5. What version of zope.testing should I use and how should I actually kick off zope.testing.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] 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?)
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: 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?)
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: 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 If you have it done in ZCML, though, you can get a template-only view without any Python at all, though: 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] 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
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...
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] 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
[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: 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? I don't know that I have, but the component system doesn't preclude it so anything we come up with will have to take it into effect. I'll whisper yagni at this point in the same way someone no doubt did when deciding if named adapters should be able to discover the name they're registered with ;-) Sure, where "everything" is defined as content space objects, other objects more rarely. Really? Certainly in Zope 2, prettymuch every persistent objects needs to be getId()'able... 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:
...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?
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
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
Re: [Zope3-dev] Re: adapter registration question
Raphael Ritz wrote: Chris Withers schrieb: Tres Seaver wrote: [..] ...and yet it works fine in Zope 2.9.4 :-S The first 'provideAdapter' call raises an exeption because 'str' doesn't have an '__iro__'. I don't even know what an __iro__ is :-S Interface Resolution Order - I think at least. Compare this to the better known __mro__ (Method Resolution Order) which defines the order in which methods will be looked up on an object - usually determined by the object's inheritance tree unless you play dirty tricks with it. In any case, whatever code is assuming that this attribute is there probably shouldn't. Tres, do you want to file the bug or shall I? 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: 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 or a /> or a 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: Can an adapter find out what name it was registered for?
Philipp von Weitershausen wrote: Chris Withers wrote: Can a named adapter find out the name it was registered with during the adaptation process? Nope. I can see why it's that way, but it seems a shame and maybe even an oversight :-/ What do you suggest I do when the adapter needs to know the name it was registered for? 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
[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
[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] 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... is deprecated, I believe, an old spelling for before 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. 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? 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 ? is about building viewlets, which are small chunks of HTML that are aggregated into a . 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: 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] 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: 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] 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', , 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] 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', , 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 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
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
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:
...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
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
[Zope3-dev] Re: adapter registration question
Tres Seaver wrote: Heh, in this case using 'IString' is really a "trussed duck" (duck typing with B&D) ;) 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
