Re: [castor-dev] schema creation/class generation commentary

[Dean Hiller]

I am not exactly sure what you are getting at.  In my environment, I actually check the schemas in and have an ant task to generate the code so the schemas and code are always in synch.  Maybe the castor developers will understand your situation better and give advice.  I guess developers don't ask me those kind of questions.  They just look at the code, because schema and code is always in synch.
Dean

Jonathan Asbell wrote:

I understand. Butin my particular situation values may need changing more frequenty than releases.  Yes the basic code generated is the same, but if a collegue at work asks me "How many types of users do we have that are on the list", I have to look in the code to find out.  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. 

----- 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?