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 <laura....@gmail.com <javascript:>> > 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 <laura....@gmail.com> 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 jbehave-user...@googlegroups.com. >> To post to this group, send email to jbehav...@googlegroups.com. >> 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 jbehave-user...@googlegroups.com <javascript:>. > To post to this group, send email to jbehav...@googlegroups.com > <javascript:>. > 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 jbehave-user+unsubscr...@googlegroups.com. To post to this group, send an email to jbehave-user@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/jbehave-user/0dfb9a4c-376a-40e0-b757-471b6b5355d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
