OK, great. Want to take a stab at adding this capability to BeanAdapter.coerce()?
On Sep 7, 2010, at 11:36 AM, Chris Bartlett wrote: > Ahh, I think I have finally pieced it all together! Apologies for being a > bit slow ;) > That all sounds reasonable to me, especially given the other conventions > used by BeanAdapter that you stated in the original email. > > > On 7 September 2010 22:17, Greg Brown <[email protected]> wrote: > >>> Are these assumptions correct? >>> 1) BXML should allow enum values to be supplied in a case insensitive >> manner >> >> Correct. This is entirely aesthetic (and subjective), but in my opinion >> this: >> >> <Label styles="{horizontalAlignment:'center'}"/> >> >> tends to read a bit easier than this: >> >> <Label styles="{horizontalAlignment:'CENTER'}"/> >> >>> 3) Enum values are case sensitive, but finite and enumerable >>> 4) An enum can contain multiple values whose names might be equal after a >>> toUpperCase()/toLowerCase() conversion >>> public enum MyEnum { >>> value, >>> VALUE, >>> vALUe >>> } >> >> Correct. >> >>> 2) BXML should support all enums regardless of whether they are part of >> the >>> Pivot code base, and not impose any naming conventions for the enum or >> its >>> values >> >> This is the key issue. The approach I was thinking of would put this logic >> in BeanAdapter, which isn't used exclusively by BXMLSerializer. I think it >> is safe to assume that all enum values used in BXML will be >> case-insensitive. However, as you noted, all enums are not guaranteed to be >> case-insensitive, nor are they guaranteed to be all uppercase. It is >> possible that a developer may want to use BeanAdapter outside of >> BXMLSerializer to set enum values that don't adhere to this convention. But >> then again, outside of BXMLSerializer, it may not be strictly necessary to >> rely on string values - you could just use the enum itself. >> >> While the various checks you outlined will certainly work, they are >> overkill for our primary use case, since all Pivot enums use the >> uppercase/underscore naming convention. In fact, they are probably overkill >> for most use cases, since most Java developers seem to use this convention. >> So I guess I am beginning to lean towards simply performing the >> toUpperCase() call in BeanAdapter.coerce(), since this will cover the 90% >> case. >> >> This shouldn't preclude you from using BeanAdapter to address the 10% case, >> though, since you could still write your own conversion function (basically, >> what we are doing today). >> >> >>
