Hi Roger, What do you think about the "toUpperCase()" issue? Would this be a problem for you? Any suggestions about how we might handle it differently? Greg
On Sep 6, 2010, at 11:26 PM, Roger Whitcomb wrote: > From what I understand, the problem is determining (by reflection) what the > appropriate enum class should be to call the "valueOf" method on. > > I'd like to have this myself! > > ~Roger Whitcomb > > Sent from my iPhone > > On Sep 6, 2010, at 6:13 PM, Chris Bartlett <[email protected]> wrote: > >> I'm not sure I fully understand what you are proposing. >> >> Is this to remove the need for methods such as >> BoxPane#setOrientation(String orientation) >> and just keep >> BoxPane#setOrientation(Orientation orientation) >> when processing BXML such as >> <BoxPane orientation="horizontal"/> ? >> >> If so, then how about first attempting a valueOf using the raw attribute >> value from the BXML? If that fails, then try with the uppercase ersion. >> That would allow case sensitive, mixed case values to be supplied in BXML. >> >> This could happen the other way around if preferred, and also could enforce >> a toUpperCase() conversion if the enum lived in a Pivot package. (If that >> is the Pivot convention) >> >> Chris >> >> >> On 7 September 2010 07:24, Greg Brown <[email protected]> wrote: >> >>> I was thinking about how we might add support for automatically converting >>> strings to enum values, and I came up with something that might work (though >>> I have not prototyped it). We might be able to use reflection to get the >>> valueOf() method on a particular enum type, and then invoke it with the >>> string value. We could potentially do this in BeanAdapter.coerce(), since >>> all BXML type coercion ultimately flows through this method. >>> >>> However, there's one minor issue with the concept. All of our enum >>> conversion overloads currently call toUpperCase() on the value. We do this >>> primarily so we can use lower case values in BXML (for readability). We'd >>> have to do the same thing in coerce() in order to eliminate the overloads. >>> In general, developers seem to adhere to the all caps/underscore convention >>> when naming enum values, but it isn't strictly enforced. We'd therefore be >>> imposing a slight limitation on the use of coerce(). >>> >>> I'm on the fence about it. BeanAdapter and BeanMonitor currently rely on >>> other naming conventions (getter and setter methods, getXXXListeners(), >>> etc.), so it's not that far-fetched. If the reflection approach works, is >>> the case conversion a limitation that we can live with? >>> >>> G >>> >>>
