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
Point well taken. On the other hand I've been seeing some amazing
things taking place in web technologies that have the potential to
obsolete much of the need for a client-based solution. AJAX is
almost by definition much easier for IT departments to support. They
only have to be concerned with one (or a small group) of servers.
Here we have several dozen client machines using the Java client-side
application. I can't tell you the support nightmare this places on
our IT group.
A really great AJAX app would solve that particular problem. I would
prefer to see Apple, and the community, place their efforts on AJAX
solutions rather than getting sides-tracked advancing Java Client.
Maybe my frustrations fighting Java Client have tarnished my
impression of it, but there you go.
Not to say that there isn't some workable solution to extend the life
of parts of Java Client. As long as it doesn't impede the efforts
going on in other areas.
On Jun 22, 2007, at 2:45 PM, 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
--
Robert Walker
[EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
