Hi Larry, the parameter conversion design of JBehave allows for many different implementations, even for the same Java type. So there is no problem in having a bespoke BooleanConverter that also does some textual pre-parsing conversion. Like-wise for the EnumConverter. In any case, it should handled (i.e. configured) as is appropriate by each converter. I would avoid having (global) property files about, as it makes the configuration less trasparent.
Similarly, we can have another date parsing converter based on Natty. I would perhaps make the non-standard converter not part of the default set and they would need to added explicitly by the user, but we also decide later on that they could be part of the default. I would suggest creating a new Jira issue for each new converter and/or enhancement to an existing converter so we can track them separately. And of course your contributions on these converters would be most welcomed. Cheers On 01/02/2011 00:07, Larry Shatzer, Jr. wrote: > Along with my change that was accepted for Enum parameter converters, > I have a few other changes I want to discuss. > > The first of these is a way for parameter converters to go through a > remapping conversion before being converted. My ultimate goal is to > make the stories as readable to non developers as possible, and also > hiding potential implementation details from the stories. > > I currently have a "BooleanConverter" that just calls in effect > "BooleanUtils.toBoolean(value)" on it. In some stories I want "pass" > to mean "true" and "fail" mean "false", but in other stories I want > "true" and "false" to be left alone. So I would like to parse the > value passed to the method and if it is something that should be > remapped to something else, do that, then execute the regular > conversion. Another place I use this is with my EnumConverter to make > the enum in the story more readable than the actual enum value. > Example, the story should use "not found" instead of NOT_FOUND (if the > enum has that value). > > Currently I'm using a properties file to define the as follows: > > booleanformat.pass=true > booleanformat.fail=false > > Then in my BooleanConverter I check for the prefix plus the value > passed in against the properties file, if it exists, swap the value > for the value in the properties file, then continue on. I also use > this as a way for the NumberConverter to allow nulls for more > developer stories that do have the need to have null objects for > better test coverage. I feel the properties file method is a little > bit of a hack, and wanted to know if someone else found this type of > behavior desirable and work on a more robust solution, and contribute > it back to the core, this way I don't have to necessarily provide my > own set of core converters that do this mapping before doing the > actual conversion. > > Another change is a more natural language date parser. I'm using natty > (http://natty.joestelmach.com/). I find this makes the stories > more tolerant of the somewhat rigid date format(s) you have to specify > for all dates. This also allows more natural expressions as "60 days > ago". However, I do see the need to have a rigid date parser that > currently exists, so looking at advise how to support both in the > core. I also know that localization is a priority of some, and natty > is not locale aware (yet). > > Also, as mentioned above, a BooleanConverter/BooleanListConverter I > think would be another natural addition, and again, I can't find an > easy way to make it locale independent, without having non-english > define their true/false strings and have those passed in to BooleanUtils. > > With any of these, I can provide a branch on my github fork for more > discussion and ideas. I figured I'd want to write the list to get some > feedback and collaborate a little bit more proposing patches. > > Thanks for the great tool, > > -- Larry > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
