Hi again Mauro, Sorry for the delay in my response and thanks a lot for your answers!
I have created the JIRA <https://jbehave.atlassian.net/browse/JBEHAVE-1172>for this. It goes without saying that I take this as a first draft. I'm aware that it might need refinement and/or splitting. I would really appreciate if you guys could take some time after 4.1 to have a look and give me your feedback. As I mentioned before I think it would be a nice addition to the framework! :) Again, many thanks for your time and good luck with the new version! On Monday, May 23, 2016 at 8:06:25 PM UTC+2, mauro.talevi wrote: > > Hi Laura, > > the functionality you describe is interesting and merits further > investigation. > > A context object managed by JBehave could be rather useful, but we’d need > to ensure that the API is sufficiently generic to be reused in different > scenarios. We could use generics to this end. > > For starters, please raise a new JIRA describing your requirements. > > For the moment, I want to concentrate on getting 4.1 out by end of month. > Thereafter, we can tackle the new behaviour. > > Cheers > > On 22 May 2016, at 06:47, Laura Ruiz <[email protected] <javascript:>> > wrote: > > You're completely right, mauro. > > These are two different concerns, as you say, the matching of the step and > the actual implementation of the step. We both agree they should be kept > separated. > The idea of having them in different layers is actually good and having > the current functionality of JBehave I think it's a really nice way to > achieve it. > > These responsibilities should be kept separated, I couldn't agree more to > this. But keeping them separated can be achieved in many different ways. > You know, for example, look at the design of JAX-RS > <https://es.wikipedia.org/wiki/JAX-RS>. You can use annotations so the > library injects different parameters to your method. You can inject path > params, query params, headers, etc... > We were trying to achieve something similar. > > We understand this functionality is a kind of cross-cutting concern, as is > the injection of parameters from the Context. > > Actually, let's go even further: JBehave could really cover this > responsibility, as does JAX-RS. It would be awesome, actually, if JBehave > was responsible of handling the Context and injecting the parameters by > following the annotations. All transparent to the client of the library. > I honestly think that will make JBehave much more powerful. > > What I'm proposing here is just a really small step in that direction, > though. Modifying the step matching so JBehave can do it the way it does > now, but ignoring the parameters marked with a certain annotation. > This way we can implement the part where the annotated parameters are > taken from the Context and injected to the method. > At the end of the day the two responsibilities you mention are still > separated. > > I really believe many users of the framework can benefit from this. What > do you think? > > > On Thursday, May 19, 2016 at 10:25:54 AM UTC+2, mauro.talevi wrote: >> >> Hi, >> >> I think you’re mixing two concerns here - one is the steps matching, the >> other the programming one. >> >> The steps matching layer should be only concerned with matching the >> textual steps with the methods and the signature should reflect the >> parameters you chose in the textual layer. This should then delegate to >> a service layer in which the methods have signatures closely matching the >> functionality they provide. >> >> The Context object should live in the steps matching layer and provide >> the parameters that are used to access the service programming layer. The >> steps layer should be as thin as possible. >> >> Have a look at the examples - they show how these two layers can interact >> effectively. >> >> Cheers >> >> On 18 May 2016, at 18:36, Laura Ruiz <[email protected]> wrote: >> >> Thanks for your answer, mauro! >> >> Look, the reason why we want this is basically good programming >> practices. The code is clearer if you can understand what a method needs as >> input just by looking its signature. >> So far you can look at the method signature and know about the parameters >> that are explicit in the step, but to know about the parameters obtained >> from the context you need to go into the body of the method. >> >> We'd like to make these input explicit. So we implemented an aspect that >> would take parameters from the context and inject them into the method by >> reading its annotations. >> >> As I said, the problem we have is that JBehave doesn't accept this, as >> the number of parameters of the step and the number of parameters in the >> actual method are different. >> So I'd like to know if there's some way to force JBehave to ignore these >> extra parameters by marking them with an annotation or something similar. >> >> Is it clearer now? >> >> >> On Wednesday, May 18, 2016 at 12:22:18 PM UTC+2, mauro.talevi wrote: >>> >>> Hi, >>> >>> The context is a user defined object so it is not known to JBehave. >>> >>> If you want to inject parameters in methods you could use the @Named >>> annotation, specifying the name-value pairs in the Meta: section. >>> >>> That said, it's not clear why you'd want to do this, as the values of >>> the Context will be already accessible without injection in the signature. >>> >>> Could you explain your usecase better? >>> >>> On 17 May 2016, at 20:05, Laura Ruiz <[email protected]> wrote: >>> >>> Hi there, >>> >>> I'm currently working with JBehave and we implemented a Context object >>> where we store data that we need to share between different steps. >>> >>> Now, we are considering some improvements on this, like explicitly >>> passing this data to the methods that implement these steps. >>> >>> Imagine you have a first step which will create a user and store its >>> credentials into the Context. >>> These credentials are needed in the second step. We would like to have >>> some kind of annotation that allowed us to implement our step like this: >>> >>> @When("...some step definition which includes some $parameterFromStep") >>> public void someMethod(String parameterFromStep, @FromContext( >>> "userCredentials") String userCredentials) { ... } >>> >>> >>> We tried to implement some logic that would take the parameter from the >>> Context and pass it to the method. The problem with this is that JBehave >>> doesn't find a method matching this step, as the method has the wrong >>> number of parameters (it expects 1 but the method has 2). >>> >>> So my question is: Is there any way of doing this with the current >>> implementation? Is there any way to force JBehave, for example, ignore the >>> parameters that are annotated? >>> >>> I would really appreciate some guidance on this. Let me know if >>> something is something needs extra clarifications, please. >>> >>> Thank you guys. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "JBehave User" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web, visit >>> https://groups.google.com/d/msgid/jbehave-user/0fae230a-b5f6-4dc8-95ff-d3f4bb500ad1%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jbehave-user/0fae230a-b5f6-4dc8-95ff-d3f4bb500ad1%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "JBehave User" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/jbehave-user/6f890c66-d546-46c1-98fa-1e1714ffeb67%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jbehave-user/6f890c66-d546-46c1-98fa-1e1714ffeb67%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "JBehave User" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/jbehave-user/0dfb9a4c-376a-40e0-b757-471b6b5355d1%40googlegroups.com > > <https://groups.google.com/d/msgid/jbehave-user/0dfb9a4c-376a-40e0-b757-471b6b5355d1%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "JBehave User" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/jbehave-user/ef0e98ac-4e77-41a0-9c22-4cc4cdfa193b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
