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