Re: JavaEOGenerator running, but I do not understand the output.
Re: JavaEOGenerator running, but I do not understand the output.
- Subject: Re: JavaEOGenerator running, but I do not understand the output.
- From: Mike Schrag <email@hidden>
- Date: Sat, 10 Nov 2007 21:46:26 -0500
The trick was:
1- replace the -model argument with the full path, and add file: in
front of it
eg: from [Example.eomodeld] to [file:/Users/johan/projects/example/
Resources/Example.eomodeld].
2- replace -destination path with the full path without the file:
in front of it.
eg: from [Sources] to [/Users/johan/projects/example/Sources]
3- replace -subclassDestination with the full path without the
file: in front of it.
eg: from [Sources] to [/Users/johan/projects/example/
Sources]
The next build of WOLips fixes this by supplying full paths instead of
relative paths to the External EOGenerator.
_ProgramSetting.java
ProgramSetting.java
base/_ProgramSetting.java
.ProgramSetting.java
Do you not use packages for your EOs? Maybe that's where the . file
ones came from? Obviously the _ProgramSetting.java is the old one, so
that could be deleted. ProgramSetting.java is your file, so that's
fine, base/_ProgramSetting.java is the new default base class. You
can override the filename template to not include ".base." in the
package name (and the default superclass template to remove base). It
appears that the default templates will not actually build on 5.3,
though, so you would need to change them.
- What is the idea behind all this? (please no "42" answers)
see above.
- Why the base folder?
they just chose that as the default package for the base class.
- Why the .class.java file?
I can't explain this except something related to default package
(which you should not do anyway). Maybe this is also from an entity
that doesn't have a class name defined?
- Should the class files should be in a package, and where is that
defined?
Technically that is a bug in JavaEOGenerator, but from a best-
practices standpoint, absolutely every single java file should be in a
package. It's defined by the class name in your EOModel file for each
entity.
- What to do with the old java files? Merge them?
The subclass is basically the same, the superclasses are autogenerated
anyway. If you continue to use the .base. syntax, obviously your
subclasses will need to be modified to point to this new superclass.
And finally:
- Are these generated files also usable in a 5.3 environment?
Well, if you modify your templates to be 5.3 compliant, then yes, but
the example templates are 5.4-only it looks like.
The other alternative is that you can use the Velocity-based
EOGenerator (yes, Virginia, there are two eogenerator replacements).
I have not mentioned this so far to just keep things less complicated,
but we actually use this EOGenerator variant rather than
JavaEOGenerator, so maybe others will find it to be useful also ...
JavaEOGenerator is Apple's recommended way, Velocity EOGenerator is
the "yeah, but you can do this too" way (aka the "my way"). If you
modify your EOGenerator settings and remove your eogenerator
executable path (leave it blank), it will switch to use the built-in
Velocity eogenerator instead of an external one. There are example
templates (that are actually my own templates) built-in, which you can
download and modify/replace ( http://webobjects.mdimension.com/wolips/EOGenerator/Velocity EOGenerator Templates/
). You'll need to modify your .eogen files to remove your eogen
executable path and to point to the new templates. I personally
prefer Velocity syntax for these over WO syntax ... It's a lot more
compact, and I find it to be easier for this type of templating, but
that's just me. One other (technical but possibly important) factoid
is that the Velocity EOGenerator sits on top of Entity Modeler's
EOModel stack whereas JavaEOGenerator sits on the WO 5.4 EOModel stack.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden