Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
Hi. On Thu, Aug 19, 2010 at 4:08 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 19 August 2010 09:52, Alec Mitchell ap...@columbia.edu wrote: Though I voted against the inclusion of the UUID PLIP on it's own, if the link-by-uuid PLIP makes good use of it, then it certainly could be worth including. I'd like to work with David to make sure that happens. It seems like an obvious win. Please be aware that the link-by-uid functionality is multi-lingual aware. As such it relies on looking up the translations of any UID target. If you change the behavior to use a different uid mechanism, it becomes more expensive to calculate those translations, as we'd have to convert from AT UID's to uuid's a number of times. I'd prefer if we kept all reference / link related functionality to use the AT functionality for now. Once we have plone.uuid as part of core Plone, I'm planning to rewrite LinguaPlone to make use of this instead of the AT uid's. At that point we can more easily switch features over to the new mechanism. So far as I was hoping to see the plone.uuid feature to make it into 4.1, which would give me enough time to finish the LinguaPlone move for 4.2. I can only work on this if we do get plone.uuid into 4.1 though. Requiring the complete uuid installation as part of a LinguaPlone upgrade is too much to ask from users. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
Le 19/08/10 12:29, Sidnei da Silva a écrit : On Wed, Aug 18, 2010 at 2:14 PM, Dorneles Treméadorne...@tremea.com wrote: from his recent work on Canonical, I'm sure Sidnei has some great insights to share here, don't you Sidnei? :-) We've been using YUI, so Y.Test as the test framework. We run tests manually in the browser when debugging, but for automated unit tests we use JsTestDriver from Google to drive the tests, save output to XML then report failure/success back to Python's unittest by parsing the XML. There's a little bridging needed to get the tests registered with JsTestDriver, but not terrible. JsTestDriver ships with a version of jQuery, but might not be the same you guys are using. There's another test runner coming up, YETI, but it might be YUI-specific. Is JsTestDriver qUnit compatible ? For functional tests, we're using Selenium2, which is alpha-something IIRC. It's *way* better than Selenium1. We're using the webdriver API (remote webdriver and Firefox, on local machine), and it's Good Do you test multiple browsers or only Firefox ? Enough, just forget about recording tests in the browser and saving them - at least for now. One way or another, writing tests manually isn't that hard once you get the idea, and produces better, more concise tests, specially if you have to match elements with CSS classes or XPath. Do you use Selenium IDE or write from scratch ? The Launchpad team is using Windmill. From the amount of groaning I hear over there, I would avoid it at all costs. First time I hear bad sound about Windmill. Happy that I am no the only one not convinced. It is possible to run headless tests with both Selenium2 and Windmill, under xvfb-run. Pretty trivial actually. Forget about writing a ton of tiny tests though. I would say functional Selenium tests should be end-to-end, massive use case tests. Because they take a long time to run. If you think Plone tests take a long time, think again. ;) Reason why I insist on automated tests. Functional tests run too slowly to rely on developers running them regularly. We need to delegate to Hudson or buildbot. -- Sidnei Regards -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On 19 August 2010 23:24, Godefroid Chapelle got...@bubblenet.be wrote: First time I hear bad sound about Windmill. Happy that I am no the only one not convinced. I hear bad sounds too from time to time, but no-one has yet been able to tell me what the real problem is. I'd be quite interested in any specifics. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
Le 18/08/10 19:01, David Glick a écrit : Godefroid, I am definitely interested to learn from your experience in this area. Regarding functional testing of Javascript, would you recommend looking at KSS to see how it is done there, or are there newer best practices that have emerged since those tests were written? I think KSS testing practices are OK. Browse to http://demo.kssproject.org/zuite/core/TestRunner.html?test=http//demo.kssproject.org/suite.html Then click Run all tests However, we miss continuous integration. I am procrastinating since a long time to refactor KSS buildout and add a builbot buildout. I guess it should not be that hard today (compared to the hell it was) when I sum up advances in Selenium RC, buildbot and buildout. I would definitely take a look at gocept.selenium. Gocept has worked a lot on it those last monthes so I guess if fits their workflow. Christian, would someone from your team mind to give us some feedback ? Regards -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
About a month ago, I spent some time with windmill, trying to do tests for plone.app.jquerytools. Windmill looked OK, but when I tried to automate the testing as a test case with niteoweb.windmill, I encountered lots of problems and ended up giving up on it. It looked like I was having trouble anytime content was changed by a test. Perhaps I wasn't patient enough, or misunderstood something about the framework, but it seemed at times like I was working in a multi-threaded environment where the threads weren't synchronized. Steve On Thu, Aug 19, 2010 at 7:37 AM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: On 19 August 2010 23:24, Godefroid Chapelle got...@bubblenet.be wrote: First time I hear bad sound about Windmill. Happy that I am no the only one not convinced. I hear bad sounds too from time to time, but no-one has yet been able to tell me what the real problem is. I'd be quite interested in any specifics. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On 20 August 2010 00:26, Steve McMahon st...@dcn.org wrote: About a month ago, I spent some time with windmill, trying to do tests for plone.app.jquerytools. Windmill looked OK, but when I tried to automate the testing as a test case with niteoweb.windmill, I encountered lots of problems and ended up giving up on it. It looked like I was having trouble anytime content was changed by a test. Perhaps I wasn't patient enough, or misunderstood something about the framework, but it seemed at times like I was working in a multi-threaded environment where the threads weren't synchronized. Strange. We've never seen anything to that effect. Oh well. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On Wed, Aug 18, 2010 at 7:08 PM, Martin Aspeli optilude+li...@gmail.com wrote: Hi Alec, On 19 August 2010 09:52, Alec Mitchell ap...@columbia.edu wrote: Though I voted against the inclusion of the UUID PLIP on it's own, if the link-by-uuid PLIP makes good use of it, then it certainly could be worth including. I'd like to work with David to make sure that happens. It seems like an obvious win. If there were a PLIP to make AT compatible with this implementation and convert Plone to using it, that would be a highly compelling argument for its inclusion. I think Plone using it should mean the link by UID mechanism in the first instance. I'd like to experiment with making the AT UID() and reference/UID catalogs use plone.uuid as well. Certainly, that's where I'd like us to end up. I just didn't want to be too ambitious with the PLIP in the first instance, in case we end up with complicated migrations or BBB issues. Of course, plone.uuid on its own works perfectly well with Archetypes objects. The problem is that as it's written right now, it doesn't care about the AT UID() method and related catalogues. One thing we probably could do, is to make the Archetypes make_uuid() method use the same UUID algorithm as plone.uuid. I'm not sure if we'd want to migrate old content. They probably shouldn't clash, and making changes could be problematic in case of embedded link-by-uid references and similar. We could also/instead make an IUUID adapter implementation for Archetypes content that looked context.UID(), and let AT continue to manage its own UUIDs (but ideally using the same UUID generating algorithm) to bridge the two. We could make the UUID indexer use the UID catalogue index instead of creating a new one. This would be more consistent, at least if the UUIDs looked and worked the same. If there's appetite for this type of a change, I'd be happy to implement it. I think this is probably the way forward; though for 4.1 we should probably do our best to preserve existing UIDs and avoid serious content migration headaches. One thing that concerns me on the technical side is that a universal UUID mechanism isn't really all that useful unless existing code (e.g. the AT reference browser) provides support for it. Without at least some minimal support within the existing framework, it would appear to make the lives of people who live on the bleeding edge (e.g. dexterity users) slightly easier at the expense of inconveniencing the vast majority of users by forcing a slow and largely unnecessary migration step. Otherwise we end up with Plone directly using one non-deprecated UID API while promoting another (which happens to not be useful anywhere within Plone itself). Don't we already suffer from enough of this kind of framework-level confusion? I guess it depends on your point of view. To me, we don't actually have proper UUID mechanism at present. Archetypes has a UID() method, which exposes an ID that's principally used as an implementation detail of its reference engine. That reference engine (and by extension the UID() method and the way in which it generates UUIDs) is tightly bound to AT's base classes and virtually impossible to use elsewhere. You can't have these kinds of UID's on comments, for example, or on portlets, or on the Plone site object, or on any non-AT content (e.g. using Dexterity). I wrote the PLIP because I'm uncomfortable with the status quo. People end up making their own half-solutions, e.g. using their own counters, physical paths (which are not stable), keeping their own BTrees of content, using zope.intid or faking up the UID() method in a way that isn't quite compatible with how AT uses it. It's my impression that people who are doing things with non-AT content are an extremely small and highly experienced minority of Plone users. I suspect that the vast majority of those users are core developers and subscribe to this list. Those users are probably already aware that plone(.app).uuid is the future and can depend on it if they need it. If not, those who wish to promote it as such can do so, but I don't think that should be the job of the framework team (or the framework itself). By including this wouldn't we essentially be saying, Martin made this, and we think it's a nice thing; so now it's part of the core? What other nice little libraries should we make part of Plone just because they might be useful to some developers or are used by a few add-ons that we happen to like? I'm sure we could think of quite a few, but I also think there's a good reason we don't generally do this. I agree with this, and I'm really not shy about keeping packages as non-core dependencies. In this case, though, I think there are compelling reasons to have a single API that is exposed as a service by the core of Plone, as outlined in my original message above. Adopting a library that we don't actually use, promotes a vision
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
I should have added that I'm very enthusiastic about getting some JavaScript continuous integration testing in place, and will happily learn whatever framework we choose. We're getting way too much browser-side code to be without systematic tests. On Thu, Aug 19, 2010 at 8:40 AM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: On 20 August 2010 00:26, Steve McMahon st...@dcn.org wrote: About a month ago, I spent some time with windmill, trying to do tests for plone.app.jquerytools. Windmill looked OK, but when I tried to automate the testing as a test case with niteoweb.windmill, I encountered lots of problems and ended up giving up on it. It looked like I was having trouble anytime content was changed by a test. Perhaps I wasn't patient enough, or misunderstood something about the framework, but it seemed at times like I was working in a multi-threaded environment where the threads weren't synchronized. Strange. We've never seen anything to that effect. Oh well. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On Thu, Aug 19, 2010 at 11:37 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 19 August 2010 23:24, Godefroid Chapelle got...@bubblenet.be wrote: First time I hear bad sound about Windmill. Happy that I am no the only one not convinced. I hear bad sounds too from time to time, but no-one has yet been able to tell me what the real problem is. I'd be quite interested in any specifics. Put simply: Both Selenium1 and Windmill use Javascript to control the browser, which isn't great because it has to compete with Javascript executing in the browser. Selenium2 uses WebDriver, which controls the browser by way of browser-specific extensions (it takes care of setting up a profile with the extension installed for you), so it has full control over the browser, even allowing interaction with browser dialogs and taking screenshots. -- Sidnei ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team M eeting Minutes– 17 August, 2010
On Aug 19, 2010, at 10:24 AM, Godefroid Chapelle wrote: Reason why I insist on automated tests. Functional tests run too slowly to rely on developers running them regularly. We need to delegate to Hudson or buildbot. I agree completely. I very nearly* have a Hudson/Selenium Grid/plone.app.testing pile running Selenium tests automatically across multiple browsers and machines. If I can convince the kid to give me a few free hours to work today, I'll wrap it up and write up what I have. * For some definition of nearly Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
Hi Alec, On 20 August 2010 00:56, Alec Mitchell ap...@columbia.edu wrote: I'd like to experiment with making the AT UID() and reference/UID catalogs use plone.uuid as well. Certainly, that's where I'd like us to end up. I just didn't want to be too ambitious with the PLIP in the first instance, in case we end up with complicated migrations or BBB issues. Of course, plone.uuid on its own works perfectly well with Archetypes objects. The problem is that as it's written right now, it doesn't care about the AT UID() method and related catalogues. One thing we probably could do, is to make the Archetypes make_uuid() method use the same UUID algorithm as plone.uuid. I'm not sure if we'd want to migrate old content. They probably shouldn't clash, and making changes could be problematic in case of embedded link-by-uid references and similar. We could also/instead make an IUUID adapter implementation for Archetypes content that looked context.UID(), and let AT continue to manage its own UUIDs (but ideally using the same UUID generating algorithm) to bridge the two. We could make the UUID indexer use the UID catalogue index instead of creating a new one. This would be more consistent, at least if the UUIDs looked and worked the same. If there's appetite for this type of a change, I'd be happy to implement it. I think this is probably the way forward; though for 4.1 we should probably do our best to preserve existing UIDs and avoid serious content migration headaches. One thing that concerns me on the technical side is that a universal UUID mechanism isn't really all that useful unless existing code (e.g. the AT reference browser) provides support for it. Without at least some minimal support within the existing framework, it would appear to make the lives of people who live on the bleeding edge (e.g. dexterity users) slightly easier at the expense of inconveniencing the vast majority of users by forcing a slow and largely unnecessary migration step. So, we must provide some new features so that we can justify the feature we want to have. :-) Anyway, if the PLIP is accepted, I'd be happy to spend some time on selective AT surgery (including the widget), unless the FWT feels this is too risky. Ditto for link-by-uid in general. It's my impression that people who are doing things with non-AT content are an extremely small and highly experienced minority of Plone users. The Dexterity list subscription rate and issue tracker suggest this is at least starting to change. It's easy to choke off adoption with that attitude, though. Three of the biggest holes in the Dexterity story that makes life difficult right now are a lack of link-by-uid, no mature multilingual support, and an inability to use Dexterity objects as reference targets from AT content. The first we can solve for 4.1 with this PLIP. The second will become more feasible with proper UUIDs according to Hanno. And the latter is the ideal end goal of any AT refactoring as per above. I suspect that the vast majority of those users are core developers and subscribe to this list. Those users are probably already aware that plone(.app).uuid is the future and can depend on it if they need it. If not, those who wish to promote it as such can do so, but I don't think that should be the job of the framework team (or the framework itself). I think you're missing my point: Since a UUID is only useful if it's universally applied to all content, it needs to be a service provided by Plone and in effect for all content and other objects, such as comments and (possibly) users, groups, etc. Simply depending on the package and using its API is not enough (if it was, I would never have submitted the PLIP). At the very least, any and all packages wanting proper UUIDs would need to provide a blunt installation step to allocate and index UUIDs for all content, with some logic to understand when this would be needed. Furthermore, divergent implementations create non-trivial duplication of effort and catalogue bloat. Hanno already indicated he was uncomfortable with this as a LinguaPlone requirement. So, at least, we have two big third party packages - LinguaPlone and Dexterity - asking for this functionality so that they themselves can move forward, with a view to improving Plone core in the future. The question to me is how we balance the risk of doing too much now in terms of modifying existing core components, against the risk of doing something that ultimately proves an inferior solution and doesn't get used properly. I think this is the sort of evolutionary argument we're always going to have for framework improvement work. All that said, I think we may solve this problem by widening the PLIP to include more of the AT changes up front, which is probably a good thing anyway. Also: this discussion now has more lines of text than plone.uuid and plone.app.uuid have code. But that may be my own fault. ;-) Martin
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
Le 19/08/10 18:14, Eric Steele a écrit : On Aug 19, 2010, at 10:24 AM, Godefroid Chapelle wrote: Reason why I insist on automated tests. Functional tests run too slowly to rely on developers running them regularly. We need to delegate to Hudson or buildbot. I agree completely. I very nearly* have a Hudson/Selenium Grid/plone.app.testing pile running Selenium tests automatically across multiple browsers and machines. If I can convince the kid to give me a few free hours to work today, I'll wrap it up and write up what I have. Have you written a new layer ? Have you looked at gocept.selenium ? * For some definition of nearly Eric -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
Hi Martin, On Thu, Aug 19, 2010 at 9:24 AM, Martin Aspeli optilude+li...@gmail.com wrote: Hi Alec, On 20 August 2010 00:56, Alec Mitchell ap...@columbia.edu wrote: I'd like to experiment with making the AT UID() and reference/UID catalogs use plone.uuid as well. Certainly, that's where I'd like us to end up. I just didn't want to be too ambitious with the PLIP in the first instance, in case we end up with complicated migrations or BBB issues. Of course, plone.uuid on its own works perfectly well with Archetypes objects. The problem is that as it's written right now, it doesn't care about the AT UID() method and related catalogues. One thing we probably could do, is to make the Archetypes make_uuid() method use the same UUID algorithm as plone.uuid. I'm not sure if we'd want to migrate old content. They probably shouldn't clash, and making changes could be problematic in case of embedded link-by-uid references and similar. We could also/instead make an IUUID adapter implementation for Archetypes content that looked context.UID(), and let AT continue to manage its own UUIDs (but ideally using the same UUID generating algorithm) to bridge the two. We could make the UUID indexer use the UID catalogue index instead of creating a new one. This would be more consistent, at least if the UUIDs looked and worked the same. If there's appetite for this type of a change, I'd be happy to implement it. I think this is probably the way forward; though for 4.1 we should probably do our best to preserve existing UIDs and avoid serious content migration headaches. One thing that concerns me on the technical side is that a universal UUID mechanism isn't really all that useful unless existing code (e.g. the AT reference browser) provides support for it. Without at least some minimal support within the existing framework, it would appear to make the lives of people who live on the bleeding edge (e.g. dexterity users) slightly easier at the expense of inconveniencing the vast majority of users by forcing a slow and largely unnecessary migration step. So, we must provide some new features so that we can justify the feature we want to have. :-) In my opinion, there must be a feature that's meaningful for Plone the application to justify adding features to the Plone the framework, yes. Anyway, if the PLIP is accepted, I'd be happy to spend some time on selective AT surgery (including the widget), unless the FWT feels this is too risky. Ditto for link-by-uid in general. Great, I don't think allowing the reference browser to support referencing non-AT content sounds particularly risky, and it's a pretty compelling feature (i.e Plone supports references between heterogenous content types). It's my impression that people who are doing things with non-AT content are an extremely small and highly experienced minority of Plone users. The Dexterity list subscription rate and issue tracker suggest this is at least starting to change. It's easy to choke off adoption with that attitude, though. Three of the biggest holes in the Dexterity story that makes life difficult right now are a lack of link-by-uid, no mature multilingual support, and an inability to use Dexterity objects as reference targets from AT content. The first we can solve for 4.1 with this PLIP. The second will become more feasible with proper UUIDs according to Hanno. And the latter is the ideal end goal of any AT refactoring as per above. The first is unequivocally solved by simply having dexterity depend on plone.app.uuid. For the second, if LinguaPlone wants to support dexterity, it can also depend on plone.app.uuid (even as a soft dependency if that's less worrisome). The third is the only part that this PLIP would seem to be necessary for, but it's not actually a part of this PLIP, as you know. I suspect that the vast majority of those users are core developers and subscribe to this list. Those users are probably already aware that plone(.app).uuid is the future and can depend on it if they need it. If not, those who wish to promote it as such can do so, but I don't think that should be the job of the framework team (or the framework itself). I think you're missing my point: Since a UUID is only useful if it's universally applied to all content, it needs to be a service provided by Plone and in effect for all content and other objects, such as comments and (possibly) users, groups, etc. Simply depending on the package and using its API is not enough (if it was, I would never have submitted the PLIP). At the very least, any and all packages wanting proper UUIDs would need to provide a blunt installation step to allocate and index UUIDs for all content, with some logic to understand when this would be needed. Furthermore, divergent implementations create non-trivial duplication of effort and catalogue bloat. Hanno already indicated he was uncomfortable with this as a
Re: [Framework-Team] Plone 4.1 Framework Team M eeting Minutes– 17 August, 2010
On Aug 19, 2010, at 12:32 PM, Godefroid Chapelle wrote: Le 19/08/10 18:14, Eric Steele a écrit : On Aug 19, 2010, at 10:24 AM, Godefroid Chapelle wrote: Reason why I insist on automated tests. Functional tests run too slowly to rely on developers running them regularly. We need to delegate to Hudson or buildbot. I agree completely. I very nearly* have a Hudson/Selenium Grid/plone.app.testing pile running Selenium tests automatically across multiple browsers and machines. If I can convince the kid to give me a few free hours to work today, I'll wrap it up and write up what I have. Have you written a new layer ? Have you looked at gocept.selenium ? * For some definition of nearly Eric I wrote a new layer, mainly because I wanted to figure out how it all worked. I've put up a quick screencast of the whole thing in action, if anyone's interested. http://blip.tv/file/4023258 Basically Hudson controls a Selenium Grid which doles out requests to the requested browsers based on RC instance availability. The testcase layer accepts environment variables for ZServer host/port and Selenium host/port/browser. I've created one job per browser (Firefox and Safari in the screencast), passing in a new port and browser string environment var in each. Selenium Grid will pass the request along to the first available RC instance with that browser identifier and that'll hit the one-off ZServer created by the testcase. We should be able to kick off each of these jobs after the Plone 4 build runs and AFAIK they'll run simultaneously without issue. The one thing I'm missing at the moment is preventing them from running during normal test runs, but David's shown me a way forward on that. Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meet ing Minutes– 17 August, 2010
Le 19/08/10 22:44, Eric Steele a écrit : I wrote a new layer, mainly because I wanted to figure out how it all worked. I've put up a quick screencast of the whole thing in action, if anyone's interested. http://blip.tv/file/4023258 Basically Hudson controls a Selenium Grid which doles out requests to the requested browsers based on RC instance availability. The testcase layer accepts environment variables for ZServer host/port and Selenium host/port/browser. I've created one job per browser (Firefox and Safari in the screencast), passing in a new port and browser string environment var in each. Selenium Grid will pass the request along to the first available RC instance with that browser identifier and that'll hit the one-off ZServer created by the testcase. We should be able to kick off each of these jobs after the Plone 4 build runs and AFAIK they'll run simultaneously without issue. The one thing I'm missing at the moment is preventing them from running during normal test runs, but David's shown me a way forward on that. Eric Thanks for the screencast ! It's great you went there. I look forward trying it myself. Is your layer available somewhere ? -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
