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