I don't think that having castor look at the schema to discover the values in an enumeration is a particularly good idea. Leaving aside the performance issue, I think it could cause inconvenience or even harm down the road. Here are a few of reasons why:
1) One of the most useful aspects of typesafe enumerations is that, well, they are typesafe. They provide compile-time checking that the values being used are valid. If you switch to a system where the proper values aren't known until run time, you introduce dozens of new possible points of failure. I'm not suggesting that this is a tradeoff that should never be made, but I don't see that it is necessary for you. Why not, as Dean suggests, just keep the generated source up-to-date? Keep in mind that, while your schema may be rapidly changing today, it probably will settle down and stay the same for most of the life of your project.
2) Using the schema dynamically, as you suggest, results in only one place to look for information about the system. (I'll ignore for the moment that you should have _documentation_ that tells you and your co-developers what values are legal where.) That single reference point is now a potentially brittle point of failure. What if a change to the schema introduces a run-time error in some infrequently accessed class? You'll have a system that starts crashing, say, once a month, with no clear idea of when the error was introduced.
3) If the schema is used dynamically for validating enumerated types, why not other restricted types? Or extensions? If you rely on schema changes to update enumerations (without any user intervention), why not changes in type? Or in the names of elements? Source generator is not a revision control system and I don't think it would be worthwhile to build one in.
Those are my doomsday scenarios for why I wouldn't add this feature if I were in charge of castor. But even if those who are in charge agree with me, remember: the beauty of open source is that you can take castor and add whatever features you want to it.
Rhett
=====================================================
| Rhett Sutphin
| Research Assistant (Software)
| Coordinated Laboratory for Computational Genomics
| and the Center for Macular Degeneration
| University of Iowa - Iowa City, IA 52242 - USA
| 4111 MEBRF - email: [EMAIL PROTECTED]
=====================================================
On Friday, December 27, 2002, at 09:07 AM, Jonathan Asbell wrote:
I understand. Butin my particular situation values may need changing more frequenty than releases. Yes, I could look at the schema. But the one schema could be out of synch with the generated classes. Now you have 2 places to look to see if what you have is correct. Instead, Castor could give the option of re-using the schema in a way in which it could also be used as part of a config file. That is, you could change the "castor.properties" to include an option that will not generate hard coded values to test, but rather reload an instance of the schema and use its listed enumerated values.----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
----- Original Message -----
From: Dean Hiller
To: [EMAIL PROTECTED]
Sent: Friday, December 27, 2002 8:49 AM
Subject: Re: [castor-dev] schema creation/class generation commentary
Here is the way my group here deals with this. Other users can give their methods also.
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?
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
