Re: Interfaces and Java Client
Re: Interfaces and Java Client
- Subject: Re: Interfaces and Java Client
- From: David Avendasora <email@hidden>
- Date: Wed, 26 Apr 2006 15:55:39 +0100
- Resent-cc: Paul Lynch <email@hidden>
- Resent-date: Thu, 27 Apr 2006 06:53:19 +0100
- Resent-from: David Avendasora <email@hidden>
- Resent-message-id: <email@hidden>
- Resent-to: wo-dev Apple <email@hidden>
Okay, maybe I need to re-think my architecture (won't be the first
time!) Let me give a quick run-down of an example of the basic
structure and maybe someone can give me some tips on how to architect
it in a nice OO/WO way.
I have a Superclass of Part and three subclasses of Raw, Intermediate
and Finished. (this is not a case of a state change, they are three
different types of Parts)
Intermediate and Finished will have a BillOfMaterial because they are
both built from one or more other Parts. Since not Raw cannot have a
BillOfMaterial I cannot relate BillOfMaterial to Part. Right now,
instead of saying that these two classes are related directly to
BillOfMaterial they both implement a IHasComponents Interface and the
BillOfMaterial is related to IHasComponents.
Raw and Intermediate can be BillOfMaterialComponent because they can
be used to make other Parts. Finished cannot, so I have both Raw and
Intermediate implementing IIsComponent and BillOfMaterialComponent is
related to IIsComponent.
It doesn't matter to a BillOfMaterial what type of Parts make up its
components, only that they have some specific attributes and methods.
Isn't this the proper OO/Java way to handle these types of
relationships?
Dave
On Apr 26, 2006, at 3:23 PM, Robert Walker wrote:
David,
Unfortunately, you've gone beyond my experience. I've used
interfaces across EOs but not in the way you are describing here,
and never on the client-side.
However, I'm not surprised you are having trouble with this
design. There are some relatively complex things happening under
the surface. Each EOEntity has an associated EOClassDescription
and a graph of objects to represent attributes, relationships,
etc. With JavaClient there is also the distribution channel to
deal with. Not to mention EOEditingContexts.
I've seen no Apple documentation on using Java interfaces within
the EOF environment, so I've always avoided attempting it, other
than very basic uses of interfaces to provide a way to "abstract"
some behavior. This was used to accommodate combining entities of
different types into a collection. This was necessary due to a
legacy design that could not be altered. The system contained some
information in two different tables that I needed to treat the
same. There were a few differences in the two tables that I
handled through implementing my interface in each of my
EOGenericRecord subclasses. But as I said this was very basic stuff.
On Apr 26, 2006, at 4:30 AM, David Avendasora wrote:
Here is some more detail after some substantial work on this:
I think it all comes down to that EOModeler and Direct to Java
Client (and probably Direct to Web) cannot handle interfaces.
(Please tell me I'm wrong!) If the actual code does not agree with
the .eomodeld package, then it causes all sorts of weirdness.
I originally had Entities in EOModeler for each interface, that
way I could set relationships to them, configure their attributes
and relationships, etc all within EOModeler. This worked GREAT for
the ability to generate java files automatically with EOGenerator
and a few custom templates that both created interfaces and
implemented them and it compiled beautifully.
The problem was the application would not work if the generated
interface and implementing class files were built in the Web
Server target (as they are supposed to be in a D2JC application).
It worked fine if they were built in the Application Server target
but then other custom code broke. I still don't understand why
they worked in the wrong target, but whatever the case, it was not
a workable solution.
I made substantial progress by removing the interface entities
from the EOModel and remapping the relationships from the
interface entities to the entities that were previously
implementing the interfaces. For example:
Interfaces: Label toOne IHasLabel
No interfaces: Label toOne Part
But this won't work unless Label's class is EOGenericRecord
because "Part" is, in fact, an abstract class and can't be
instantiated yet my eomodeld package IS telling it to. This is one
of my reasons for using an interface in the first place. That
along with the fact that Part is the Superclass to 3 other
classes, only two of which would ever have a label, so having the
relationship to Part is not an accurate design anyway! These two
subclasses implemented the IHasLabel interface.
I've tried manually modifying the .plist files within
the .eomodeld package so the relationships are set properly, but
That generates a "java.lang.IllegalStateException: Server
exception: EORelationship(): cannot find entity named IHasLabels
for destination of relationship part in entity Label." exception
in the console.
Can anyone give me insight into proper use of interfaces in a
Direct To Web/Java Client context??
Thanks,
Dave
On Apr 25, 2006, at 2:34 PM, Robert Walker wrote:
David,
Are you adding your interfaces to both the "Application Server"
and "Web Server" targets? I've not tried this myself, but if
your interfaces are in the "Application Server" target only, then
that may be why they don't work on the client-side. I know this
is a simple thing and you are probably already do this, but I
thought I would mention it just in case.
On Apr 25, 2006, at 4:55 AM, David Avendasora wrote:
Hi all,
I'm working on a Java Client project. I am trying to implement
interfaces instead of inheritance in several places, but I'm
running into a problem.
I'm using XCode for development and if the client-side classes
are built in the Web Server target as they are supposed to be
according to the Apple WO Java Client documentation, the
interfaces don't work. The proper SQL is executed on the
database, but no objects ever show up in the client application.
If I simply change the target to Application Server, then
everything works exactly as would be expected.
Does anyone have any idea why interfaces built to the Web Server
target don't work?
Thanks!
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
--
Robert Walker
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:
40avendasora.com
This email sent to email@hidden
--
Robert Walker
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:
This email sent to email@hidden