In our first release, we generate classes so one enum might be cat, dog, mouse. In the next release, we will regenerate the code and have cat, dog, mouse, giraffe, lion as our enum. We don't see this as a big deal, because all previous code written to use these castor classes will continue to work. The only time it would break is if something was deprecated. Just like Sun, we plan on saying stuff is deprecated, but will probably never really deprecate it, at least not for 4-5 releases down the road. I am not sure what you mean by externalize enumerated values. They seem externalized to me, and the only problems you run into is if an enumeration is deprecated and a client of castor objects is using it. Every Java Class is really just an interface if you think about it. Say you write a class Temp. You could completely rewrite the Temp class and as long as you have all the same methods plus some added ones, none of the clients of Temp will break.
Dean
Jonathan Asbell wrote:
It is true that XML Schema is a much better way to restrict xml content. If you know what you want to do you can even restrict the possible values of fields or attributes. This is all good until you want to represent your own lists of possible values for use with castor (enumerated values). The reason is that as you, the developer, will want to expand the list of possible values over time, and unfortuneately this implies "re-generating" the castor classes based on the new schema with the additional values. You dont have to provide these values at all, but that means that castor also wont check to restrict the values. So, you are caught between either re-generating classes when values change, or not have the control in restricting the values at all. My issue is the following: Do you Castor users/developers think it would be better to somehow "externalize" possible enumerated values rather than represent them as class values? The downside is, of course, that you would have to manage yet another file(like an xml file). Any comments?
