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 > >
