The solution of generating the client class was almost perfect. It now generates the header fine:
public abstract class _Y extends com.sportstec.A.client.X {
but EOGenerator also goes on to generate all the accessor methods that are inherited from the parent class X, so are redundant. It doesn't do this for the generated server side class.
And I had to change the template to:
public abstract class <$GEN_PREFIX$><$clientClassNameWithoutPackage$> extends <$if hasParentEntity$><$parentEntity.clientClassName$><$else$>EOGenericRecord<$endif$> {
in order for EOGenericRecord to be added if there wasn't a parent. On 14/07/2005, at 12:04 PM, Ian Joyner wrote:
On 14/07/2005, at 11:12 AM, Chuck Hill wrote:
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.
Perfect!
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.
And these are probably the best features for building really large, complex stuff and being able to manage the complexity. Unfortunately, I had many teething problems, particularly with EOModeler, but once you are past these it all works fine. I no longer have EOModeler crash when I synchronize the database, or have to edit the plists because they got corrupted somehow. I don't know whether a lot got fixed in 5.2.4, or whether just making large changes in the early days of modelling (especially when you don't really know what you are doing). Anyway, that's my experiences, and unfortunately are probably things that stop people using models and inheritance, or even worse, EOModeler and WO altogether.
I also found EOModeler prototypes (in EOPrototype) are great to be able to define common strings (char_1, char_8, char_64, etc) as well as primary and foreign keys, and if you want to change these, you can do it once globally. But I suspect not many people are using prototypes, either. I found only a few bugs, like prototypes cannot be defined in terms of other prototypes, and setting one to itself put EOModeler in a loop (reports submitted to Apple). In fact, I think Enterprise Objects could reach an even higher level of abstraction (translate that as "much easier to use and create systems") if things like prototypes were more built in (or better type handling and definition in general). Maybe CoreData addresses such issues for Cocoa, but we need cross-platform development (while staying as far away from Windows as we possibly can, because Apple developers do actually need to provide things to the wider world to survive).
(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.
Only one... three actually, the original and the other two signed by Bertrand.
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.
Now if only there were a library to interface Eiffel to WO like there is to Cocoa, I'd be really happy, but I think when Apple banished Objective-C for Java only, they cut off a lot of other possibilities too. With the extra facilities in Eiffel to build well-structured, bug-free programs in WO, I'd be in heaven!
Java drives me a bit crazy, especially having to put imports in every source code file for things which are global to a project (Eiffel just does this once in the ACE, (or equivalent) file, and all those extraneous parentheses and braces especially the empty ones '()' for a low-level call operator which should have gone out with FORTRAN and COBOL. And all the type casts all over the place because of non-generic containers, and lack of type variance, things like 'like <type>' in Eiffel, and the "?=" assignment attempt. However, WO makes up for so much and really puts databases on a new level.
Maybe in another lifetime Ian Sportstec
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.
|