Re: Java Client refuses to use Client-Side classes once deployed
Re: Java Client refuses to use Client-Side classes once deployed
- Subject: Re: Java Client refuses to use Client-Side classes once deployed
- From: Ian Joyner <email@hidden>
- Date: Mon, 25 Jun 2007 09:51:20 +1000
We use Nib to Swing. It's a difficult technology to use and Swing
does not help – apparent bugs in JC are really bugs in Swing, which
Apple has no control over. Three-tier client-server does not seem to
have caught on as expected (maybe I should read the Client/Server
Survival Guide, which seems to have made a 3rd edition in 1999 again:
http://www.amazon.com/Client-Server-Survival-Guide-3rd/dp/0471316156/
ref=pd_bbs_sr_1/103-7723472-9845462?
ie=UTF8&s=books&qid=1182728366&sr=8-1).
I think there are some exciting things going on with AJAX (thanks
Apple and Mike Schrag), but I don't think these give a full desktop
experience (as yet). We are using JC for data entry (customers use
both Mac and Windows). Data mining is mainly done with D2W (thanks
for enhancements Apple and Anjo Krank).
What do other people use JC for?
Ian
On 23/06/2007, at 4:45 AM, Florijan Stamenkovic wrote:
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
_______________________________________________
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:
This email sent to email@hidden