Changes for page EOF-Using EOF-EOGenerator

Last modified by Pascal Robert on 2012/01/21 22:03

From 20.1 to 21.1 From 24.1 to 25.1

From version 21.1

edited by Pascal Robert
on 2007/12/21 20:55

Change comment: There is no comment for this version

To version 24.1

edited by Quinton Dolan
on 2007/07/16 22:42

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

@@ -1,1 +1,1 @@
--EOF-Using EOF-EOGenerator
++Programming__WebObjects-EOF-Using EOF-EOGenerator

Author

@@ -1,1 +1,1 @@
--XWiki.probert
++XWiki.qdolan

Content

@@ -1,18 +1,14 @@
--|= Contents
--| {{toc style="disc" minLevel="2"}}{{/toc}}
++|=Contents
++|
--== Overview ==
++{{toc style="disc" minLevel="2"}}{{/toc}}
--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.
++== Overview  ==
--{{warning}}
++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.
--EOGenerator don't work on Mac OS X 10.5.&nbsp; You either have to use [JavaEOGenerator|http://developer.apple.com/samplecode/JavaEOGenerator/] or [Velocity EOGenerator|WOL:Velocity EOGenerator (Veogen)].
++== Advantages  ==
--{{/warning}}
--
--== 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.
@@ -19,7 +19,7 @@
  * 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 ==
++== How To Use It  ==
  Kieran Kelleher has writtten an [[Introduction to EOGenerator>>http://homepage.mac.com/kelleherk/iblog/C1837526061/E1908382110/index.html]] on his blog.
@@ -30,34 +30,34 @@
  {{panel}}
--eogenerator \-model /path/to/model/YourModel.eomodeld \-destination /path/to/source/folder
--\-subclassDestination /path/to/source/folder \-templatedir /path/to/EOGenerator/templates \-java \-packagedirs
++eogenerator -model /path/to/model/YourModel.eomodeld -destination /path/to/source/folder
++   -subclassDestination /path/to/source/folder -templatedir /path/to/EOGenerator/templates -java -packagedirs
  {{/panel}}
  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
++* --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 ==
++== Custom EOGenerator Mods  ==
--=== Zak Burke ===
++=== 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.
  {{code}}
--public void save<$ToOneRelationship.name.initialCapitalString$>(<$ToOneRelationship.destinationEntity.referenceJavaClassName$> value)
++  public void save<$ToOneRelationship.name.initialCapitalString$>(<$ToOneRelationship.destinationEntity.referenceJavaClassName$> value)
    {
      if (value == null)
      {
@@ -73,13 +73,13 @@
  {{/code}}
--=== Chuck Hill ===
++=== Chuck Hill  ===
  Return the list of changes between the current EO and the last committed version of the EO:
  {{code}}
--public NSDictionary changedProperties() {
++  public NSDictionary changedProperties() {
      NSDictionary commitedValues = editingContext().committedSnapshotForObject(this);
      return changesFromSnapshot(commitedValues);
    }
@@ -86,13 +86,13 @@
  {{/code}}
--=== Jonathan Rentzsch ===
++=== Jonathan Rentzsch  ===
  Jonathan Rentzsch has provided his base EOGenerator templates, which are a must-have:
--[[http://rentzsch.com/share/eogenerator52templates.zip]]
++http:~/~/rentzsch.com/share/eogenerator52templates.zip
--=== Markus Ruggiero ===
++=== Markus Ruggiero  ===
  Constants for all attributes and relationships. This allows compile time error checking in situations like
  addObjecttoBothSidesOfRelationshipWithKey(myObject, Person.TO//MANY//Children)
@@ -99,7 +99,7 @@
  {{code}}
--<$foreach attribute classAttributes.@reversedArray do$>
++  <$foreach attribute classAttributes.@reversedArray do$>
      public static final String ATTRIBUTE_<$attribute.name$> = "<$attribute.name$>";<$endforeach do$>
    <$foreach ToOneRelationship classToOneRelationships.@reversedArray do$>
@@ -114,15 +114,15 @@
  {{code}}
--<$if attribute.userInfo.usage h1.  booleanFlag $>    // boolean accessors
++  <$if attribute.userInfo.usage h1.  booleanFlag $>    // boolean accessors
      public void <$attribute.userInfo.setterName$>(boolean newBoolean) {
        set<$attribute.name.initialCapitalString$>(newBoolean ? "true" : "false");
      }
--
++
      public boolean <$attribute.userInfo.getterName$>() {
        return "true".equals(<$attribute.name$>()) ? true : false;
      }
--
++
      // validation
      public String validate<$attribute.name.initialCapitalString$>(String newValue) {
        if ( newValue  null ) {
@@ -137,13 +137,13 @@
  {{/code}}
--=== Mike Schrag ===
++=== 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)~://
  {{code}}
--public static final String ENTITY_NAME = "<$name$>";
++  public static final String ENTITY_NAME = "<$name$>";
  {{/code}}
@@ -179,23 +179,15 @@
  {{code}}
--public static NSArray fetchAll<$classNameWithoutPackage$>s(EOEditingContext _editingContext) {
++  public static NSArray fetchAll<$classNameWithoutPackage$>s(EOEditingContext _editingContext) {
      return <$GEN_PREFIX$><$classNameWithoutPackage$>.fetchAll<$classNameWithoutPackage$>s(_editingContext, null);
    }
--{{/code}}
--
--{{code}}
--
--public static NSArray fetchAll<$classNameWithoutPackage$>s(EOEditingContext _editingContext, NSArray _sortOrderings) {
++  public static NSArray fetchAll<$classNameWithoutPackage$>s(EOEditingContext _editingContext, NSArray _sortOrderings) {
      return <$GEN_PREFIX$><$classNameWithoutPackage$>.fetch<$classNameWithoutPackage$>s(_editingContext, null, _sortOrderings);
    }
--{{/code}}
--
--{{code}}
--
--public static NSArray fetch<$classNameWithoutPackage$>s(EOEditingContext _editingContext, EOQualifier _qualifier, NSArray _sortOrderings) {
++  public static NSArray fetch<$classNameWithoutPackage$>s(EOEditingContext _editingContext, EOQualifier _qualifier, NSArray _sortOrderings) {
      EOFetchSpecification fetchSpec = new EOFetchSpecification(<$GEN_PREFIX$><$classNameWithoutPackage$>.ENTITY_NAME, _qualifier, _sortOrderings);
      fetchSpec.setIsDeep(true);
      NSArray eoObjects = _editingContext.objectsWithFetchSpecification(fetchSpec);
@@ -202,19 +202,11 @@
      return eoObjects;
    }
--{{/code}}
--
--{{code}}
--
--public static <$classNameWithoutPackage$> fetch<$classNameWithoutPackage$>(EOEditingContext _editingContext, String _keyName, Object _value) {
++  public static <$classNameWithoutPackage$> fetch<$classNameWithoutPackage$>(EOEditingContext _editingContext, String _keyName, Object _value) {
      return <$GEN_PREFIX$><$classNameWithoutPackage$>.fetch<$classNameWithoutPackage$>(_editingContext, new EOKeyValueQualifier(_keyName, EOQualifier.QualifierOperatorEqual, _value));
    }
--{{/code}}
--
--{{code}}
--
--public static <$classNameWithoutPackage$> fetch<$classNameWithoutPackage$>(EOEditingContext _editingContext, EOQualifier _qualifier) {
++  public static <$classNameWithoutPackage$> fetch<$classNameWithoutPackage$>(EOEditingContext _editingContext, EOQualifier _qualifier) {
      NSArray eoObjects = <$GEN_PREFIX$><$classNameWithoutPackage$>.fetch<$classNameWithoutPackage$>s(_editingContext, _qualifier, null);
      <$classNameWithoutPackage$> eoObject;
      int count = eoObjects.count();
@@ -229,22 +229,14 @@
      }
      return eoObject;
    }
--
--{{/code}}
--
--{{code}}
--
--public static <$classNameWithoutPackage$> fetchRequired<$classNameWithoutPackage$>(EOEditingContext _editingContext, String _keyName, Object _value) {
++
++  public static <$classNameWithoutPackage$> fetchRequired<$classNameWithoutPackage$>(EOEditingContext _editingContext, String _keyName, Object _value) {
      return <$GEN_PREFIX$><$classNameWithoutPackage$>.fetchRequired<$classNameWithoutPackage$>(_editingContext, new EOKeyValueQualifier(_keyName, EOQualifier.QualifierOperatorEqual, _value));
    }
--{{/code}}
--
--{{code}}
--
--public static <$classNameWithoutPackage$> fetchRequired<$classNameWithoutPackage$>(EOEditingContext _editingContext, EOQualifier _qualifier) {
++  public static <$classNameWithoutPackage$> fetchRequired<$classNameWithoutPackage$>(EOEditingContext _editingContext, EOQualifier _qualifier) {
      <$classNameWithoutPackage$> eoObject = <$GEN_PREFIX$><$classNameWithoutPackage$>.fetch<$classNameWithoutPackage$>(_editingContext, _qualifier);
--    if (eoObject ==  null) {
++    if (eoObject h1.  null) {
        throw new NoSuchElementException("There was no <$classNameWithoutPackage$> that matched the qualifier '" + _qualifier + "'.");
      }
      return eoObject;
@@ -256,16 +256,12 @@
  {{code}}
--public <$classNameWithoutPackage$> localInstanceOf<$classNameWithoutPackage$>(EOEditingContext _editingContext) {
++  public <$classNameWithoutPackage$> localInstanceOf<$classNameWithoutPackage$>(EOEditingContext _editingContext) {
      return (<$classNameWithoutPackage$>)EOUtilities.localInstanceOfObject(_editingContext, this);
    }
--{{/code}}
--
--{{code}}
--
--public static <$classNameWithoutPackage$> localInstanceOf<$classNameWithoutPackage$>(EOEditingContext _editingContext, <$classNameWithoutPackage$> _eo) {
--    return (_eo == null) ? null : (<$classNameWithoutPackage$>)EOUtilities.localInstanceOfObject(_editingContext, _eo);
++  public static <$classNameWithoutPackage$> localInstanceOf<$classNameWithoutPackage$>(EOEditingContext _editingContext, <$classNameWithoutPackage$> _eo) {
++    return (_eo  null) ? null : (<$classNameWithoutPackage$>)EOUtilities.localInstanceOfObject(_editingContext, _eo);
    }
  {{/code}}
@@ -274,7 +274,7 @@
  {{code}}
--<$if !ToManyRelationship.inverseRelationship$>
++  <$if !ToManyRelationship.inverseRelationship$>
    	public NSArray <$ToManyRelationship.name$>(EOQualifier qualifier) {
    		return <$ToManyRelationship.name$>(qualifier, null);
    	}
@@ -283,12 +283,12 @@
    	public NSArray <$ToManyRelationship.name$>(EOQualifier qualifier) {
    		return <$ToManyRelationship.name$>(qualifier, null, false);
    	}
--
--  	public NSArray <$ToManyRelationship.name$>(EOQualifier qualifier, boolean fetch) {
++
++  	public NSArray <$ToManyRelationship.name$>(EOQualifier qualifier, boolean fetch) {
    		return <$ToManyRelationship.name$>(qualifier, null, fetch);
    	}
    <$endif$>
--
++
    	public NSArray <$ToManyRelationship.name$>(EOQualifier qualifier, NSArray sortOrderings<$if ToManyRelationship.inverseRelationship$>, boolean fetch<$endif$>) {
    		NSArray results;
    <$if ToManyRelationship.inverseRelationship$>
@@ -324,25 +324,25 @@
  {{/code}}
--=== John Huss ===
++=== 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).
++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).//
  {{code}}
--@SuppressWarnings("all")
++  @SuppressWarnings("all")
    public class _Invoice extends ERXGenericRecord {
    }
  {{/code}}
--=== Guido Neitzer ===
++=== 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:
  {{code}}
--/**
++/**
   * Initialization of the instance while inserting it into an editing context
   */
  public void awakeFromInsertion (EOEditingContext editingContext) {
@@ -353,3 +353,5 @@
  {{/code}}
  This is from my JavaSubclassSourceTemplate.eotemplate
++
++Category:WebObjects

Changes for page EOF-Using EOF-EOGenerator

Summary

Details

Applications

Navigation

My Recent Modifications

Need help?