[Zope3-dev] ZCML, functional testing and buildout
Hi everyone, Thomas Lotze and I were working on creating a zc.buildout for one of our internal projects. The ZCML of our application is loaded using the 'package-includes' mechanism. To support functional testing, a 'kita-ftesting.zcml' slug was placed in the 'package-includes' and - as far as I can tell - this takes care to only load this ZCML when running functional tests. We're having a problem with the buildout integration at this point, as for the testrunner we are using the zc.recipe.testrunner recipe. However, the functional testing ZCML is placed in the instance part, but the testrunner does not know anything about this (should it?). Here's the question: what would be a good way to get the test runner load the correct ZCML for running tests? Cheers, Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZCML, functional testing and buildout
Christian Theune wrote: Hi everyone, Thomas Lotze and I were working on creating a zc.buildout for one of our internal projects. The ZCML of our application is loaded using the 'package-includes' mechanism. I think this is a bad idea. I think for serious development, package-includes is a bad idea. For our projects, we *never* use package-includes. To support functional testing, a 'kita-ftesting.zcml' slug was placed in the 'package-includes' and - as far as I can tell - this takes care to only load this ZCML when running functional tests. I have no idea what you are trying to say. We're having a problem with the buildout integration at this point, as for the testrunner we are using the zc.recipe.testrunner recipe. However, the functional testing ZCML is placed in the instance part, but the testrunner does not know anything about this (should it?). You'll need to use the working-directory option in the testrunner recipe to get it to run from the instance. The functional test code in zope.app.testing.functional *assumes* that the current working directory is an instance directory. :( Here's the question: what would be a good way to get the test runner load the correct ZCML for running tests? IMO, the package you want to test should define it's own ftesting.zcml and define a zcml-based test layer based on that. see zc.sharing as an example. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZCML, functional testing and buildout
Hi, Jim Fulton wrote: Christian Theune wrote: Hi everyone, Thomas Lotze and I were working on creating a zc.buildout for one of our internal projects. The ZCML of our application is loaded using the 'package-includes' mechanism. I think this is a bad idea. I think for serious development, package-includes is a bad idea. For our projects, we *never* use package-includes. Can we declare package-includes to be bad in general than and abandon it please? At least tell everyone not to use it if possible? To support functional testing, a 'kita-ftesting.zcml' slug was placed in the 'package-includes' and - as far as I can tell - this takes care to only load this ZCML when running functional tests. I have no idea what you are trying to say. The 'package-includes' mechanism is set up in a normal instance that site-zcml does not load *-ftesting.zcml slugs, whereas ftesting.zcml does includes *-ftesting.zcml slugs, so you can 'safely' place your ftesting configuration there. We're having a problem with the buildout integration at this point, as for the testrunner we are using the zc.recipe.testrunner recipe. However, the functional testing ZCML is placed in the instance part, but the testrunner does not know anything about this (should it?). You'll need to use the working-directory option in the testrunner recipe to get it to run from the instance. The functional test code in zope.app.testing.functional *assumes* that the current working directory is an instance directory. :( Ah. I didn't make the connection in my brain to make the test runner change the working directory. That sounds reasonable right now. Here's the question: what would be a good way to get the test runner load the correct ZCML for running tests? IMO, the package you want to test should define it's own ftesting.zcml and define a zcml-based test layer based on that. see zc.sharing as an example. Ah. I forgot to use zc.sharing as a buildout example. Thanks, Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZCML, functional testing and buildout
Christian Theune wrote: Hi, Jim Fulton wrote: Christian Theune wrote: Hi everyone, Thomas Lotze and I were working on creating a zc.buildout for one of our internal projects. The ZCML of our application is loaded using the 'package-includes' mechanism. I think this is a bad idea. I think for serious development, package-includes is a bad idea. For our projects, we *never* use package-includes. Can we declare package-includes to be bad in general than and abandon it please? At least tell everyone not to use it if possible? There are more opinions than just mine. :) I think package-includes or something like an egg basket could be useful for an application, like plone, that wants to support extension by non-developers. But for developers, I think direct zcml includes is better. I've been meaning to write up some thoughts on this topic for some time. Hopefully, I'll find time for it soon. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZCML, functional testing and buildout
Hi, Jim Fulton wrote: Christian Theune wrote: Can we declare package-includes to be bad in general than and abandon it please? At least tell everyone not to use it if possible? There are more opinions than just mine. :) I think package-includes or something like an egg basket could be useful for an application, like plone, that wants to support extension by non-developers. But for developers, I think direct zcml includes is better. Right. I guess in our case the package-includes isn't needed. But if we do support it, it should be supported well. I've been meaning to write up some thoughts on this topic for some time. Hopefully, I'll find time for it soon. :) I'm very happy with zc.buildout in general and look forward to start using it much more, but the recipes need some polish and some of the integration issues just start coming up while we're using it and make me a bit nervous about using it full-scale. We'd love to contribute, so having some guidance on the ideas would be very appreciated. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZCML, functional testing and buildout
Christian Theune wrote: ... I've been meaning to write up some thoughts on this topic for some time. Hopefully, I'll find time for it soon. :) I'm very happy with zc.buildout in general and look forward to start using it much more, Great! but the recipes need some polish Yup, especially the Zope 3 instance recipe. and some of the integration issues just start coming up while we're using it and make me a bit nervous about using it full-scale. Yes, of course. It is early and we're in a bit of a prototyping mode, learning from experience and making things better incrementally. We'd love to contribute, so having some guidance on the ideas would be very appreciated. Ok, I'll think about that. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?
Benji York wrote: Chris Withers wrote: I don't think it'll be a common pattern, but it doesn't feel right to me that a named adapter (ie: one registered with a specific name) has no way of finding out what name it has been registered with... Because the same adapter can be registered more than once, it would actually need to find out all the names with which it was registered. Really? Now this is a use case I hadn't thought of.. can you give me some examples of where you've run into this? This seems somewhat analogous to a Python object being given multiple names. In that case too, there is no way for the object to know what it's names are. Hmmm, okay, but I'd counter with both Zope 2 and Zope 3 having the notion of an object knowing its own name. Certainly in Zope 2, everything has an id or .getId(). That pattern evolved for a reason ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Can an adapter find out what name it was registered for?
Tres Seaver wrote:
for name in ('vindaloo', 'madras', 'tiki_masala'):
globals()[name] = MNA_factory_maker(name)
and then in ZCML:
adapter for=.interfaces.IChicken
provides=.interfaces.ICurry
name=vindaloo
factory=.adapters.vindaloo /
...but here you have to specify the same info twice and hence duplicate
info and get it identical in two places, which feels icky to me.
Is there a python-only way to register adapters instead of in ZCML and,
if it exists, is it safe to use in conjunction with the normal zcml dances?
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?
Chris Withers wrote: 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? I don't know that I have, but the component system doesn't preclude it so anything we come up with will have to take it into effect. 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 ;-) Sure, where everything is defined as content space objects, other objects more rarely. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?
On Tue, Nov 28, 2006 at 06:12:19PM +, Chris Withers wrote: 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? There's always a way :) You could just do what the directive does - call the adapter() function which used to be in zope.app.component.metaconfigure but now lives in zope.component.zcml. I haven't done it but AFAICT it should work safely. It's sometimes instructive to look at how directives are implemented. Find the meta.zcml file that declares the directive, and that'll tell you what module contains the schema and handler for that directive. The handler does the work. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildout WHUI heads up
This is a heads up that I'm going to call we haven't used it!
on a couple of buildout features. The next release of buildout
will not support ConfigParser-style variable substitutions
(e.g. %(foo)s). Only the string-template style of variable
(e.g. ${section:option}) substitutions will be supported.
Supporting both violates there's only one way to do it.
I'm deprecating the buildout-section extendedBy option.
Ian suggested to me a while ago that this wasn't needed
and I've come to agree with him.
If anyone is using these features and will have pain
by having them disappear, please let me know. It will be
at least a couple of days, probably more, before I make
a new release.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Can an adapter find out what name it was registered for?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: Chris Withers wrote: 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? I don't know that I have, but the component system doesn't preclude it so anything we come up with will have to take it into effect. I have already used the same adapters registered under different names (including the default empty string name). The CA is about allowing component configuration to express policy, which sometimes means that reusing an adapter makes sense (e.g., one might override the 'bar' named adapter for a particular object, while leaving the 'foo' adapter alone; the fact that the default registration uses the same factory for 'foo' and 'bar' Just Works now). I would argue that having adapters which need to know their name is *very* unusual, in fact. 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 ;-) Sure, where everything is defined as content space objects, other objects more rarely. That pattern has actually been the source of a lot of lost hair in the past -- content itmes know their IDs, which means that renaming them involves modifying *both* the container *and* the item. There was a fishbowl proposal for Zope2 to move the ID into the acquisition wrapper, which would have removed the need for content items to know them. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbNMH+gerLs4ltQ4RAheTAJ4rQee1njxmI0t4BrNkn8ikLzNThwCfWp/b EHnI2flrrxL0d33v9oLudcg= =hm22 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
