Hi all, Any update on this?
Best Regards, Rafa. El miércoles, 13 de julio de 2016, 17:10:52 (UTC+2), Rafael Jimenez escribió: > > 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 <[email protected]> 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]. >>> 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/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/2c4a427d-1270-4413-bed3-aafeb8293914%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
