Hi all, I created a PR with an initial version of this feature.
https://github.com/jbehave/jbehave-core/pull/127 Currently @Before/@After methods do not support these new annotations. ImmutableCollections is out of the scope, I think it is something that user should do when returning the object, rather than forcing to use immutable collections. A new method in StepMonitor should be created to report parameters from Context. Unfortunately methods to reset object repositories are public, they need to be called from PerformableTree. No Examples/HTML Documentation has been created yet. I just wanted to know that we all agree with the current approach before progressing with it. Please let me know your thoughts about this. Best Regards, Rafa. El miércoles, 25 de mayo de 2016, 21:38:18 (UTC+2), Laura Ruiz escribió: > > 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 <laura....@gmail.com> 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 <laura....@gmail.com> 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. >>> 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/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...@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/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 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/ae2278d3-ef94-4497-be09-39a7d210d815%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
