[Zope3-dev] Re: [Zope-dev] I'd lobe to merge the zope3-dev and zope-dev lists

2007-10-05 Thread Chris Withers

Jim Fulton wrote:


Any objections?

This would basically involve retiring the zope3-dev list and moving 
zope3 developers to the zope-dev list.


+1 from me :-)

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: [Zope-dev] I'd lobe to merge the zope3-dev and zope-dev lists

2007-10-05 Thread Chris Withers

Lennart Regebro wrote:

On 10/4/07, Michael R. Bernstein [EMAIL PROTECTED] wrote:

 This would basically involve retiring the zope3-dev list and moving
 zope3 developers to the zope-dev list.

+1


+1


What about retiring #zope3-dev IRC channel and only using #zope ?

No. #zope is roughly the equivalent of the main zope list. There is no
#zope-dev channel.


Renaming #zope3-dev to #zope-dev would make sense to me though.


+1 from me too :-)

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: RFC: Known working sets

2007-09-06 Thread Chris Withers

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

2007-09-06 Thread Chris Withers

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

2007-09-05 Thread Chris Withers

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

2007-09-04 Thread Chris Withers

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

2007-06-01 Thread Chris Withers

Tres Seaver wrote:

Another feature I'm not sure is already in setuptools:

  - I *don't* want dev releases to replace production ones
implicitly:  no package should be able to install a non-released
version without explicit callout.  If this isn't already the
default behavior, then I'd like syntax for spelling it.


+lots... I haven't been paying huge amounts of attention, but I've 
noticed what seemed to be a few people complaining about dev eggs 
stomping on their production eggs :-S


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: How to deal with major versions?

2007-05-31 Thread Chris Withers

Jim Fulton wrote:


I don't see how this helps one say that they want to depend on a minimum 
version of a major version.  That is, how does it prevent dependencies 
like:


foo =1.0 1.999

?

I'm wondering how Gentoo got *that* right.


I wonder if the package should have something in it's setup.py that says 
I won't be compatible with anything expecting version 2.0 ?


This would end up as metadata on pypi or in the egg/.tar.gz and 
setuptools could do the hard work of resolving the dependencies...


It also removes the burden of specifying maximum revision numbers on the 
consuming packages and puts it where it belongs: on the maintainer of 
the package who knows if it's going to be backwards compatible or not..


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: egg version numbers and zope releases

2007-05-31 Thread Chris Withers

Benji York wrote:
Even if developers remembered, it would be icky to have to spell out   
something like =3.4 =3.99 on everwhere.


Not as icky (IMHO) as having distribution names with embedded major 
version numbers.  I'm interested in other people's opinions here.


I'm definitely in agreement here. Everytime I type BTreeFolder2 I feel 
like someone's killing a kitten somewhere.


It's a shame setuptools doesn't take care of this properly :-/

(where my definition of properly is that major releases like 2.0, 3.0 
are assumed to be backwards incompatible such that 3.0 won't satisfy a 
=2.0)


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)

2007-05-23 Thread Chris Withers

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

2007-05-16 Thread Chris Withers

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

2007-05-11 Thread Chris Withers

Bernd Dorn wrote:


for my projects however i just directly set all zope.* dependencies in 
setup.py explicitly, see the various z3c.* on svn.zopeorg packages as 
examples


I guess that makes sense if the satellite projects start getting their 
own release cycles, which I think would be a good thing.


I dunno, do we actually need an offical big zope 3 release anymore?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] adapter lookup question

2007-05-11 Thread Chris Withers

Hi All,

I want to lookup a multi-adapter using the following code:

getMultiAdapter((obj1,obj2),ISomething)

I also wanted to have a backstop adapter so that the above would never 
fail, which I tried to register as follows:


adapter
  for=* *
  provides=ISomething
  factory=.something.Something/

...however the getMultiAdapter call still failed with a 
ComponentLookupError :-(


I had to change the registration as follows:

adapter
  for=* .module.BaseClassOfObj2
  provides=ISomething
  factory=.something.Something/

...to get the getMultiAdapter call to work.

Why do I need to do this?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] what dependency to use for zope 3

2007-05-10 Thread Chris Withers

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



Re: [Zope3-dev] Re: Separating projects

2007-04-27 Thread Chris Withers

Christian Zagrodnick wrote:

On 2007-04-27 02:43:10 +0200, Fred Drake [EMAIL PROTECTED] said:

[...]



Since I expect the giant checkout to rapidly fall out of favor, I'm
all for moving code to the satellite projects.  Then Zope 3 will be
free to become a swarm of nano-projects that can be assembled into
useful but also lean and maintainable applications.  Which is what we
really care about.


Yes! I'd very much like that. That makes it also easier to get the 
dependencies right.


+1 from me. One of the main things stopping me doing zope 3 development 
is the need to do a monster checkout.


Of course, the only slightly risk is that when you change a satellite 
project, you cause test breakage in other satellite projects. How do 
people feel about that?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: Community opinion about search+filter

2007-03-28 Thread Chris Withers

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

2007-03-05 Thread Chris Withers

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

2007-03-03 Thread Chris Withers

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

2007-03-02 Thread Chris Withers

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 ?

2007-03-01 Thread Chris Withers

Michael Haubenwallner wrote:

Here is the patch that made it break:
+--- Lib/hotshot/stats.py~2001-10-15 22:18:53.0 +
 Lib/hotshot/stats.py2006-04-21 18:39:17.691461512 +
+@@ -1,7 +1,14 @@
+ Statistics analyzer for HotShot.
+
+-import profile
+-import pstats
++try:
++import profile
++import pstats
++except ImportError, msg:
++import sys
++sys.stderr.write('ImportError: %s\n' % str(msg))
++sys.stderr.write('please install the python%s-profiler package\n'
++ % sys.version[:3])
++sys.exit(1)
+
+ import hotshot.log


Wow, that's pretty evil.

Who's the appropriate Ubuntu person to take this up with?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: Why is the testrunner running with the --profile option ?

2007-03-01 Thread Chris Withers

Andrew Bennetts wrote:

Chris Withers wrote:

Michael Haubenwallner wrote:

Here is the patch that made it break:
+--- Lib/hotshot/stats.py~2001-10-15 22:18:53.0 +
 Lib/hotshot/stats.py2006-04-21 18:39:17.691461512 +

[...]

Wow, that's pretty evil.

Who's the appropriate Ubuntu person to take this up with?


Matthias Klose, but the best way to report this would be via:

https://bugs.launchpad.net/ubuntu/+source/python2.4/+filebug


done:

https://bugs.launchpad.net/ubuntu/+source/python2.4/+bug/88960

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: run-time adapter registration and un-registration

2007-02-15 Thread Chris Withers

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

2007-02-13 Thread Chris Withers

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?

2007-02-07 Thread Chris Withers

Philipp von Weitershausen wrote:

Okay, how about the config parser registers the utility:


The config parser (ZConfig) is generic 


Well, it runs of a schema which uses handlers specific to the project, 
so I don't see what your point is here...


the component architecture. The main() program in zope.app.appsetup, 
which makes use of the zope.conf configuration, would have to do it.


...it sounds like Zope 3's ZConfig schema creates an inert source of 
information, unlike Zope 2's, which instantiates things as it parses the 
config. Is that the case?


Right, but the whole point of factoring it out to a utility is to gain 
the ability to override things. If it's registered using 
z.c.provideUtility(), it'll be hard to impossible to override it using 
overrides.zcml. 


True, but if this happens in parsing zope.conf, you don't want to be 
able to change it later...


That's why I suggested we use named utilities because 
the we don't need to work with overrides.zcml.


I'm still struggling with why they need to be named, no doubt I'll find 
out why if/when I make a start on this ;-)


If so, what bad things could happen if the zodb sections in zope.conf 
were made optional and a later zcml statement provided the utility?


utility factory=myIRootObjectProvider /


Yeah, but how would you implement myIRootObjectProvider w/o having 
access to the ZODB? 


I'd envisage myIRootObjectProvider would be the thing which opened the 
zodb...


You don't know which ZODB you're going to get the 
root object from because that's decided *at runtime* in the main() 
program by reading zope.conf.


I thought you said the ZCML was processed after the main() stuff?

Because I'm not sure how persistent objects behave in a global registry. 


I'd imagine the root would just be a factory that opened a new 
connection/etc on traversal, or when it was requested by the 
publication, or some such...


Right now in the Zope default publication, the root object is gotten 
*after* opening the DB.  If we'd register the (persistent) root object 
in the global registry, it might exist w/o any ZODB connections open. 
Not sure if that's every going to occur, or if that's going to be a 
problem, etc.


I would hope to keep the semantics of getting the root object after 
opening the db in the same way...


Anyway, I think I've tried to give as many pointers as I could. I'm sure 
some of the things discussed here will come up when you'll implement 
this :).


Yep, I think it's time to start cutting code... eep...

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: zope.app.twisted.main?

2007-02-06 Thread Chris Withers

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?

2007-02-06 Thread Chris Withers

Philipp von Weitershausen wrote:

Why would this be in zope.conf at all?
I would have thought just having a normal zcml setup for a single, 
global IRootObjectFactory utility would be fine...


Well, actually, you can't register it through ZCML because ZCML knows 
nothing about the ZODB. 


Okay, how about the config parser registers the utility:

from zope.component import provideUtility
provideUtility(IRootObject,MyZODBRootThingy)

Of course, I don't see any reason for the config parser to _have_ to do 
so... something just needs to register an IRootObject before the first 
publication gets instantiated, right?


If so, what bad things could happen if the zodb sections in zope.conf 
were made optional and a later zcml statement provided the utility?


utility factory=myIRootObjectProvider /


Also, why the factory? Why not just IRootObject?


I guess just IRootObject is ok, the factory would have been a bit more 
generic because then you're not registering a specific root object for 
all times but could actually incorporate some logic into the 
root-object-finding-process.


Why would you want to do that?

There should be only one root, if it then wants to do interesting 
things, then either it can, or traversal adapters that start with it 
can. Why would you want any more complexity?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: zope.app.twisted.main?

2007-02-05 Thread Chris Withers

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?

2007-02-02 Thread Chris Withers

Philipp von Weitershausen wrote:
As Jim pointed out in an earlier discussion [1], we would rather like to 
separate server configuration from the application definition (ZODB, 
logs, etc.).


That sounds like any work I do here will help...


- make twisted/zserver interchangeable through a zope.conf setting


Like Jim, I would rather like to see (at least the HTTP) server 
definition thru something that's more general, such as paste.deploy.


I don't know paste.deploy and I don't have time or inclination to learn 
it. However, any work I do will be aiming to make it simpler to slot in 
different bits in different roles. What does paste.deploy do?


I was toying with the idea of trying to have an IConfiguration utility 
such that ZConfig could be switched out, is that what you're talking about?


- refactor so that as much code as possbile is shared between 
zope.app.twisted.main and zope.app.server.main


+1

I'd say that this should result in a general main() program that *can* 
(but doesn't have to) read the application definition from a zope.conf 
file, 


Indeed.

and does server setup (at least HTTP) through a general framework 
like paste.deploy. 


Well, I'll try and make this code encapsulated...

I would assume that this also results in a separate 
configuration file for paste.


Yay! More config files, just what we need ;-)


- explore ways of seperating some of the publication concerns


+1

For one, I suggest factoring the whole root object issue out of the 
publication (e.g. introduce an IRootObjectFactory utility that, when 
called, will return the root object; 


How about just making an IApplication utility, or is IApplication too 
specific?


the main() program, if it has a 
zodb configuration, would register such a factory that would talk to the 
DB; others could do SQL or whatever).


Yeah, this is exactly what I'm after :-)

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] development checkout

2007-02-01 Thread Chris Withers

Hi All,

It's been way too long since I did that, but how do I go about getting 
an svn checkout of Zope 3 that I can develop with? Is there a how-to 
somehwere?


I'd imagine it goes something like:

1 - checkout svn url you wish to develop with

2 - do some kind of inplace build

3 - point your mkzopeinstance-created instance at the checkout

4 - develop

5 - run tests

How do I do 2 and 5?

For 2, how do I do a suitable in-place build on Linux? Are there still 
up-to-date pre-built binary bits for Windows that I can unpack? If so, 
where do I get them from?


For 5, how do I run tests for a module in the checkout with the 
testrunner, as opposed to tests for a module in the instance?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] customizing accesslog format

2007-02-01 Thread Chris Withers

Sascha Ottolski wrote:

Hi,

it appears as if the format for the access log is somewhat hardcoded. I 
see that there exists (at least)


zope.app.server.accesslog
zope.app.twisted.accesslog
zope.app.twisted.log

and

twisted.web2.log


ouch...

From discussions I found it seems as if the latter would be the place to 
hack the actual logging format (like suggested in 
http://mail.zope.org/pipermail/zope3-dev/2006-January/017771.html).


I'm wondering, is patching twisted really the way to go?


It's a shame that the python logging framework isn't used by either 
twisted or zope3 from what you're saying :-(


I wonder if they could be made to do so and if the respective 
communities would welcome that?


Would it be feasible to make the acceslog format be customizable via a 
zope.conf entry, in a way similar to what possible with apache  co.?


Indeed, it should just be another logger section...

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] zope.app.twisted.main?

2007-02-01 Thread Chris Withers

Stephan Richter wrote:

On Thursday 01 February 2007 02:42, Chris Withers wrote:

Is there a non-twisted main.py of does zope.app.twisted.main get used
for all Zope 3 instances?


zope.app.server.main


How do you switch between the two?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] zope.app.twisted.main?

2007-01-31 Thread Chris Withers
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?

2007-01-25 Thread Chris Withers

All the following are great, especially the (SF) ones ;-)

Tres Seaver wrote:

   from zope.interface import Interface, Attribute
   from zope.interface import implements, directlyProvides
   from zope.component import provideUtility, provideAdapter, adapts
   class IFoo(Interface):
  ... name = Attribute(u'Name')
   class FooUtil:
  ... implements(IFoo)
  ... def __init__(self, name):
  ... self.name = name
   fooUtil = FooUtil('default')
   provideUtility(fooUtil)
   fooUtilNamed = FooUtil('named')
   provideUtility(fooUtilNamed, name='named')
   class FooAdapter:
  ... implements(IFoo)
  ... adapts(None)
  ... name = 'default'
  ... def __init__(self, context,*args):
  ... self.context = context
   class FooAdapterNamed(FooAdapter):
  ... name = 'named'
   provideAdapter(FooAdapter)
   provideAdapter(FooAdapterNamed, name='named')

Now the usage.  Things which *don't* work today are marked '(SF)'.

Interfaces called with *no* context argument return
utilities, not adapters (SF)::

   u_default = IFoo() # return the default utility
   u_default.__class__.__name__, u_default.name
  ('FooUtil', 'default')

Named utilities can also be looked up (SF)::

   u_named = IFoo(name='named')
   u_named.__class__.__name__, u_named.name
  ('FooUtil', 'named')

Default adapter lookup works as expected::

   context = object()
   a_default = IFoo(context)
   a_default.__class__.__name__, a_default.name
  ('FooAdapter', 'default')

But we can also do named adapter lookup (SF)::

   a_named = IFoo(context, name='named')
   a_named.__class__.__name__, a_named.name
  ('FooAdapterNamed', 'named')


I'll note that none of these appear to do contextual lookup.
Would we want a spelling like this which worked with contextual lookup?

One thing I think I mentioned before would be the ability to use 
calling the interface to get a multi-adapter:



provideAdapter(FooAdapter,adapts=(None,None))
a_default = IFoo(objects=(context,context))
a_default.__class__.__name__, a_default.name

('FooAdapter', 'default')

One other thing, where is the code that gets called when you do 
ISomething(..etc...)? I had a look in interface.py and couldn't find 
anything :-S


I'd be interested in knocking the above set of extras up on a branch and 
seeing what people think...


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] calling interface returns object, calling queryAdapter returns None?

2007-01-24 Thread Chris Withers

Hot on the heels of my multi-adapter problem:

http://mail.zope.org/pipermail/zope3-dev/2007-January/021600.html

...which I'm still waiting for guidance on, I now find that queryAdapter 
and calling an interface behave unexpectedly differently in the case 
where an object directly implements an interface:


 from zope.interface import Interface,implements
 class ITest(Interface): pass
...
 class Test:
...   implements(ITest)
...
 t = Test()
 ITest(t)
__main__.Test instance at 0x01C6E300
 from zope.component import queryAdapter
 queryAdapter(t,ITest)


How come calling the interface returns t but queryAdapter returns None?

Should I log this and my previous multi-adapter example as bugs in the 
collector?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?

2007-01-24 Thread Chris Withers

Laurence Rowe wrote:
 From the Interface.__call__ docstring: If an object already implements 
the interface, then it will be returned


queryAdapter is looking in the adapter registry.

You have not registered any adapters.

So this looks like the expected behaviour to me.


Documented maybe, expected no.

queryAdapter, for me, is starting with the supplied object, get me 
something that implements the supplied interface and return None if no 
such object can be obtained.


If there's another function which does this, fine, if not, then I 
maintain the current behaviour is not correct...


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?

2007-01-24 Thread Chris Withers

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?

2007-01-24 Thread Chris Withers

Fred Drake wrote:

On 1/24/07, Chris Withers [EMAIL PROTECTED] wrote:

queryAdapter, for me, is starting with the supplied object, get me
something that implements the supplied interface and return None if no
such object can be obtained.


 o = IFoo(ob, None)
 if os is not None:


Ah, now that's what I was looking for, thanks :-)

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: Zope 3 without ZODB

2007-01-22 Thread Chris Withers

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

2007-01-22 Thread Chris Withers

Philipp von Weitershausen wrote:
(Note that in my original reply to ChrisW, I tried to be pragmatic. Of 
course, if ChrisW has the resources to go into this refactoring, by all 
means, let's do it).


No resources, sorry :-(
Just a desire to see this done right :-S

The pragmatic approach is just to make like Sidnei and have a zodb with 
only one root object in it...


There are two parts of your question.  Making it simpler to plug in a 
different application root, and dealing with ZConfig.


This is true... while I'd love to have config have nothing to do with 
the problem at hand, I guess, as you point out, it's currently woken in. 
 I guess a start would be to make it simpler to *not* use ZConfig but 
use a.n.other configuration method. I have memories of Jim having a 
proposal about this?


In order to implement a simpler security mechanism for grok, we had to 
re-implement every single publication (though of course subclassing was 
still possible, but we had to create a new variant of every publication 
class). That shouldn't be necessary.


Yeah, I'm guessing there's a few places where:

-getting the root object
-setting up the component achitecture
-setting up the servers
-setting up the security policy

...all run into one and maybe now's the time to burst them open?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Zope 3 without ZODB

2007-01-20 Thread Chris Withers

Hey All,

I'm still continuing poking around (when I have the chance) to see how 
I'd get Zope running without ZODB.


Does the following line:

db = zope.app.appsetup.appsetup.multi_database(options.databases)[0][0]

...from:

http://svn.zope.org/Zope3/trunk/src/zope/app/server/main.py?rev=71011view=markup

...mean that Zope 3 is currently hard-coded to need a ZODB?

If so, how should we go about making this optional?

(I am willing to put the work in to make this happen if people give me 
some hints...)


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: Zope 3 without ZODB

2007-01-20 Thread Chris Withers

Philipp von Weitershausen wrote:
We would check if options.databases if empty. If that's so, we could set 
'db=None'.


The 'db' object (the database) gets passed a long to the ServerTypes 
which pass it along to the WSGIPublisherApplication which then passes it 
along to the request/publication factory. This way, when a new request 
is created and a publication object with it, the publication has the 
database to start traversal off of. As far as I can see it, the 
publication is the only component in that whole chain that expects the 
'db' object NOT to be None. So, you'd have to write your own publication 
that wouldn't use the 'db' object for a traversal root but your own 
custom object, e.g.:


class MyPublicationMixin(object):
Mix this in with BrowserPublication, HTTPPublication, etc.

def getApplication(self, request):
stack = request.getTraversalStack()
if '++etc++process' in stack:
return applicationControllerRoot

myroot = RootObject()
return ProxyFactory(myroot)


Ouch, what this code seems to imply is that I'd have to create new 
publications of all types :-S


It strikes me that I shouldn't have to mixin and create new publications 
of every type just because I don't want a ZODB ;-)


Is there an IApplication? If so, could whatever calls getApplication 
(which I guess must somehow get passed db) rather adapt db to an 
IApplication?


zope.conf could then return things other than ZODB db's from it's db 
section and everything would be great provided there was an adapter from 
the object returns to IApplication, where IApplication is the interface 
that describes whatever getApplication above should return?


cheers,

Chris

PS: I'm aware the above is hand waving in some senses, I don't have the 
time I'd like to dig in and research this properly right now, but I want 
to try and get a feel of things for when I do...

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Zope 3 without ZODB

2007-01-20 Thread Chris Withers

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

2007-01-20 Thread Chris Withers

Jim Fulton wrote:


I would *much* rather see us open this up by making this part of Zope 3 
more modular and putting more emphasis on explaining what is going on 
and how one would do something different.


big +1 from me...


Here's what I'd like to see:

1. Separate server definition from application definition.  They are way 
too interwoven now.  I'd like to see us move to Paste Deploy (or 
something based on the framework it defines).


Is this the seperation of what objects are being served from what 
protocols are being served that I mentioned in my other reply?


In my dreams, it'd be great if I could just wire in a different 
IApplication utility to get the root of the object tree and just leave 
the zodb section of zope.conf empty. How hard would that be to achieve?


(the 2nd bit of it is important, I don't want zodbs opened, especially 
if they're never going to get used)


2. Document how to use the zope.publisher framework to define web 
applications.  It isn't very complicated, it just needs some 
documentation.  I made a beginning of of this in my aborted bobo 
project.  A good start for examples would be a hello-world app, the 
existing zope 3 app, and, I assume, Grok.


Yes, I'm curious about Grok too here, I hope someone who knows from that 
project will pipe up. Would the hello-world app be akin to the stuff I 
was nosing around in zope.app.appsetup?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] wildcard adapter

2007-01-19 Thread Chris Withers

Marius Gedminas wrote:

There's a slight difference, I think.  In the Zope 3 world, there's
usually one style that is considered to be the best way of doing stuff.
Only it varies with time and with individual Zope 3 developers. ;-)


I do wish it would stop varying...


If you pass the adapts/provides arguments to provideAdapter (or the ZCML
directive), the values you specify override the defaults declared by the
adapter itself.


Right, so provideAdapter is still king? ;-)

Does your favoured methodology actually register the adapter?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: wildcard adapter

2007-01-19 Thread Chris Withers

Marius Gedminas wrote:

Now when you try to adapt anything to ITest, zope.component will call
your ``adapter`` function and then check the return value.  A return
value of None means the adapter is not available, and results in a
TypeError you see here:


Yes, apologies, both you and Philipp are correct, I was trying to show a 
simple version of a problem and oversimplified.


Here's what I really meant:

 from zope.component import provideAdapter
 from zope.interface import Interface
 from zope.component import getMultiAdapter
 class ITest(Interface): pass
...
 def adapter(*args): return args
...

 provideAdapter(adapter,adapts=(None,),provides=ITest)
 ITest(1)
(1,)

Yay, as expected...

 getMultiAdapter((1,),ITest)
(1,)

Good, still works...

 provideAdapter(adapter,adapts=(None,None),provides=ITest)
 getMultiAdapter((1,1),ITest)
Traceback (most recent call last):
...
zope.component.interfaces.ComponentLookupError:
 ((1, 1), InterfaceClass __main__.ITest, u'')

Oh dear, what have I done wrong here?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: wildcard adapter

2007-01-19 Thread Chris Withers

Tres Seaver wrote:

  provideAdapter(adapter,adapts=(None,None),provides=ITest)
  getMultiAdapter((1,1),ITest)
Traceback (most recent call last):
...
zope.component.interfaces.ComponentLookupError:
  ((1, 1), InterfaceClass __main__.ITest, u'')

Oh dear, what have I done wrong here?


The order of your adapter registration is *one*, 


Does the following not register for an order of two?

provideAdapter(adapter,adapts=(None,None),provides=ITest)

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] wildcard adapter

2007-01-18 Thread Chris Withers

Marius Gedminas wrote:
BTW passing interfaces to provideAdapter/adapts is out of fashion. 


This stuff is getting almost perl-ish in it's there's many ways to do 
it, pick the style you like nature..



I
prefer using zope.component.adapts and zope.interface.implements (or
zope.component.adapter and zope.interface.implementer, when my adapter
is a function rather than a class).


I often register the same adapter factory for several different types or 
objects / interfaces. How would I do that with your favoured spelling?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: wildcard adapter

2007-01-18 Thread Chris Withers

Philipp von Weitershausen wrote:
If it is, then which of the following should I use to register a 
generic adapter for any single object to an interface:


provideAdapter(...,adapts=(None,),...)


This one.


Given that you can register adapters for any class, whether or not it 
implements any interface, this doesn't work as it should:


 from zope.component import provideAdapter
 def adapter(*args): pass
...
 from zope.interface import Interface
 class ITest(Interface): pass
...
 provideAdapter(adapter,adapts=(None,),provides=ITest)

 ITest(1)
Traceback (most recent call last):
...
TypeError: ('Could not adapt', 1, InterfaceClass __main__.ITest)

 class test: pass
...
 ITest(test())
...
TypeError: ('Could not adapt', __main__.test instance at ..., 
InterfaceClass __main__.ITest)


I have no idea what a generic adapter is, but the zope.component API 
docs (== interfaces) are certainly complete in this sense. There are 
also doctests.


Where can I find the docs and interfaces you mention above? I looked 
through both zope.interface and zope.component and obviously missed them :-(


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: Idea: Failure to lookup adapters

2007-01-18 Thread Chris Withers

Philipp von Weitershausen wrote:
Code like this won't be run with python -O (which is what you'd 
obviously use in production).


obviously... not.

How many people actually do this?

I wonder whether a different approach could be taken. The APIDOC code 
does already a registration analysis. Maybe we can use the 
registrations in a away that they simulate the adapter registry. Thus 
you could provide APIDOC (via the Web UI or Python) with a component 
or instance and it tells you how it tries to look up the adapter. 
Clearly that would be much slower, but okay for inspection.


Sounds good. I like the explainAdapter() suggestion.


Me too...

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] wildcard adapter

2007-01-17 Thread Chris Withers

Hi All,

I was wondering if someone could give me a definitive explanation of 
what the following means:


adapter
for=* ISomething *
...

...means?

Is the following equivalent:

provideAdapter(...,adapts=(None,ISomething,None),...)

?

If it is, then which of the following should I use to register a generic 
adapter for any single object to an interface:


provideAdapter(...,adapts=(None,),...)
provideAdapter(...,adapts=None,...)

I'm not having a lot of joy registering generic adapters so I thought 
I'd come and check my understanding here ;-)


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: zope.tal.xmlparser.XMLParser() dislikes unicode

2007-01-17 Thread Chris Withers

Martijn Faassen wrote:

That's what I do too...


See my post elsewhere in the thread for an example of why this is Not Good.


Luckily Twiddler is still less than version 1.0 ;-)

When someone reports it as a bug, I'll fix it.

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Idea: Failure to lookup adapters

2007-01-17 Thread Chris Withers

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

2007-01-15 Thread Chris Withers

Philipp von Weitershausen wrote:

u'?xml version=1.0 encoding=something-else?node /'

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

2007-01-14 Thread Chris Withers

Dieter Maurer wrote:

A halfway intelligent parser would accept Unicode when it gets it
and concentrate on the remaining part of its task: either reporting
structural events or building a parse tree.


The trivial fix I use in Twiddler is as follows:

if isinstance(source,unicode):
  source = source.encode('utf-8')

Of course, this assumes a heading of either ?xml version=1.0 
encoding=utf-8? or a missing encoding attribute, in which case the 
xml spec states that the string must be utf-8 encoded.


The problem comes when someone sends you something like:

u'?xml version=1.0 encoding=something-else?node /'

What should be done then?

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances

2007-01-04 Thread Chris Withers

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

2006-12-22 Thread Chris Withers

Jim Fulton wrote:

The easiest way is with the buildout zc.recipe.testrunner recipe.
There are lots of examples of this in the repository,
including ZODB, zc.buildout, zc.ngi, zc.recipe.rhrc, among many others.


Are there high level docs for building things out like this?

I'm somewhat intimidated by the whole buildout/eggs/distutils thing :-S

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)

2006-12-21 Thread Chris Withers

Dieter Maurer wrote:

Someone already worked on this and reported success.

   He integrated a ZEO client via mod_python.


Yep, that was Philipp. I wonder where that project ended up?

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: [SpringCleaning07]

2006-12-21 Thread Chris Withers

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?)

2006-12-20 Thread Chris Withers

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?)

2006-12-20 Thread Chris Withers

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?)

2006-12-19 Thread Chris Withers

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

2006-12-18 Thread Chris Withers

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

2006-12-15 Thread Chris Withers

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...

2006-12-11 Thread Chris Withers

Martin Aspeli wrote:
Why can't IView (or whatever it is) just specify that the constructor 
must accept a request, response and a template instance?


Because the template may not be passed in, and even if it is, where 
would it be constructed and how would it be found again?


See my currying comment later in the thread.

then you may as well not have a 'template' attribute for browser:page 
If you have it done in ZCML, though, you can get a template-only view 
without any Python at all, though:


browser:page
for=*
template=mytemplate.pt
name=my_view
permission=zope.Public
/


yeah, but I'm talking about the horrificness that currently makes the 
above work.


I'm asking whether it really needs to be that bad or whether it could be 
more sanely implemented.


I guess I should just make a branch and have a play or stfu...

The later is likely to win due to lack of time

*sigh*

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: wading through zcml...

2006-12-07 Thread Chris Withers

Martijn Faassen wrote:

Chris Withers [EMAIL PROTECTED] wrote:

Martijn Faassen wrote:

class TemplateView(grok.View):
template = unassociated
module_info = module_info_


I'm not sure. Debugging becomes a nightmare with generated classes, 
which is how I ran into these problems in the first place.


Can you explain what the what the above code snippet actually does?


It generates a view for a template file that doesn't have its own view.


Okay, but isn't this just a currying problem?

If so, there's all the usual python currying solutions, here's one...

class ViewFactory:

   implements(IView)

   def __init__(self,klass):
   self.template = PageTemplateFile(klass.template_name)
   self.klass = klass

   def __call__(self,context,request):
   return self.klass(template,context,request)

class MyView:

   template_name = ''

provideAdapter(ViewFactory(MyView),(IContext,IRequest),IView)


Possibly. It's not that bad right now. The difficulty is that I do
need to generate a class, not an instance, as I can only initialize the
instance when the view is initialized because the context and request
are needed.


There's something to be said for circumstances where creating an adapter 
each time it's asked for is sub-optimal, but I don't have a good enough 
feel for the problem in its generic sense to make any suggestions...


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] zope3 instance with no zodb

2006-12-06 Thread Chris Withers

Jim Fulton wrote:


Yes.  You have to configure an alternate publication object. 


Okay, any clues how to do that? Where's the default configuration done? 
What interfaces do I need to implement?



Launchpad
does this. 


Cany any Launchpad'ers present tell me where to look in your source 
repository?



other things, controls object traversal.  The default publisher uses a
database object as a starting point for traversal.  An alternate publisher
could use something else, including allowing multiple root objects.


Cool :-)

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: wading through zcml...

2006-12-06 Thread Chris Withers

Martijn Faassen wrote:

dynamically generated class for templates that don't have classes of
themselves. I know you were there when we created this one. :)

class TemplateView(grok.View):
template = unassociated
module_info = module_info_

of course the instances of this class do nothing the developer has to
interact with. As soon as the developer provides a view class of their
own, there's no dynamically generated class anymore. I think that this
is an acceptable use of the pattern.


I'm not sure. Debugging becomes a nightmare with generated classes, 
which is how I ran into these problems in the first place.


Can you explain what the what the above code snippet actually does?


I've done it too recently in the form support. The *real* formlib-level
form class is dynamically created for each grok-level form:

class RealEditForm(form.EditForm):
form_fields = get_form_fields(factory, context)
actions = actions_

This one is a bit more scary, as the end-user interacts with an
*instance* of this class; the form attribute on grok-level forms is one.


There must be a nicer way :-S

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: zope3 instance with no zodb

2006-12-06 Thread Chris Withers

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...

2006-12-06 Thread Chris Withers

Jim Fulton wrote:

If you want to specify the name of a template in ZCML, then you'll
have to invoke some magic.  


Why can't IView (or whatever it is) just specify that the constructor 
must accept a request, response and a template instance?



Now I'll go back to ignoring this thread, the desire to do so
increased by the sort of extreme over-simplifying remarks made.


Not sure what you mean by this...

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] zope3 instance with no zodb

2006-12-02 Thread Chris Withers

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?

2006-11-30 Thread Chris Withers

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?

2006-11-28 Thread Chris Withers

Benji York wrote:

Chris Withers wrote:
I don't think it'll be a common pattern, but it doesn't feel right to 
me that a named adapter (ie: one registered with a specific name) has 
no way of finding out what name it has been registered with...


Because the same adapter can be registered more than once, it would 
actually need to find out all the names with which it was registered.


Really? Now this is a use case I hadn't thought of.. can you give me 
some examples of where you've run into this?


This seems somewhat analogous to a Python object being given multiple 
names.  In that case too, there is no way for the object to know what 
it's names are.


Hmmm, okay, but I'd counter with both Zope 2 and Zope 3 having the 
notion of an object knowing its own name. Certainly in Zope 2, 
everything has an id or .getId(). That pattern evolved for a reason ;-)


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: Can an adapter find out what name it was registered for?

2006-11-28 Thread Chris Withers

Tres Seaver wrote:

  for name in ('vindaloo', 'madras', 'tiki_masala'):
   globals()[name] = MNA_factory_maker(name)

and then in ZCML:

   adapter for=.interfaces.IChicken
provides=.interfaces.ICurry
name=vindaloo
factory=.adapters.vindaloo /


...but here you have to specify the same info twice and hence duplicate 
info and get it identical in two places, which feels icky to me.


Is there a python-only way to register adapters instead of in ZCML and, 
if it exists, is it safe to use in conjunction with the normal zcml dances?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?

2006-11-27 Thread Chris Withers

Stephan Richter wrote:

On Friday 17 November 2006 03:43, Chris Withers wrote:

What do you suggest I do when the adapter needs to know the name it was
registered for?


You can make the name part of the adapter API.


Not sure what you mean by this?

However, I would suggest revising the design; I have never come across a 
scenario where I wanted the name of the adapter be known within the adapter. 
This seems to be a recipe for trouble. 


I don't think it'll be a common pattern, but it doesn't feel right to me 
that a named adapter (ie: one registered with a specific name) has no 
way of finding out what name it has been registered with...


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: adapter registration question

2006-11-17 Thread Chris Withers

Tres Seaver wrote:

We were discussion a (notional) value adapter, whose factory would
have the contract of returning an object of a specific concrete type,
rather than on implementing an interface.


Right, but the CA supports the use of classes instead of interfaces and 
that works just fine here...



There are reasonable usecases
for such adapters, but the CA machinery doesn't permit registering them:
 it requires that the 'provided' argument be either an interface or None
(although the 'required' args can be concrete types).


Nah, for both provides and adapts classes can be used in place of 
interfaces just fine, and I've got this working just how I want it now :-)


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: adapter registration question

2006-11-17 Thread Chris Withers

Dieter Maurer wrote:

As Chris example demonstrates, it would have been better
to call IZopeDublinCore(myobj) the IZopeDublinCore
adaptation of myobj.


Agreed, and would have saved me a lot of confusion.

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?

2006-11-17 Thread Chris Withers

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: wading through zcml...

2006-11-17 Thread Chris Withers

Philipp von Weitershausen wrote:

browser:view
  Note: browser:view always creates new classes on the fly.


evil


browser:page
  Registers an adapter where the second adapted object defaults to
  IBrowserDefaltLayer. Always creates a new class on the fly and
  mixes in functionality that makes the adapter a *publishable view*.


evil.

I'm sick of ZCML and its magic and its inconsistency. The typing and the 
pointy brackets I could live with... ME GROK SMASH ZCML.


Yeah, ZCML is the new acquisition :-(

It's sad that one of it's main selling points (the ability to turn off 
configuration made in another package) was never implemented :-(


That said, I can live with most of the crap, but these dynamically 
generated classes... wtf? why? why did that? why are they still breathing?!


Whatever happened to explicit is better than implicit et al?

I'm trying to register an adapter in such a way that I can do the 
following in a page template:


p tal:content=structure someobj/@@render/

Which of the myriad flavours of view registration should I be using?


Inherit from BrowserView 


Everyone says this, but why is it a good idea? I want these things to be 
_really_ light, they're going to be used a lot in every page render...


and use either a simple adapter / or a view 
/ or a browser:view / directive to register it. Note that this thing 
won't be publishable via the URL then (which is probably what you want).


Correct.

Also, why, when zope:view is described as a synonym for zope:adapter, 
does zope:view support an allowed_attributes attribute, while 
zope:adapter does not?


zope:adapter assumes the provides interface as the allowed_interface.


*sigh*

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: adapter registration question

2006-11-16 Thread Chris Withers

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

2006-11-16 Thread Chris Withers

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

2006-11-16 Thread Chris Withers

Jean-Marc Orliaguet wrote:

once you have that utility / adapter you should be able to call it like:

  converter = getAdapterFor(123, type=IToStringConverter)
  strResult = converter.convert(123)


Not quite, what I'm looking to do is more along the lines of:

mystr = getAdapter(123,str)

(where str is the interface I'm looking for here)


PS: calling '123' an adapter is really bending concepts.


Yes, this is a mistake, I believe this should always be referred to as 
the adapted value or the suggestion Dieter made...


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] adapter registration - sort of works :-S

2006-11-16 Thread Chris Withers

Hi All,

Chris Withers wrote:

Jean-Marc Orliaguet wrote:

once you have that utility / adapter you should be able to call it like:

  converter = getAdapterFor(123, type=IToStringConverter)
  strResult = converter.convert(123)


Not quite, what I'm looking to do is more along the lines of:

mystr = getAdapter(123,str)


OK, less talk, more do... and when I stop worrying about it, it all gets 
very easy:


 from zope.component import provideAdapter
 provideAdapter(str,(int,),str)
 from zope.component import getAdapter
 getAdapter(123,str)
'123'

Yay! That's _exactly_ what I want. Although it does suggest that 'adapt' 
should be provided as an acronym for 'getAdapter'.


Anyway, now all excited, I tried this:

 def to_date(value):
...   try:
... return DateTime(value)
...   except:
... return None
...
 provideAdapter(to_date,(str,int),DateTime)
 getAdapter('2006/11/16',DateTime)
Traceback ...
...
zope.component.interfaces.ComponentLookupError:
('2006/11/16', class DateTime.DateTime.DateTime at 0x00E73600, u'')

wtf?

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: adapter registration - sort of works :-S

2006-11-16 Thread Chris Withers

Philipp von Weitershausen wrote:

  from zope.component import provideAdapter
  provideAdapter(str,(int,),str)
  from zope.component import getAdapter
  getAdapter(123,str)
'123'

Yay! That's _exactly_ what I want.


And that's exactly what I meant -- and wrote about half way up the 
thread. :)


Yeah, but the words were wrong, so I didn't grok it.
A simple example as above would probably have done it ;-)


  provideAdapter(to_date,(str,int),DateTime)


This registers a multi adapter for (a_string, an_integer), like views 
are multi-adapters for (context, request). You want to say:


   provideAdapter(to_date, (str,), DateTime)
   provideAdapter(to_date, (int,), DateTime)


A... okay, I had to guess from this:

 help(provideAdapter)
Help on function provideAdapter in module zope.component:

provideAdapter(factory, adapts=None, provides=None, name='')

 provideAdapter(str,int,str)
Traceback...
...
TypeError: iteration over non-sequence

I guessed the wrong use of the sequence :-(

Shame provideAdapter doesn't have a docstring ;-)

Okay, so now I can do what I want:

 getAdapter('2006/11/16',DateTime)
DateTime('2006/11/16')

...except:

 getAdapter('moo',DateTime)
Traceback...
...
zope.component.interfaces.ComponentLookupError:
('moo', class DateTime.DateTime.DateTime at 0x00E73600, u'')

I'm guessing this is 'cos my adapter is returning None and that's a 
special value meaning couldn't adapt, right?


How would I _really_ return None from an adapter?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] wading through zcml...

2006-11-16 Thread Chris Withers
What's the difference between zope:view, browser:view, browser:page and 
browser:viewlet?


I'm trying to register an adapter in such a way that I can do the 
following in a page template:


p tal:content=structure someobj/@@render/

Which of the myriad flavours of view registration should I be using?

Also, why, when zope:view is described as a synonym for zope:adapter, 
does zope:view support an allowed_attributes attribute, while 
zope:adapter does not?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] wading through zcml...

2006-11-16 Thread Chris Withers

Martin Aspeli wrote:


Chris Withers wrote:
What's the difference between zope:view, browser:view, browser:page and 
browser:viewlet?



I would strongly encourage you to buy Philipp's book when the second edition
comes out, and read some of the available existing documents (e.g.
worldcookery.com, the Zope 3 wiki thingie).


I'm a strong reader of Philipp's book(s) but they don't go into enough 
detail here...



zope:view / is deprecated, I believe, an old spelling for adapter /
before adapter / could do multi-adapters.


See my previous complaint, they have totally different signatures, I 
don't see how one can be deprecated in favour of the other.



browser:view / is about registering a new view, typically one that doesn't
render a page (so think of it analogous to where you may use a Script
(Python) in Zope 2)


What's the difference between a page and not a page in your mind?


browser:page / is about a view typically with an associated template that
renders something for the user


Then why is the macros view in the following example registered as a page:
http://wiki.zope.org/zope3/SimplifyMacroRegistration
?


browser:viewlet / is about building viewlets, which are small chunks of
HTML that are aggregated into a browser:viewletManager /. The DocTest in
zope.viewlet explains it all.


Sounds like this is worth a look...

I'm trying to register an adapter in such a way that I can do the 
following in a page template:


p tal:content=structure someobj/@@render/


You would use a browser:view with a class deriving from BrowserView
(Products.Five.browser.BrowserView)


Why do I need to subclass BrowserView? I looked through the code and 
can't really see what this adds...


As I've said before, I don't care about the request, and really don't 
like the magic appearance of both the request and context attributes. 
That said, looking at the actual object I appear to get as the view, I'm 
deeply scared to see so much magic going on (wtf is a 
Products.Five.metaclass?!)



and did its magic in the __call__ method
i believe. A more common pattern would be to have a method on the view
render that you call:

tal:define=renderView someobj/@@render
tal:content=structure renderView/renderTheData


This all feels way to heavyweight. My IRender has exactly one method, 
and a lot of objects will be getting rendered on each page...


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Can an adapter find out what name it was registered for?

2006-11-16 Thread Chris Withers

Hi All,

Can a named adapter find out the name it was registered with during the 
adaptation process?


This is the only way I can think to do it, but results in the thing 
calling methods on the adapter passing in the name to every method call 
to get the information across, which seems a bit clunky to me:


for name,adapted in getAdapters((someobj,),ISomething):
   adapted.doSomething(name)

Other ideas greatfully received!

cheersm

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: adapter registration question

2006-11-15 Thread Chris Withers

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

2006-11-14 Thread Chris Withers

Philipp von Weitershausen wrote:

Chris Withers wrote:

Christian Theune wrote:
The problem you have is to provide a specification for the 'str' 
interface.


There are a couple of problems here...

1. str is both a function and a class


Nope. It's a class since Python 2.2.


...hence the quotes. It's a function in that I want to use it as an 
adapter that doesn't need to be instantiated by a factory before being used.


Right, as an *input* of the adaption it's ok just to specify a class. 
But the output obviously always has to be specified by an interface. 
Otherwise the whole point of using of adaption is perverted...


Not really. It's the ability to register the adapter, and change which 
adapter you choose to use that's important for me here. I think it 
should be fine to adapt to a class if you can adapt from a class. Is 
there anything in the implementation that actually prevents this?

(which I, for one, would consider a bug)


should be:

provide=str


Wtf? Then why do you need an adapter?


See above.

I thought you wanted to say 
IString(1) instead of str(1) to be more flexible...?


Hmm, I see your point, but there are other ways to get an adapter than 
by calling an interface ;-)

(and I think I'd need to use those here, since there is no interface)

...and factory=str is wrong for the reasons given above, or, put 
differently, because str()(1) will tell you that strings aren't 
callable ;-)


Huh? You got that wrong. IString(1) will call str(1) if 
provideAdapter(str, (int,), IString).


right, but factory= registers and adapter factory, not an adapter and 
provideAdapter registers an adapter directly, correct?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: adapter registration question

2006-11-14 Thread Chris Withers

Tres Seaver wrote:

Heh, in this case using 'IString' is really a trussed duck (duck
typing with BD) ;)  Python's duck typing breaks down with strings,
because they can by quack tested like sequences, but you almost
*never* want to treat them the same way as other sequences, so you end
up with 'isinstance(obj, basestr)' tests to prevent handling them that way.


True, and I guess for my uses, I'd be wanting to register adapter both 
too and from basestr, since that'd cover unicodes too, unless that would 
be bad ;)


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: adapter registration question

2006-11-14 Thread Chris Withers

whit wrote:


hello RuleDispatch...


What's RuleDispatch?

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: adapter registration question

2006-11-13 Thread Chris Withers

Christian Theune wrote:

The problem you have is to provide a specification for the 'str' interface.


There are a couple of problems here...

1. str is both a function and a class

2. I was to register the function str as an adapter for, say, the 
class int to the class str, so there's not factory for the adapter, 
since it's a function



Let's create a marker interface that promises everything that 'str' does:

class IString(zope.interface.Interface):
A marker for the 'str' interface.


As discussed elsewhere, you shouldn't need the marker interface, as you 
can adapt classes. However, given the edge-case nature of this, I can 
believe there might be bugs to be found here...



Now, you can setup your adapter like this:

adapter
for=int
provides=.interfaces.IString
factory=str/


Well, that's not right ;-)

should be:

provide=str

...and factory=str is wrong for the reasons given above, or, put 
differently, because str()(1) will tell you that strings aren't callable ;-)


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] adapter registration question

2006-11-10 Thread Chris Withers
This is a toy example, but I need to do something similar and can't seem 
to get the registration right...


How can I register the str builtin as an adapter from python int objects 
to python str objects?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] adaptation based on class rather than interface

2006-11-09 Thread Chris Withers

Hi All,

I find myself often having to define pure marker interfaces for each 
class that I define, purely so I can register adapters for objects of 
that class.


How do people feel about:

- being able to register an adapter as follows:

adapter
for=.myclasses.MyClass
provides=.interfaces.ISomething
factory=.adapters.MyAdapter
/

  ..in addition to the normal registration for interfaces.

- be able to adapt objects based on their class if no interfaces match:

class MyClass: pass

obj = MyClass()

ISomething(obj)

I'm expecting people to say NO! very loudly, but I'm interested in the 
real reasons for why this is bad.


Having to define interfaces purely so an adapter can be registered seems 
tortological to me...


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] adaptation based on class rather than interface

2006-11-09 Thread Chris Withers

Jim Fulton wrote:

adapter
for=.myclasses.MyClass
provides=.interfaces.ISomething
factory=.adapters.MyAdapter
/


I think it is a fine idea.  That's why it has been supported for
a long time.  You can register adapters and views (which, of course
are adapters) for classes as well as interfaces.


Yay! *sound of a million marker interfaces dying*

Hmm, is this documented anywhere?

Philipp, is this in the new edition of your book?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Test Layers

2006-10-17 Thread Chris Withers

Hi All,

Am I right in assuming that there aren't any good narrative docs for 
test layers?


I've read the relevant text files in zope.testing but am none the wiser...

I found an article of Philipp's here which helped a bit:

http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_03_10_death-to-zopetestcase

I've also found this on ZopeWiki:

http://zopewiki.org/TestLayersHowTo

I think the latter would be good to bash into a doctest and included 
into the zope.testing documentation. Do others agree?


Now, related to this, say I have content objects X and Y, which are 
expensive to set up. I have LayerX which sets up a sample content object 
X, and LayerY which does the same for content object Y. This is fine for 
tests which need one or other content type, but how do I write tests 
which need both?


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] layers can't be new style classes?

2006-10-17 Thread Chris Withers

Hi All,

It would appear that Philipp's article is somewhat misleading in that 
layers can't be new style classes...


class MyLayer(object):

   def setUp(self): pass

   def tearDown(self): pass

..results in the following when used as a layer:

AttributeError: type object 'object' has no attribute 'setUp'

Is this a bug in Philipp's article or in the testrunner?

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] layers can't be new style classes?

2006-10-17 Thread Chris Withers

Stefan H. Holek wrote:

IIRC you need

@classmethod
def setUp(cls):
pass

@classmethod
def tearDown(cls):
pass


Sorry, braino on my part. Yes, I have the @classmethod's and I still see 
the error:



AttributeError: type object 'object' has no attribute 'setUp'


cheers,

Chris

PS: Has anyone doen the work Philipp aludes to in his article to make 
ZopeTestCase a series of layers?


--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Test Layers

2006-10-17 Thread Chris Withers

Martin Aspeli wrote:


Layers are ... layered. If your test base class has layer X and a test case
subclass of that has layer Y, then it will set up X, run all the X tests,
then setup Y and run all the Y and XY tests, then tear down Y and then X.


I didn't mention subclassing tests. Personally, I think that's evil...


I did this in Plone recently, but it completely escapes me where. Maybe I'll
have an epiphany after lunch, but look at how the ZCML layer in
PloneTestCase trunk works (it sets up all kinds of ZCML) and then try to
derive a class from PloneTestCase (or your equivalent) and set layer =
myLayer.


What layer(s) would the following test be executed in:

class BaseX(TestCase):

   layer = 'X'

class BaseY(TestCase):

   layer = 'Y'

class SomeTests(BaseX,BaseY):

   def test_1(self):
   pass

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Test Layers

2006-10-17 Thread Chris Withers

Jim Fulton wrote:
Am I right in assuming that there aren't any good narrative docs for 
test layers?


This is obviously in the eye of the beholder.  I'm sure the people
who created narratives tried to do a good job. Perhaps you can do better.


I may be missing some then... which narratives are you thinking of?

And yes, I'm hoping to do better unless I've just missed some existing 
docs...


I've attached a test file which opened my eyes... how do I go about 
weaving this into a doctest?


Now, related to this, say I have content objects X and Y, which are 
expensive to set up. I have LayerX which sets up a sample content 
object X, and LayerY which does the same for content object Y. This is 
fine for tests which need one or other content type, but how do I 
write tests which need both?


You create a layer that extends both.


How so?

Here's a sample of why I'm struggling:

class ZODB:

   @classmethod
   def setUp(cls):
   ... open zodb connection
   ... begin transaction

   @classmethod
   def tearDown(cls):
   ... abort transaction
   ... close connection

class LayerX(ZODB):

   @classmethod
   def setUp(cls):
   cls.savepoint = transaction.savepoint()
   ... create X instance

   @classmethod
   def tearDown(cls):
   cls.savepoint.rollback()

class LayerY(ZODB):

   def setUp(cls):
   cls.savepoint = transaction.savepoint()
   ... create Y instance

   @classmethod
   def tearDown(cls):
   cls.savepoint.rollback()

class MyLayer(LayerX,LayerY): pass

class MyTests(TestCase):

   layer = '.MyLayer'

   def setUp(self):
   self.savepoint = transaction.savepoint()

   def tearDown(self):
   self.savepoint.rollback()

   def test_1(self):
   pass

Basically, will the above work or will the savepoints become a horrible 
jumbled mess and I end up with several ZODB connections as well?


cheers,

Chris

PS: can I use '.MyLayer' as a layer, or do I always need to put the full 
dotted path in?


--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
from unittest import TestSuite, makeSuite, TestCase


class MyLayer:

@classmethod
def setUp(self):
# do something here
print 'L1 setup'
print self

@classmethod
def tearDown(self):
# undo it here
print 'L1 teardown'


class MyExtendedLayer(MyLayer):

@classmethod
def setUp(self):
# do additional stuff here
# don't call super
print 'L2 setup'

@classmethod
def tearDown(self):
# undo it only the additional stuff here
# don't call super
print 'L2 teardown'
raise RuntimeError('fubar MyExtendedLayer.tearDown')

class T1(TestCase):

layer = 'Products.MyProduct.tests.test_layers.MyLayer'

def setUp(self):
print T1 setup

def tearDown(self):
print T1 teardown

def test_1(self):
print 'T1.1'

def test_2(self):
print 'T1.2'

def test_3(self):
print 'T1.3'
raise RuntimeError('fubar T1.test_3')

class T2(TestCase):

layer = 'Products.MyProduct.tests.test_layers.MyExtendedLayer'

def setUp(self):
print T2 setup

def tearDown(self):
print T2 teardown
raise RuntimeError('fubar')

def test_1(self):
print 'T2.1'

def test_2(self):
print 'T2.2'

def test_3(self):
print 'T2.3'
raise RuntimeError('fubar T2.test_3')

class T3(TestCase):

def setUp(self):
print T3 setup
raise RuntimeError('fubar')

def tearDown(self):
print T3 teardown

def test_1(self):
print 'T3.1'

def test_suite():
suite = TestSuite()
suite.addTest(makeSuite(T1))
suite.addTest(makeSuite(T2))
suite.addTest(makeSuite(T3))
return suite
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] layers can't be new style classes?

2006-10-17 Thread Chris Withers

Jim Fulton wrote:

A layer is simply an object that has __module__, __name__, and __bases__
attributes and that has setUp and tearDown methods.  That's it.  You
can achieve that any way you want.  I regret the use of the __bases__
attribute.  It would have been better if I had left it up to layer
implementations to call base layers, rather than having the test runner 
call

them automatically.  It was a bad automation tradeoff.


Is it too late to add an explicit Layer class to zope.testing that deals 
with this properly rather than confusing n00bs like me?


(even if it does involve some BBB if/then/else'ing in testrunner.py...)

cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



  1   2   3   4   >