Skip to Content

Changes for page EOF-Using EOF-EOGenerator

Last modified by Pascal Robert on 2012/01/21 22:03
From version 32.1
edited by Pascal Robert
on 2012/01/21 22:03
Change comment: Migrated to Confluence 5.3
To version 30.1
edited by Pascal Robert
on 2012/01/21 22:03
Change comment: There is no comment for this version

Summary

Details

Page properties
Parent
... ... @@ -1,1 +1,0 @@
1 -Deprecated
Tags
... ... @@ -1,1 +1,0 @@
1 -wikireview
Content
... ... @@ -2,19 +2,17 @@
2 2  This is deprecated information!
3 3  {{/warning}}
4 4  
5 -|=(((
6 -Contents
7 -)))
8 -|(((
9 -{{toc minLevel="2" style="disc"/}}
10 -)))
5 +|= Contents
6 +| {{toc style="disc" minLevel="2"}}{{/toc}}
11 11  
12 12  == Overview ==
13 13  
14 -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>>url:http://www.rubicode.com/Software/EOGenerator/||shape="rect"]], 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.
10 +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>>http://www.rubicode.com/Software/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.
15 15  
16 16  {{warning}}
17 -EOGenerator doesn't work on Mac OS X 10.5. You have to use [[JavaEOGenerator>>url:http://developer.apple.com/samplecode/JavaEOGenerator/||shape="rect"]] or [[Velocity EOGenerator>>doc:WOL.Velocity EOGenerator (Veogen)]].
13 +
14 +EOGenerator doesn't work on Mac OS X 10.5. You have to use [JavaEOGenerator|http://developer.apple.com/samplecode/JavaEOGenerator/] or [Velocity EOGenerator|WOL:Velocity EOGenerator (Veogen)].
15 +
18 18  {{/warning}}
19 19  
20 20  == Advantages ==
... ... @@ -21,43 +21,45 @@
21 21  
22 22  There are several advantages to using EOGenerator over EOModeler's default Java file generation and merging with FileMerge.
23 23  
24 -* 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.
25 -* 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.
22 +* 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.
23 +* 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.
26 26  * As David LaBer put it, "all the cool kids use it - and we all know looking cool is the **most** important criteria".
27 27  
28 28  == How To Use It ==
29 29  
30 -Kieran Kelleher has writtten an [[Introduction to EOGenerator>>url:http://homepage.mac.com/kelleherk/iblog/C1837526061/E1908382110/index.html||shape="rect"]] on his blog.
28 +Kieran Kelleher has writtten an [[Introduction to EOGenerator>>http://homepage.mac.com/kelleherk/iblog/C1837526061/E1908382110/index.html]] on his blog.
31 31  
32 -It's actually very simple to use. The quick start is:
30 +It's actually very simple to use. The quick start is:
33 33  
34 34  * Download and untar EOGenerator from the Rubicode site
35 35  * Run the following command:
36 36  
37 37  {{panel}}
38 -eogenerator -model /path/to/model/YourModel.eomodeld -destination /path/to/source/folder
39 - -subclassDestination /path/to/source/folder -templatedir /path/to/EOGenerator/templates -java -packagedirs
36 +
37 +eogenerator \-model /path/to/model/YourModel.eomodeld \-destination /path/to/source/folder
38 +\-subclassDestination /path/to/source/folder \-templatedir /path/to/EOGenerator/templates \-java \-packagedirs
39 +
40 40  {{/panel}}
41 41  
42 -Voila. EOGenerator will spit out your Java files for you. Let's break down the commands you can pass in:
42 +Voila. EOGenerator will spit out your Java files for you. Let's break down the commands you can pass in:
43 43  
44 -* -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
45 -* -destination <path>, the folder that _Person.java-style java files will be produced in (the non-editable files)
46 -* -java, produce java files
47 -* -javaTemplate <filename>, the name of the Java template to use inside of the template dir (_Person)
48 -* -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
49 -* -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 )
50 -* -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
51 -* -subclassDestination <path>, the folder that Person.java-style java files will be produced in (the editable files)
52 -* -subclassJavaTemplate <filename>, the name of the Java subclass template to use inside of the template dir (Person)
53 -* -templatedir <path>, the path to the folder that contains EOGenerator templates
54 -* -verbose, turn on verbose output
44 +* 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
45 +* destination <path>, the folder that Person.java-style java files will be produced in (the non-editable files)
46 +* java, produce java files
47 +* javaTemplate <filename>, the name of the Java template to use inside of the template dir (//Person)//
48 +* 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
49 +* 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 :-) )
50 +* 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
51 +* subclassDestination <path>, the folder that Person.java-style java files will be produced in (the editable files)
52 +* subclassJavaTemplate <filename>, the name of the Java subclass template to use inside of the template dir (Person)
53 +* templatedir <path>, the path to the folder that contains EOGenerator templates
54 +* verbose, turn on verbose output
55 55  
56 56  == Custom EOGenerator Mods ==
57 57  
58 58  === Zak Burke ===
59 59  
60 -Allow setting nulls on a to-one relationship (and turn it into a remove). Note, this is also included in Jonathan Rentzsch's templates.
60 +Allow setting nulls on a to-one relationship (and turn it into a remove). Note, this is also included in Jonathan Rentzsch's templates.
61 61  
62 62  {{code}}
63 63  
... ... @@ -94,12 +94,12 @@
94 94  
95 95  Jonathan Rentzsch has provided his base EOGenerator templates, which are a must-have:
96 96  
97 -[[http:~~/~~/rentzsch.com/share/eogenerator52templates.zip>>url:http://rentzsch.com/share/eogenerator52templates.zip||shape="rect"]]
97 +[[http://rentzsch.com/share/eogenerator52templates.zip]]
98 98  
99 99  === Markus Ruggiero ===
100 100  
101 101  Constants for all attributes and relationships. This allows compile time error checking in situations like
102 - addObjecttoBothSidesOfRelationshipWithKey(myObject, Person.TO_MANY_Children)
102 +addObjecttoBothSidesOfRelationshipWithKey(myObject, Person.TO//MANY//Children)
103 103  
104 104  {{code}}
105 105  
... ... @@ -143,7 +143,7 @@
143 143  
144 144  === Mike Schrag ===
145 145  
146 -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):
146 +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)~://
147 147  
148 148  {{code}}
149 149  
... ... @@ -164,7 +164,7 @@
164 164  
165 165  {{/code}}
166 166  
167 -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):
167 +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):
168 168  
169 169  {{code}}
170 170  
... ... @@ -179,21 +179,26 @@
179 179  
180 180  {{/code}}
181 181  
182 -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:
182 +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:
183 183  
184 184  {{code}}
185 +
185 185  public static NSArray fetchAll<$classNameWithoutPackage$>s(EOEditingContext _editingContext) {
186 186   return <$GEN_PREFIX$><$classNameWithoutPackage$>.fetchAll<$classNameWithoutPackage$>s(_editingContext, null);
187 187   }
188 -{{/code}}
189 189  
190 +{{/code}}
191 +
190 190  {{code}}
193 +
191 191  public static NSArray fetchAll<$classNameWithoutPackage$>s(EOEditingContext _editingContext, NSArray _sortOrderings) {
192 192   return <$GEN_PREFIX$><$classNameWithoutPackage$>.fetch<$classNameWithoutPackage$>s(_editingContext, null, _sortOrderings);
193 193   }
194 -{{/code}}
195 195  
198 +{{/code}}
199 +
196 196  {{code}}
201 +
197 197  public static NSArray fetch<$classNameWithoutPackage$>s(EOEditingContext _editingContext, EOQualifier _qualifier, NSArray _sortOrderings) {
198 198   EOFetchSpecification fetchSpec = new EOFetchSpecification(<$GEN_PREFIX$><$classNameWithoutPackage$>.ENTITY_NAME, _qualifier, _sortOrderings);
199 199   fetchSpec.setIsDeep(true);
... ... @@ -200,15 +200,19 @@
200 200   NSArray eoObjects = _editingContext.objectsWithFetchSpecification(fetchSpec);
201 201   return eoObjects;
202 202   }
203 -{{/code}}
204 204  
209 +{{/code}}
210 +
205 205  {{code}}
212 +
206 206  public static <$classNameWithoutPackage$> fetch<$classNameWithoutPackage$>(EOEditingContext _editingContext, String _keyName, Object _value) {
207 207   return <$GEN_PREFIX$><$classNameWithoutPackage$>.fetch<$classNameWithoutPackage$>(_editingContext, new EOKeyValueQualifier(_keyName, EOQualifier.QualifierOperatorEqual, _value));
208 208   }
209 -{{/code}}
210 210  
217 +{{/code}}
218 +
211 211  {{code}}
220 +
212 212  public static <$classNameWithoutPackage$> fetch<$classNameWithoutPackage$>(EOEditingContext _editingContext, EOQualifier _qualifier) {
213 213   NSArray eoObjects = <$GEN_PREFIX$><$classNameWithoutPackage$>.fetch<$classNameWithoutPackage$>s(_editingContext, _qualifier, null);
214 214   <$classNameWithoutPackage$> eoObject;
... ... @@ -224,14 +224,17 @@
224 224   }
225 225   return eoObject;
226 226   }
227 -{{/code}}
228 228  
237 +{{/code}}
238 +
229 229  {{code}}
240 +
230 230  public static <$classNameWithoutPackage$> fetchRequired<$classNameWithoutPackage$>(EOEditingContext _editingContext, String _keyName, Object _value) {
231 231   return <$GEN_PREFIX$><$classNameWithoutPackage$>.fetchRequired<$classNameWithoutPackage$>(_editingContext, new EOKeyValueQualifier(_keyName, EOQualifier.QualifierOperatorEqual, _value));
232 232   }
233 -{{/code}}
234 234  
245 +{{/code}}
246 +
235 235  {{code}}
236 236  
237 237  public static <$classNameWithoutPackage$> fetchRequired<$classNameWithoutPackage$>(EOEditingContext _editingContext, EOQualifier _qualifier) {
... ... @@ -244,14 +244,16 @@
244 244  
245 245  {{/code}}
246 246  
247 -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):
259 +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):
248 248  
249 249  {{code}}
262 +
250 250  public <$classNameWithoutPackage$> localInstanceOf<$classNameWithoutPackage$>(EOEditingContext _editingContext) {
251 251   return (<$classNameWithoutPackage$>)EOUtilities.localInstanceOfObject(_editingContext, this);
252 252   }
253 -{{/code}}
254 254  
267 +{{/code}}
268 +
255 255  {{code}}
256 256  
257 257  public static <$classNameWithoutPackage$> localInstanceOf<$classNameWithoutPackage$>(EOEditingContext _editingContext, <$classNameWithoutPackage$> _eo) {
... ... @@ -316,7 +316,7 @@
316 316  
317 317  === John Huss ===
318 318  
319 -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).
333 +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).
320 320  
321 321  {{code}}
322 322  
XWiki.XWikiComments[0]
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.probert
Comment
... ... @@ -1,1 +1,0 @@
1 -Please information about how to use the Java-based tools that are replacing EOGenerator.
Date
... ... @@ -1,1 +1,0 @@
1 -2007-12-12 21:55:29.0