Hey Ryan and Kohsuke, I have a possible enhancement that I'd like to
discuss. There are lots of bug reports and stuff out here, but this one is
more of a "wouldn't this be a cool feature" type thing.
First, for reference, please take a look at the Schema for ContentCard,
located at:
http://singularity-sys.sourceforge.net/schemas/contentCard.xsd
Notice that the element called "productType" has a moderate sized
enumeration of possible values. These values are all just Strings.
In code, what this ends up meaning is that somebody has to make an API call
that looks like this:
cCard.setProductType("Software - Plug-in");
That's not terrible, but consider this. Somehow, your code has to know in
advance what possible Strings it can put there. How is it to know? What if
the Schema changes? Even recompiling the Schema with JAXB doesn't give the
code any way to know what it can pass in. The only way to know, currently,
is for the developer to actually read the XSD file with his own eyes,
remember the choices, and put a valid one in there. That's going to be
pretty bug-prone, I would guess. Typos are common, especially on Strings
like that that you have no way to validate until runtime.
JAXB currently can validate such a setting. In other words, it is able to
look at the String and say "yes, that value is allowed." It would be nice
if JAXB could provide the programmer with valid choices to use, up front.
Here's a real-world example. Let's say I want to create a GUI that allows
the editing of some objects, like for example Cars. The data from my
application will be stored in a big XML database, and the XML will be
produced by marshalling JAXB-created objects. This GUI lets you change all
the interesting attributes of the Cars, such as Make, Model, Year, Mileage,
and of course, Color.
In defining the schema for a Car, it would be fairly likely that several of
the elements would have restrictions. Let's consider Color. Maybe the
factory that is using this application only supports Red, Blue, Black, and
White cars. The application should, therefore, restrict entry of Color
choices to one of those.
It stands to reason (and it's good UI design) that such a visual entry field
would use either a JList or a JComboBox. When designing such an
application, then, using JAXB as it is today, the code might look something
like this:
String[] options = {"Red","Blue","Black","White"};
JComboBox combo = new JComboBox( options );
If the Schema changes, somebody will need to go back into the code and
change the options array...and in other places too, if it's there.
What would be MUCH NICER would be if you could instead do this, with the
help of JAXB's object:
List options = carObj.getColorOptions();
JComboBox combo = new JComboBox( options.toArray() );
This would allow the code to change with changes in the schema, and would
ensure that programmer typos were not capable of introducing bugs.
What do you think? Would this be something doable? I think it would be a
highly-used feature of JAXB down the road.
Thanks,
-Brandon Franklin
Thought River South
/**
* There are only 10 types of people, those who understand binary and those
who don't!
*/
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20030408"
AAAAB3NzaC1yc2EAAAABJQAAAIB1Oya5y2gACM7mQX/OWRlaLLstK27x8rTG8+Cu
kXNPCt163dNGYP1OcBhNlMtexN6eVat/L0D1/yMgc5ezYGz5Znqu8tvNUbsDXRdb
MlV7tvohb1wk8qIFx33bAJb3VjGt+4qRgmOkxMqCJvrSwBjiQ06pFsLDFW2BF8mF
8K0/qQ==
---- END SSH2 PUBLIC KEY ----