Brian, Thanks for your comments.
Your email further sparked my ideas. I will look into the spring converters, and maybe in the jbehave-spring artifact, we can put something together to have JBehave defer to Spring to convert it, where appropriately configured. I like the idea to create a new annotation you can put on parameters where you declare the conversion class you want to use. This way you can have single out special parameters that share the same object type as others, but still apply some special conversion. So with a bit of hacking around today, I have got it working (it lacks tests, however all the existing still pass) https://github.com/larrys/jbehave-core/commit/e4823c6a3b1bba8f1d5595d7b2604ab2c6cfcf3b While implementing this, I did run across a potential bug in the code that checks for the @Named annotation, if you have multiple annotations on the parameter, depending on ordering, it will overwrite it wil null (this should be super rare, except with this new annotation I added). I wrapped it in an if block to check if it is not null, then get the named annotation, otherwise the named annotation was already found, and to skip that element in the array of annotations. Besides lacking tests (due to trying to find a way with the existing tests how to test this change, and where), it does lack the ability to pass configuration to the converter, due to how this is implemented, and what annotations allow us. To me this is not a huge deal breaker, you will just have to wrap the real converter with your own class, that has the configuration. So if anyone wants to review my code, let me know. I'll work on adding in some tests, documentation and some examples of it over the coming days. -- Larry On Mon, Jan 31, 2011 at 7:22 PM, Brian Repko <[email protected] > wrote: > > Larry, > > Thanks for starting the discussion. There are so many libraries for type > conversion, many > with IoC containers - particularly those that read from XML - and web > application frameworks, > that I'm surprised that some of this has not been standardized. > > The Spring-Security example uses Spring's BeanWrapper as the implementation > of a Builder > pattern in order to leverage Spring's type conversion framework and its > defaults. With Spring 2 > and 2.5 the main framework was the JavaBean PropertyEditor framework. That > was replaced > in Spring 3 with a new custom framework which you can find documented at: > > > http://static.springsource.org/spring/docs/3.0.x/reference/validation.html#core-convert > > This is now used in SpringMVC and allows for annotated conversions as > needed. > > While I know that we would not include Spring as a core dependency for > JBehave, that > design (as well as potentially looking at how Guice/Pico or other web > frameworks deal > with this - typically via OGNL) would be a place to start with ideas. The > ability to apply > conversion at a parameter-level as well as a generic registry of converters > can get you > there - the other thought is to apply the filter-chain or delegating > pattern to the converter > framework. > > My 2c coming from a Spring background... > > Brian > > ----- Original message ----- > From: "Larry Shatzer, Jr." <[email protected]> > To: [email protected] > Date: Mon, 31 Jan 2011 16:07:27 -0700 > Subject: [jbehave-dev] A discussion on some Parameter Conversion ideas... > > 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 > > --- > Brian Repko > LearnThinkCode, Inc. <http://www.learnthinkcode.com> > email: [email protected] > phone: +1 612 229 6779 >
