1 Feb 2011 03:22
Re: A discussion on some Parameter Conversion ideas...
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." <larrys-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: dev-b1QraVsTlj/IJWOP8RzEEmD2FQJk+8+b@public.gmane.org
Date: Mon, 31 Jan 2011 16:07:27 -0700
Subject: [jbehave-dev] A discussion on some Parameter Conversion ideas...
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
phone: +1 612 229 6779
RSS Feed