> > > > This makes it much easier to work with tables, lets me focus the > > stories on what's more important, "ignoring" some of the details. I > > tried just having my own @AsParameterConverter for ParameterTable, but > > although getAs(Integer.class, "id") worked, it wasn't picking up any > > of the other @AsParameterConverters I'd defined, so > > each.getAs(LocalDate.class) wasn't. > > > I'll have a look at this use case in more detail. Just to recap, you'd > like to have an extension of ExamplesTable that converts parameters for > you on demand, via the getAs(Class,String) method, > and in particular the conversion defined in methods annotated via > @AsParameterConverter, right? >
Essentially, that's right, although whether it's an extension or replacement, I'm in 2 minds about. I'd quite like to see a situation where any values that fail this conversion get specifically highlighted as such in the reports. Potentially changing the colour of the cell background that failed validation to red, and having the ones that passed validation green, or some such thing. I think this would be especially useful for Examples: tables actually, hence my hesitance for extension or replacement. I thought about just adding a new XXParameterConverter to ParametersConverters and passing the ParametersConverters instance in via the constructor, but I dislike doing that, as the ParametersConverters wouldn't be fully initialised. Also, you're then limited to ParameterConverters defined as classes if they want to access ParametersConverters for nested conversions. The other option was to create a new interface ParameterConverter2, which had the extra parameter in the convert method, which would stay backwards compatible, but would just mean some duplicate code within ParametersConverters. In retrospect, if backwards compatibility for this section of code is that important, this would've been the best option. I've got a couple more changes locally to the ParameterTable structure, to allow a user to specify defaults for a column, if that column isn't specified in the table, in another ParameterTable to make the whole thing easier to work with. I've just been playing around with the API a little until I was happy with it. Should be pushed sometime today (UK time). The angle that I'm coming at this from is, that I'm trying to get our testers to write the stories, which are then implemented by the developers, so trying to make life as easy as possible for the testers. IE, providing useful error messages (not stacktraces) when conversions, etc fail. Also, from some of my other patches/raised issues, allowing testers to create new stories without needing to code any java.
