Re: Java Client : who is using it ?
Re: Java Client : who is using it ?
- Subject: Re: Java Client : who is using it ?
- From: email@hidden
- Date: Mon, 25 Jun 2007 11:35:10 +0200
I'm very happy finally someone is talking about this. So far we only
built web apps with WO, but we plan do replace our large inhouse
application done with obsolete technology by a WO Java Client solution.
My first trials with this and the sheer absence of any references
here one the list or elsewhere made me doubt, this is the right way.
But so far I didn't find any alternative. And AJAX definitely is not!
AJAX is useful (although technically ugly) for nice UI stuff in web
apps. But if you want JC you want other things. We for example have
to do a lot of data processing on the client. Another thing is
intelligent search techniques using preprocessing on the client.
I really wonder why the whole industry ends up in pure terminal
software rooted in mainframe architecture. Where is the possibility
to do real client/server computing that has been promised to us for
years now?
Florijan, I'm really interested in your approach of using JC without
auto-generating Java code. How do you combine your Swing code with
the EOF stuff? Do you use the controller classes from JC?
On 23.06.2007, at 22:14, Florijan Stamenkovic wrote:
Philippe,
We are currently working on one large project, and have plans for
future Java Client projects based on WO. I can not go into much
details, but will try to point out as much relevant information as
possible.
Our large project is a database system targeted at companies who
could use good centralized data management (that's specific, huh?).
We chose the JC approach to this because of the amounts of data
that are being put into the system, and desired output
capabilities. Our client app is a regular Swing application, and
utilizes EOF only for data retrieval and management. It pretty much
comes down to using EOEnterpriseObject, EOClassDescription,
EOEditingContext, Foundation, and RMI built into EOF. The Swing
part is substantially more complicated. We are talking at the
moment about a couple dozen different data input forms, highly
specialized, and plenty of architecture around general data
procedures. There is a lot of advanced manipulation involved
("advanced" implying that simple user actions may trigger
complicated data manips, as opposed to "type into the field, store
into the eo"). There is also plenty of summarizing of data,
visualizing etc. All of this makes us really happy to offload as
much as possible processing, validation, summarizing etc to the
client processor. Of course, there is the responsiveness of the app
to consider as well; there are no lags on data validation etc, the
app behaves like the data is locally stored (after the initial
fetching delay that is).
The client side app is around 45000 lines. During it's development
I've made a couple thousand more lines of general EOF + Swing code,
and isolated it for further projects built with the same approach.
We could not achieve this with a web based app, I doubt we could
come anywhere near even if we invested a lot of sweat into AJAXing
it all. As for the EOF part, it is irreplaceable to us, as it is
just so damn good. I have looked into alternatives, even thought of
writing custom server side frameworks, but none of it could replace
EOF in any acceptable implementation cost / time. We *need* EOF to
take care of it's part for us, otherwise as a small development
company we can not make this product come true. We believed Apple
when they said that we could do it. I remember reading dozens of
times in their docs about not reinventing the wheel. Reusing stuff.
Building on top of... Well, it only works if the big guys don't
start to pull the rug from under your feet.
Are we satsified with this approach, assuming nothing gets dropped?
YES. YES. YES. YES. Swing is getting better and better, Java in
general as well. JFX says it will refresh things up, AND be
compatible Swing. Java 2D and 3D are getting better as well. The
platform is growing in capability. Not even mentioning the plethora
of fantastic third party code that can be found (printing,
graphing, GUI improvements...). And WO provides enormous data
sharing capability for it. Which is AFAIK furthest down the road in
it's line of business, AND provides a way to output the same data
easily in browsers. And yes, there is other good stuff out there,
but am I wrong in seeing this also as an excellent choice?
Sorry if I am over-advocating. It feels warranted by the current
state of things.
Best regards,
Florijan
p.s. - except for Philippe here, I know of only three or four other
people who use WO this way. I continuously wonder why there aren't
more of us...
Hi,
I changed the subject of the mail because your mail content was no
more appropriate ;-)
I completely agree with your mail. In the WO FF session of the
last WWDC, I explained that the lack of support of Java Client is
a very bad thing for some developpers because we are working on
very big projects.
For my part, we have worked on several applications with Java
Client for a very well known bank. And there is a big project in
France involving 50 universities. There is a web site (http://
www.cocktail.org) only in french. The home page lists a part of
applications developed with Java Client and there are a lot ...
And there is a developer in this team who makes incredible stuff
with Java Client.
The Apple WO team needs to know how Java Client is used. So the
best thing is to send an email to Pierre Frisch, the manager of WO
team with a description of the project. And if you are allowed to
speak publicly about your project, please, send it to the list too.
Philippe Rabier
_______________________________________________
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
_______________________________________________
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