Allow mapping of ExamplesTable rows to annotated custom types

Interesting! Do you have a POC or spike of this somewhere showing it in action?

Working on it

Here's a POC, only using annotations for now...

git@github.com:JSlain/jbehave-core.git
branch: pojo_table

Here's a test that shows it in action:
org.jbehave.core.io.stories.pojotable.PojoTableStory

Not sure about the classes name, seems ugly to me...

I'll continue the POC to support manual mapping, the second way to map a pojo, without annotations.

Added support for manually-defined mapping (for example, enable mapping with third-party objects, which you cannot annotate).
Also added support for methods receiving a single object instead of a list.

the example now illustrate the 4 usage:

    @Given("the following annotated table: $table")
    public void givenExamplesAnnotatedPojo(List<MyAnnotatedPojo> pojos){}

    @Given("the following annotated single-element table: $table")
    public void givenExamplesAnnotatedPojo(MyAnnotatedPojo pojo){}

    @Given("the following non-annotated table: $table")
    public void givenExamplesNonAnnotatedPojo(List<MyNonAnnotatedPojo> pojos){}

    @Given("the following non-annotated single-element table: $table")
    public void givenExamplesAnnotatedPojo(MyNonAnnotatedPojo pojo){}

Hi Ghislain,

many thanks for your contribution. The idea is rather interesting, but at a quick glance the code to implement it seems a bit too elaborate for what it gives us.

To sum up the idea, what you're looking for is to map a list of Parameters objects (as obtainable from the ExamplesTable) to user-defined classes (annotated or not).

I'm thinking there may be simpler way to do. Let me mull over it.

Cheers

Well, it's a POC.

Sure, and that's why we can use the POC as a starting point and look at different ways to implement it.

For example, adding a method to ExamplesTable

public <T> List<T> getRowsAs(Class<T> type);

may be simpler to convert Parameters to type <T>. Then having an annotation on type <T> to trigger use the converter, as you suggested with your @TableDef.

Great idea, and that would prevent from touching multiple classes from the core.
Also, almost all the sources from the poc may only be moved into ExamplesTable for getting it to work.

Hi Ghislain,

I've push an initial implementation. Have a look at latest snapshot. The story you proposed is verified, see examples_table_parameters.story, albeit with a rather slimmer implementation (only add the annotations @AsParameters and @Parameter as new classes).

Your feedback would be most welcome. Feel free to propose enhancements.

Cheers

Hi Mauro,

this is actually pretty nice and easy to use!
I still think it could be of some use to be able to map a third party object by defining a mapping between the third-party fields against the column names.
Something like:

public class ThirdPartyClass{
    private Integer aInteger;
}

ParameterMapping map = new ParameterMapping();
map.addMapping("scenarioColumn1", "aInteger");

examplesTable.getRowsAs(ThirdPartyClass.class, map);

Btw, thanks for reformulating my messages, you might have noticed english is not my native language.

What's the advantage of doing this over the annotations?

public class ThirdPartyClass{
    @Parameter(name = "scenarioColumn1")
    private Integer aInteger;
}

If you're accessing the ExampleTable directly then you can use the Parameters interface

Parameters parameters = examplesTable.getRowsAsParameters().get(0);
parameters.valueAs("scenarioColumn1", Integer.class);

Well, when i talk about third-party classes, i mean classes from external libraries you're using, but cannot/won't change the sources.
It would also apply to business objects you'll be using in production, which you don't want to add the smell of test-related annotations.

You're right about the fact that we can manually use the Parameters class to build another object, i just thought it would be more "from the table to the object" that way.
In fact, it also lead to another subject i'm going to bring soon, which would also be advantaged by the use of a separated configurable mapping object.

Right, this usecase could indeed be useful. I've added the ability to specify an optional map with the field name mapping. Check latest snapshot.

Thanks for your insight and suggestions!

Nice!
Thanks for the development.
I guess you can close the issue.