Hi all,
There seems to be a lack of distinction in different ways to use WO JavaClients. It seems that most people see this being done as either the direct or non-direct approaches described by Apple. BUT, there is another approach that does not utilize large portions of WO's JavaClient support code, where most trouble comes from.
This approach comes down to using client side EOF only for data persistence, within any kind of a Java app. There is no D2JC auto-generated GUI, rule systems, translations from nib to Swing etc. All the places where WO's JavaClient capabilities become difficult and error prone.
I feel it is important to point this out, as the whole "dropping of WO Java Client" by either Apple or users of it, can imply different things:
1. Dropping direct-to stuff
2. Dropping Nib to Swing
3. Dropping ALL of the JavaClient code including data distribution classes
The first two causes most of the trouble (IMHO), but dropping it does not have to imply dropping the third. I also think that part of the JC code base is relatively small, not difficult to maintain, and yet opens a door for WO to be used in a not very popular, but powerful way.
I know that I am speaking for a very small percentage of a very small community, but I hope Apple has mercy on us there.
Two cents,
Flor
However, it is my opinion that dropping Java Client is the right thing to do. It is technology that was deeply rooted in the Objective-C version of WO in the pre-version 5.0 days and really has not translated very well to the Java world. It's crazy building swing application using Interface Builder and translating Cocoa controls to Swing controls. It just makes programming Java Client really difficult and it's q