# WebObjects/EOF/Using EOF/EOGenerator
### Overview

If you've ever used EOModeler's Java source code generator, you know how much of a pain it can be when you make changes to your model objects and have to merge changes in later. One solution for this is to use EOGenerator, an application developed by Rubicode Software, which uses the Generation Gap pattern to create your Java files from your EOModels. EOGenerator produces TWO java files for each Entity rather than one. Take the example of a Person entity. The first java file is _Person.java, which contains all of the autogenerated methods. The second java file is Person.java, and Person extends _Person. The second file is where you place all of your customizations. Any time your model changes, only your _Xxx.java files are updated, and your customizations are left untouched. Additionally, EOGenerator allows for the creation of extensive custom templates for your files, which provides the ability to place convenience methods in your _Xxx.java files.

### Advantages

There are several advantages to using EOGenerator over EOModeler's default Java file generation and merging with FileMerge.
* EOGenerator uses the Generation Gap pattern, which provides a much cleaner separation of autogenerated vs customized code with no need to deal with merging at all. There are border cases with FileMerge that can cause you to deal with annoying conflicts.
* EOGenerator uses the MiscMerge language for its templates. This allows you to extend the core templates with extensive customizations (see the EOGenerator Mods section below), better supporting your own custom development process and workflow.
* As David LaBer put it, "all the cool kids use it - and we all know looking cool is the *most* important criteria".

### How To Use It

Kieran Kelleher has writtten an Introduction to EOGenerator on his blog.
It's actually very simple to use. The quick start is:
* Download and untar EOGenerator from the Rubicode site
* Run the following command:
Voila. EOGenerator will spit out your Java files for you. Let's break down the commands you can pass in:
* -define-EOGenericRecord <class>, allows you to specify the _Person class's superclass. For instance, if you use Project Wonder, you would specify -define-EOGenericRecord er.extensions.ERXGenericRecord
* -destination <path>, the folder that _Person.java-style java files will be produced in (the non-editable files)
* -java, produce java files
* -javaTemplate <filename>, the name of the Java template to use inside of the template dir (_Person)
* -model <path>, Passes in the path of a .eomodeld you would like to generate Java files for. You can actually include multiple -model commands on the commandline
* -packagedirs, produce package directory for any package statements defined in your Java files (not necessary if you don't specify package names on your entities. By the way, you should specify packages on your entities :) )
* -refmodel <path>, Passes in the path of an .eomodeld that is required for generating Java files, but that won't actually have Java files generated for it. For instance, you should -refmodel any prototypes, or any models in other frameworks that you depend on
* -subclassDestination <path>, the folder that Person.java-style java files will be produced in (the editable files)
* -subclassJavaTemplate <filename>, the name of the Java subclass template to use inside of the template dir (Person)
* -templatedir <path>, the path to the folder that contains EOGenerator templates
* -verbose, turn on verbose output

### Custom EOGenerator Mods
#### Zak Burke

Allow setting nulls on a to-one relationship (and turn it into a remove). Note, this is also included in Jonathan Rentzsch's templates.

#### Chuck Hill

Return the list of changes between the current EO and the last committed version of the EO:

#### Jonathan Rentzsch

Jonathan Rentzsch has provided his base EOGenerator templates, which are a must-have:
http://rentzsch.com/share/eogenerator52templates.zip

#### Markus Ruggiero

Constants for all attributes and relationships. This allows compile time error checking in situations like addObjecttoBothSidesOfRelationshipWithKey(myObject, Person.TO_MANY_Children)
We also make heavy use of the user info dictionary on entity and attribute level. Allows to generate customized methods and what not. One example is booleans that are stored in the DB as strings with values "true" and "false".

#### Mike Schrag

Add a constant that represents the name of the entity so that you can refer to Person.ENTITY_NAME in fetches rather than the String (allows refactoring support in Eclipse):
Add a static factory method to your EO's ( Person createPerson(...) ) that shows you what required attributes and relationships are configured for you entity (attempts to provide a replacement "constructor" since EO constructors are empty):
Here's a little bitty fancier (read: nastier) version that also handles superclass mandatory attributes and fields (one level). It skips any attribute that is referenced in the restricting qualifier of your subclass (since you are probably going to set that in your awakeFromInsertion):
Add a bunch of convience fetch methods (fetchAllPersons, fetchRequiredPerson, and other variants). It's not smart about pluralization, so it's just going to put an "s" on the end of the entity name:
Add methods for getting local instances of EO's. The static one is handy if you have a reference to an EO that might be null (it does a null check first):
If you've ever wanted to be able to qualify a toMany relationship on your EO's, but sometimes you want to fetch them w/ a fetch spec, and sometimes you want to filter in-memory, you can use the following:

#### John Huss

I wanted to share a wonderful bit of knowledge I learned today. If you're using Java 1.5 you can add @SuppressWarnings("all") to the template for your _EO base classes and eliminate annoying compiler messages (usually uneeded import statements).

#### Guido Neitzer

Create awakeFromInsertion and awakeFromFetch in your EOGenerator template as a method stub that only calls super and has a comment for "initialize your object here ...". You only have to put in the code at that place and can't possibly forget to call super. Here is an example:
This is from my JavaSubclassSourceTemplate.eotemplate