>
> Maybe since I don't use Java at all in my projects I don't understand all
> of the problem. I use custom EO's for almost all of my tables. I have them
> in Objective C and I make a different file in my project usually called
> ClassExtras into which I put all the methods I like on a Class. The
> ClassExtras is a category (I believe this is the correct term) off of
> Class. This way when my model can and does change I just regenerate the
> code and overwrite. I don't have to deal with the merge tool or any
> problems since I dont' customize the code in the file the model generates.
Wandering off topic:
I wish that EOModeler had a little more formal way of generating
classes then just using the merge tool. One tool I used to use
generated two classes for every class. It worked really well.
For instance, lets say you have an entity called: Person.
Person has attributes: first name, middle name, last name, suffix,
key, timestamp.
The tool I used to use would, the first time, generate two class files:
XPerson would always be generated and it would depend on the definition
of Person. It was interface mostly, and/or default implementations of
Person accessors.
Person was a sub-class of XPerson, and was only generated if it was
missing. It was originally empty of everything but definitions.
So lets say you add a new derived attribute called "fullName" to Person the
entity. So you add fullName to Person the class. EZ-Breezy.
Now lets say you add phone_number to Person the entity.
No problem, you regenerate, and you get a new XPerson class, but Person
gets left alone (since it already existed). However, since Person inherited
from XPerson, it now has the new attribute.
Now lets say that you want to override the way that one of the default
implementation works (like you modify the setAttribute methods to set
the timestamp attribute if the values are different.)
So you change them in the Person class, which automatically overrides the
XPerson class.
This tool was really cool, and it was a clever way to take advantage of OOP
to solve the code-generation problem.
What I'd like to see in EOModeler:
1. Implement the double-class generation method described above.
2. In the X_ class files generated, store an MD5 hash code for the file.
If the MD5 hash-codes match when regenerating, optionally overwrite
them without prompting all the X_files. (Its annoying when EOModeler
asks you if you want to merge when the only change is the timestamp.)
Pierce
----------------------------------------------------------------
Pierce T. Wetter III, Director, Twin Forces, Inc.
e-mail: [EMAIL PROTECTED] Phone:520-779-4227
<http://www.twinforces.com/>
U.S. Mail: 1300 South Milton Rd, Suite 206, Flagstaff, AZ 86001
