Look at TraderSteps, and where you see the StepsFactory in use, imagine using PicoStepsFactory or GuiceStepsFactory instead. Its not meant to be an abstraction as its end-user code. What it means is that Guice will be able to fill constructors for Steps POJOs. Not sure about scopes, JB seems to want all of the instances to steps up front.
What I was trying to do over Xmas (but may have to rollback) was Pico do all of that AND take over the injection into the methods themselves. Pico calls that reinjection and it was pretty close to working with some limits. The positive side was that it would have allowed extra parameters in the givens/whens/thens for other Pico managed components from some parent scope. That would mean that you would not have to make member variables for things and have them passed in through constructors. Was too hard to get right though as JB has its own parameter converters. So we'll pull back from that vision, and do it in JB 2.6 or somesuch (as an extension of course). If you wanted to code a Guice version of the StepsFactory, it'll take your a few hours now at most (with tests). I;d have the Pico one re-done already, but I'm working on client stuff today. Regards, - Paul On Jan 7, 2010, at 11:00 AM, Cristiano Gavião wrote: > Hi Paul, > > Im looking for those changes right now... > > I are right, do not have to extends Steps and to allow addSteps out of > constructor will help a lot... > > nice job !! > > > > Paul Hammant escreveu: >> It is not going to make it to 2.4, no. Though some of teh refactorings >> we're doing in 2.4 will facilitate. One that Mauro's completing now is >> making steps implementation classes POJOs. I.e. they don't have to extend >> Steps anymore. >> >> The Guice one should be pretty similar. >> >> Regards, >> >> - Paul >> >> On Jan 7, 2010, at 10:45 AM, Cristiano Gavião wrote: >> >> >>> Hi, >>> >>> >>> Humm, ok. I already tried some experimental work myself with guice and >>> jbehave, mostly unsucessfull until now... >>> >>> But I could get guice to work together with junit, but it was needed to >>> create an expecific extension of BlockJUnit4ClassRunner.. >>> >>> Btw, I really think that is should be postponed to 2.5. There is already a >>> lot of new features to deal with on 2.4 :-) >>> >>> regards >>> >>> Mauro Talevi escreveu: >>> >>>> Cristiano, >>>> >>>> the DI support is still very much experimental work we're doing with Paul. >>>> We're still trying to work out some fundamentals and if it's stable >>>> enough to release in 2.4, or need to postpone it to 2.5 (hence we've not >>>> gone "public" with it). As soon as we've got a stable build with examples >>>> we'll post the details and update the documentation. >>>> >>>> The issue related to this is JBEHAVE-133. We are currently working on >>>> Pico support, with other containers to follow suit. >>>> >>>> Cheers >>>> >>>> Cristiano Gavião wrote: >>>> >>>>> Hi people... >>>>> >>>>> I got glad to see that was commited some work for a new extension with a >>>>> DI container... very nice... >>>>> >>>>> I've got interested in knowing little more about this feature... >>>>> >>>>> What are the plans and desired behaviors for DI extension for jBehave. >>>>> What are the goals for this feature? >>>>> >>>>> Which classes would be enabled for being injected on jbehave context? >>>>> Steps on Scenarios? Configuration Classes in both steps and scenarios? >>>>> Third lib classes? >>>>> >>>>> And about configuring DI: using xml, properties or annotation? >>>>> >>>>> is there a issue for this on jira? >>>>> >>>>> thanks >>>>> >>>>> Cristiano >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe from this list, please visit: >>>>> >>>>> http://xircles.codehaus.org/manage_email >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this list, please visit: >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
