[
https://jira.codehaus.org/browse/JBEHAVE-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=288852#comment-288852
]
Daniel Schneller commented on JBEHAVE-702:
------------------------------------------
My modified Steps class in the ZIP works on both. Of course, it could be
limited to calling the permutation generator for aliases only.
However, what would you put into the "canonical" (i. e. @Given, @When, @Then)
annotations in that case? Maybe the first option of each variant pattern?
>From what I can see, that would bring back the redundancy I was trying to
>eliminate in the first place, especially with multiple patterns in one line.
{code:java}
@Then("A must be $x unless it's part of $y")
@Alias("A {must|has to|is to}be $x unless {it's|it is} {part of|contained in}
{list |}$y")
{code}
However, even when only adding the new feature to aliases, I see a problem with
backwards compatibility in cases where existing stories contain lines that for
some reason already have curly braces and/or pipes in them. Those would break
if the expansion were to suddenly take place, not matter if it were in the
aliases or the primary annotations.
For that reason I'd say one could add a (default false) boolean attribute to
the @Given/@When/@Then annotations that would require a conscious and explicit
decision to enable pattern expansion.
Like this:
*Example 1: unchanged behavior for existing story lines*
{code:java}
@Then("A {must |has to |is to |} be $x unless {it's|it is} {part of|contained
in} {list |}$y")
{code}
Would not be expanded, but used verbatim, just like it is today.
*Example 2: explicitly enabled expansion*
{code:java}
@Then(value="A {must |has to |is to |} be $x unless {it's|it is} {part
of|contained in} {list |}$y",
permutate=true)
{code}
Would work as described above.
The same would go for Alias/es as well to maximize backwards compatibility.
Maybe, depending on feature adoption, one could argue to change the default to
be true in some distant future version, however I think it would would not
really be necessary.
> Allow injection of the "Steps" class to customize its behavior
> --------------------------------------------------------------
>
> Key: JBEHAVE-702
> URL: https://jira.codehaus.org/browse/JBEHAVE-702
> Project: JBehave
> Issue Type: Improvement
> Components: Core
> Affects Versions: 3.5.4
> Reporter: Daniel Schneller
> Labels: i18n, wish
> Attachments: jbehave-702-1.zip, Steps.java, Steps.java
>
>
> To get more natural German story texts, it would be very helpful if the
> Steps.listCandidates() method could be amended.
> This would allow for automatically generating slight variations of the texts
> without having to specify them all as aliases. Currently I am doing this:
> @Then("soll foo bar with $xyz")
> @Aliases(values = {
> "foo bar with $xyz",
> "soll foo bar: $xyz",
> "foo bar: $xyz" })
> The word "soll" is made optional this way. The reasoning behind this is that
> when using "And" it is more natural to write
> Then soll something else
> And foo bar with $xyz
> instead of
> Then soll something else
> And soll foo bar with $xyz
> It would be very nice to not have define aliases for all these variants,
> because it makes the code harder to maintain. Instead, I though I'd add this
> dynamically, the same way annotated Aliases are, but it seems this
> functionality would require providing a new subclass of
> org.jbehave.core.steps.Steps which I cannot see how to do.
> I suggest a change like this:
> 1) In org.jbehave.core.steps.Steps add another call in listCandidates() after
> each of the addCandidatesFromAliases(...) like
> addCustomDerivedCandidates(...) with the same signature and a protected empty
> default implementation.
> 2) Allow configuration to specify a custom subclass of
> org.jbehave.core.steps.Steps. In there custom additions to the candidates
> list could be made, like the one I described.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
