Re: EOModeler Issue
Re: EOModeler Issue
- Subject: Re: EOModeler Issue
- From: Chuck Hill <email@hidden>
- Date: Wed, 13 Jul 2005 18:12:25 -0700
On Jul 13, 2005, at 5:59 PM, Ian Joyner wrote:
I think I have almost fixed my own question. I changed
JavaClientSourceEOF52.eotemplate
public abstract class <$GEN_PREFIX$><$clientClassNameWithoutPackage
$> extends EOGenericRecord {
to
public abstract class <$GEN_PREFIX$><$clientClassNameWithoutPackage
$> extends <$javaParentClassName$>#change server to client# {
which produces:
public abstract class _Y extends com.sportstec.A.server.X#change
server to client#
note that this generated 'server' in the string, not 'client',
hence I added the junk string #change server to client# to remind
me to change it manually (which is at least better than finding
keys have suddenly gone missing at run time).
However, if there is a place holder of the form <
$javaParentClientClassName$>, I'd be even happier. (I did try that.)
I can almost recall where to look for the headers, but not quite.
Try parentEntity.clientClassName.
But I suppose I still have a niggling question as to why
EOGenericRecord has been there for so long. (Except I suppose that
I have found that very few people use Java Client, let alone
multiple models and/or inheritance (of which I have used all three
forms in their correct place to create an elegant and non-redundant
model).
I think that is probably your answer.
(OK, I could also do with multiple inheritance done right (as in
Eiffel), complete with attribute renames and DBC with inheritance.)
Oooh, Ian knows about Eiffel. :-) I'll bet you have a copy of OOSC
too. AspectOriented Programming is probably the best you are going
to do in Java for MI like functionality. We use Jass for DBC in
Java, it works reasonably well - depending on your definition of
reasonably. We have integrations for xCode (not overly tested yet)
and Eclipse.
Chuck
On 14/07/2005, at 10:18 AM, Chuck Hill wrote:
What does the class definition part of the client template look like?
Chuck
On Jul 13, 2005, at 5:01 PM, Ian Joyner wrote:
Having recently adopted EOGenerator, I agree that it is not only
the workaround, but the way you want to generate files in the
short/long term. However, it has a small bug (or perhaps I am not
using it quite right) when generating client-side files which
inherit from a parent-side class (which might also be due to
inheritance from another model). In model B, class Y inherits
from class X in model A. Server-side classes are generated fine:
public abstract class _Y extends com.sportstec.A.server.X {
but on the client side we just get:
abstract class _Y extends EOGenericRecord {
not
public abstract class _Y extends com.sportstec.A.client.X {
so you have to change the extends by hand everytime you change
the model (which thankfully doesn't happen that much, if you have
done your modelling right). I think this is a bug (either in
EOGenerator or in the EOModeler files if they don't keep a parent
for the client-side class), unless I have something set up wrong,
which maybe someone could advise me on, if so.
But having to make that small change is certainly superior to
running the risk of EOModeler just clobbering the files you have
put all your code in.
Here is a handy shell script (and the one I use if there is any
problem with it) that I use:
#!/bin/sh
USERPATH=/Users
USER=ianjoyner
EOGENERATORDIR=$USERPATH/Shared/Applications/eogenerator-1.6.X
EOGENERATOR=$EOGENERATORDIR/eogenerator
MODELS=$USERPATH/$USER/Development/<your path>
DEST=$USERPATH/$USER/Development/<your path>/BusinessLogic
TEMPLATES=$EOGENERATORDIR/Templates
MODEL=B # The model to generate files for
ENTITY=Y # If only one entity, include this
EOGEN_ARGS=-java
$EOGENERATOR $EOGEN_ARGS -model $MODELS/$MODEL.eomodeld -
templatedir $TEMPLATES -refmodel $MODELS/A.eomodeld -refmodel
$MODELS/B.eomodeld -refmodel $MODELS/C.eomodeld -refmodel $MODELS/
D.eomodeld -destination $DEST/$MODEL/Server/Generated -
subclassDestination $DEST/$MODEL/Server $ENTITY
EOGEN_CARGS=-javaclient
$EOGENERATOR $EOGEN_CARGS -model $MODELS/$MODEL.eomodeld -
templatedir $TEMPLATES -refmodel $MODELS/A.eomodeld -refmodel
$MODELS/B.eomodeld -refmodel $MODELS/C.eomodeld -refmodel $MODELS/
D.eomodeld -destination $DEST/$MODEL/Client/Generated -
subclassDestination $DEST/$MODEL/Client $ENTITY
I include this as a resource file without a target in Xcode so I
can edit it quickly and simply drag it from the "Groups & Files"
panel to terminal when I want to run it.
Ian
Sportstec
On 14/07/2005, at 3:40 AM, Chuck Hill wrote:
Hi Ryan,
Another BC resident using WO, cool!
This is a bug in WO 5.3. IIRC, you can fix this by copying some
templates or some such from WO 5.2.4. I side step the whole
issue and use EOGenerator to handle the generation. It is a
more flexible and powerful solution. You will want it
eventually, might as well start using it now.
http://www.rubicode.com/Software/EOGenerator/
Chuck
On Jul 13, 2005, at 10:35 AM, Ryan - CyberScript wrote:
Hello All,
I have recently started learning WebObjects and love it but
seem to have come across a problem that I have no clue how to
solve.
After the EOModeler reads my previously created MySQL database
schema, I select a table and choose "Generate Java Files", it
asks for a location to save and I choose the location of my
WebObject project, when I click Save it comes up with the error
"Unable to write file /Users/ryan/KelownaLife/Account.java"
Please let me know if I am doing something wrong, if this is a
bug or if you need any further details.
Thanks,
Ryan Campbell
CyberScript
--
Practical WebObjects - a book for intermediate WebObjects
developers who want to increase their overall knowledge of
WebObjects, or those who are trying to solve specific
application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40sportstec.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects
developers who want to increase their overall knowledge of
WebObjects, or those who are trying to solve specific application
development problems.
http://www.global-village.net/products/practical_webobjects
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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