Extending EnumValueAdapter

[alesj]

An 'issue' I stumbled upon today, perhaps being worth a new feature.
It would be cool if we could make EnumValueAdapter be case unaware for String keys.
Probably the best way to impl this is to extend EVA, where we before provide proper hooks.
And the user than sets this as a ValueAdapter for his enum.

What do you think?

ps: I've already got a working impl locally :-)

[adrian.brock]

"alesj" wrote:
An 'issue' I stumbled upon today, perhaps being worth a new feature.
It would be cool if we could make EnumValueAdapter be case unaware for String keys.
Probably the best way to impl this is to extend EVA, where we before provide proper hooks.
And the user than sets this as a ValueAdapter for his enum.

What do you think?

ps: I've already got a working impl locally :-)

Just do something like

@JBossXmlEnum(ignoreCase=true)
public enum MyEnum {}

Then when constructing the map of valid values and doing the lookups
convert the xml values to lower case if the "ignoreCase" is true.

The user shouldn't have to write code for this feature when it can
be made declaritive.

[alesj]

The user shouldn't have to write code for this feature when it can
be made declaritive.

Sure.
But I didn't want to bloat EVA, with all the string handling code.
Since this only applies if the key is pure string.

[adrian.brock]

"alesj" wrote:

The user shouldn't have to write code for this feature when it can
be made declaritive.

Sure.
But I didn't want to bloat EVA, with all the string handling code.
Since this only applies if the key is pure string.

Everything is a String in xml :-)

[alesj]

Everything is a String in xml :-)

Yeah, but your key might not be.

 Object key = enumValue;
 try
 {
 key = enumType.convertValue(enumValue, false);
 }
 catch (Throwable t)
 {
 throw new RuntimeException("Error for enum " + enumInfo.getName() + " unable to convert " + enumValue + " to " + enumType.getName());
 }
 Object value = constant.getValue();
 valid.put(key, value);

[adrian.brock]

It's not about the underlying value its about recognising which xml string value
maps to which enum value.

You still haven't done what I told you to do.
So its not surpising you don't get it :-)

e.g.

@JBossXmlEnum(ignoreCase=true)
public enum ControllerMode
{
 @XmlEnumValue("Automatic")
 AUTOMATIC("Automatic"),
...
}

would mean "automatic" in the xml gets converted to the "AUTOMATIC" enum value.

@XmlEnum(type=Integer.class)
@JBossXmlEnum(ignoreCase=true)
public enum Numbers
{
 @XmlEnumValue("ONE")
 ONE(1),
}

Would mean that "one" in the xml gets translated to the ONE enum value.

[alesj]

Would mean that "one" in the xml gets translated to the ONE enum value.

And where does that '1' get used?
OK, no need to answer, I'll use 'Suck it and see' principle. ;-)

[adrian.brock]

"alesj" wrote:

Would mean that "one" in the xml gets translated to the ONE enum value.

And where does that '1' get used?
OK, no need to answer, I'll use 'Suck it and see' principle. ;-)

It doesn't. The "1" gets used if you do this:

@XmlEnum(Integer.class)
public enum Numbers
{
 ONE(1)
}

i.e. a "1" in the xml maps to the ONE enum value.

[alesj]

It doesn't. The "1" gets used if you do this:

@XmlEnum(Integer.class)
public enum Numbers
{
 ONE(1)
}

i.e. a "1" in the xml maps to the ONE enum value.

So in this case it would be illegal to use @JBossXmlEnum(ignoreCase=true) or just ignored?
Who makes sure "1" is passed into EVA::cast as an Integer?

[adrian.brock]

"alesj" wrote:

It doesn't. The "1" gets used if you do this:

@XmlEnum(Integer.class)
public enum Numbers
{
 ONE(1)
}

i.e. a "1" in the xml maps to the ONE enum value.

So in this case it would be illegal to use @JBossXmlEnum(ignoreCase=true) or just ignored?

Yes. Obviously, you can't ignore case on an integer. ;-)

Who makes sure "1" is passed into EVA::cast as an Integer?

Its the xsd:type (or technically its parent type) of the attribute/element.

From JBossXBNoSchemaBuilder

 // Determine the enum type
 Class<?> xmlEnumValue = String.class;
 XmlEnum xmlEnum = typeInfo.getUnderlyingAnnotation(XmlEnum.class);
 if (xmlEnum != null)
 xmlEnumValue = xmlEnum.value();
 TypeInfo enumType = typeInfo.getTypeInfoFactory().getTypeInfo(xmlEnumValue);

 // Resolve the enum type as the parent (must be simple)
 TypeBinding parent = getSimpleType(enumType);

 // Create the enum type
 QName qName = null;
 TypeBinding typeBinding = null;
 if (root)
 {
 qName = generateXmlName(typeInfo, XmlNsForm.QUALIFIED, overrideNamespace, overrideName);
 typeBinding = new TypeBinding(qName, parent);
 }
 else
 {
 typeBinding = new TypeBinding(null, parent);
 }

Please, either read the spec, read the code, read the tests or "suck it and see".

Don't keep expecting me to explain the finest points of every implementation detail
ad infinitum in the forums (unless you want to post in the user forums
where I can ignore you :-).

[alesj]

Please, either read the spec, read the code, read the tests or "suck it and see".

Don't keep expecting me to explain the finest points of every implementation detail
ad infinitum in the forums (unless you want to post in the user forums
where I can ignore you :-).

Hey, you started suggesting how to do it.
Hence I need/want/like to know the details of what you meant. :-)

Also, afaik I had a working impl + already suggested you throw in a 'suck it and see' principle. ;-)

[adrian.brock]

"alesj" wrote:

Please, either read the spec, read the code, read the tests or "suck it and see".

Don't keep expecting me to explain the finest points of every implementation detail
ad infinitum in the forums (unless you want to post in the user forums
where I can ignore you :-).

Hey, you started suggesting how to do it.
Hence I need/want/like to know the details of what you meant. :-)

Also, afaik I had a working impl + already suggested you throw in a 'suck it and see' principle. ;-)

It was you that started talking about people having to implement hooks
for a simple feature like ignore case.
I naturally assumed you didn't understand how it works or the idea
that is supposed to be declaritive (annotation based).

If you don't like the EnumValueAdapter (which is an implementation detail)
then you can replace it with your own adapter already (possibly extending the original).
There's a seperate annotation for that.
(There's no need to write hooks for hooks. Not very "cool" at all. :-)

This was confirmed to me when you kept asking questions
instead of trying to understand how it really worked.

Claiming to have a working implementation of a new feature when you're not showing
and understanding of how the old stuff works is obviously a "red flag".

Problems:
1) Why should we let you modify something you don't understand?
2) Why should we continue to answer questions when you haven't tried to understand
it for yourself?

"Because it SEEMS to work for me" isn't an answer. :-)

[alesj]

I naturally assumed you didn't understand how it works or the idea
that is supposed to be declaritive (annotation based).

Claiming not understanding something as simple as a single class with the size of 20+ lines is low. ;-)

What is declarative is debatable.
Adding @JBossXxmlEnum(ignore=true) to my (although it was never written down, this is what I had in mind) @ValueAdapter(CaseIgnoreEnumAdapter.class) is not that far apart.

This was confirmed to me when you kept asking questions
instead of trying to understand how it really worked.

Claiming to have a working implementation of a new feature when you're not showing and understanding of how the old stuff works is obviously a "red flag".

Problems:
1) Why should we let you modify something you don't understand?
2) Why should we continue to answer questions when you haven't tried to understand it for yourself?

Claiming constant 'not understanding' won't make your semi-detailed answers go away. :-)

Let's look at the history:

Then when constructing the map of valid values and doing the lookups
convert the xml values to lower case if the "ignoreCase" is true.

Not all values can be converted to lower case:

Yes. Obviously, you can't ignore case on an integer. ;-)

Next one:

Everything is a String in xml :-)

And we got this from additional drill-down:

"alesj" wrote:

Who makes sure "1" is passed into EVA::cast as an Integer?

Its the xsd:type (or technically its parent type) of the attribute/element.

This one also isn't as obvious as it could be:

@XmlEnum(type=Integer.class)
@JBossXmlEnum(ignoreCase=true)
public enum Numbers
{
 @XmlEnumValue("ONE")
 ONE(1),
}

Defining Integer type + explicit String enum value.
OK, I'll can pass this one to 's&s' principle.
Though my first idea tells me that Integer.parse in IntegerEditor will complain since it will get passed "ONE".
Or it could be that perhaps I again don't understand. ;-)

[adrian.brock]

"alesj" wrote:

Claiming constant 'not understanding' won't make your semi-detailed answers go away. :-)

They're semi-detailed because I'm saying your doing it wrong,
I want you try to understand how it really works (code - all of it) and the philisophy
(the spec), not expect to be spoon fed.

I could spend all day telling you how it works and linking to code snippets
(or having stupid arguments like this one) but then I'll never get any work done.

And I might as well do the implementation myself since I can do it twice as fast
if I don't have to go into painful details on the forums.

Let's look at the history:

Then when constructing the map of valid values and doing the lookups
convert the xml values to lower case if the "ignoreCase" is true.

Not all values can be converted to lower case:

Yes. Obviously, you can't ignore case on an integer. ;-)

Next one:

Everything is a String in xml :-)

And we got this from additional drill-down:

"alesj" wrote:

Who makes sure "1" is passed into EVA::cast as an Integer?

Its the xsd:type (or technically its parent type) of the attribute/element.

This one also isn't as obvious as it could be:

@XmlEnum(type=Integer.class)
@JBossXmlEnum(ignoreCase=true)
public enum Numbers
{
 @XmlEnumValue("ONE")
 ONE(1),
}

Defining Integer type + explicit String enum value.
OK, I'll can pass this one to 's&s' principle.
Though my first idea tells me that Integer.parse in IntegerEditor will complain since it will get passed "ONE".
Or it could be that perhaps I again don't understand. ;-)

Ok, the example quoted shouldn't have had the @XmlEnum(Integer.class)
(cut and paste error). i.e. you want JBossXB to pass you the string
because you have the XmlEnumValue("ONE") as a string not the integer.

The other example that did use numbers was correct.

But those came well after my original post and you started asking about
how the value conversion works.

[adrian.brock]

Anyway I've had enough of this thread.

We can continue to argue about arguing as much as you want,
but it isn't going to get us anywhere. :-)

The original point was:

t would be cool if we could make EnumValueAdapter be case unaware for String keys.
Probably the best way to impl this is to extend EVA, where we before provide proper hooks.

* Adding a hook to hook is not "cool" it is pointless, overly complicated
and bound to lead to confusion/maintenance problems.

* There is already is a mechanism to convert the enum values to other types
or values.

* What there isn't is a declartive (annotation) to ignore case when the xml
enum type extends xsd:string.