Re: Swing desktop app + EOF, three-tier
Re: Swing desktop app + EOF, three-tier
- Subject: Re: Swing desktop app + EOF, three-tier
- From: Ian Joyner <email@hidden>
- Date: Thu, 3 Nov 2005 12:49:38 +1100
Le 02/11/2005 à 11:52 PM, Florijan Stamenkovic a écrit :
Hi, thanks for the reply...
For the problem in general.. Well, I did bump into a small chapter
that describes how to start building this construction. It turns
out that we have to build two projects at the same time: a
JavaClient project to construct the AppServer target, and a Swing
Application project to define the user side. That one needs to be
tweaked a bit, and that is where we are going into at the moment.
Not much docs about it though...
Please see below for the response to your post.
On Nov 02, 2005, at 02:26, Ian Joyner wrote:
We are doing three-tier but with Nib files and Interface Builder.
It should certainly be possible to write the Swing yourself, but
it seems like it would be less painful to generate the Swing code
from an interface creation app. There are probably quite a few of
these around, but I know a little JBuilder and IB and would prefer
IB because it translates on the fly, whereas JBuilder more
statically generates code. The advantage to that is that it is
more tailorable, but with IB and EO, you can get at most of the
structures anyway and tailor the swing.
Uhm, we want a *standalone* app, so something you download, it
looks like any other application on whatever platform, and then
when you start up it tries to communicate with a database wherever.
Well, it is intended that we use those apps in a LAN situation, so
not really wherever. Anyway, WebStart is something we want to
avoid. Better performance and no security boundaries are a point as
well, as we expect to end up with a rather *heavy* application.
We have a standalone app, see the Desktop Applications book Chapter
11 pp237-. Can't argue with your other reasons though, except I
expect you can do diagrams, etc with custom panels in Nibs, because
that's what we intend to do. It would be rather an interesting
experiment to do a small but sophisticated app using both approaches
to really find out what the pros and cons are and whether the sorts
of problems I have are actually from the IB -> Swing translation or
come from the Swing. I guess there is no one on the group that can
advise better. (Although, our project has translated a pure Swing/SQL
two-tier application into an EO three-tier class. Some quick project
metrics are that the original project had around 100 handwritten
(apart from JBuilder generated swing) classes of around 5,000 lines
each. The new project has many EOModeler (EOGenerator actually)
generated classes, with just a few with 100 lines of written code,
and about 6 EOInterfaceController classes, the most complex of which
with 1,500 lines of handwritten code, which includes much more
functionality than the original.)
However, I would not say that the IB approach is exactly painless!
You might also like to think about the integration with EOModeler and
how you can just drag an EO entity into IB to create the display
groups, but otherwise you'll have to do that in code.
Other resons why:
-we plan to end up with an application that uses a LOT of extra
non translatable (from nibs) features like diagrams, charts, 3D
panels maybe etc.
-better look and feel control, better code control
-considering the amount of customizations a pure Swing solution
seems *much* cleaner
-reducing the amount of technologies involved due to expansion
ideas. So, as we make things more complicated, we would prefer to
avoid bumping into complications in nibs, web start, swing,
translation, WebStart behavior etc. If we use pure Swing projects
from start, we think we end up with a better code handling and
thereby make it easier in the future.
-resulting in a better user experience
As for user interface building, there for sure we will be using a
visual building tool that generates code. Translation on the fly is
exactly what we want to avoid.
If you need a Swing component that IB does not know about use a
Custom class (chapter 19). In fact, you could probably do
everything that way, just have an empty window in IB with the
contents one big custom class and just have a JComponent/
JContainer (whatever) subclass implement your Swing interface.
Did see it, didn't like it. It is as if we have to go through three
hoops for what (if we just use Swing) is only one.
What are you doing that you must avoid IB completely? It really
does a lot for you, but others might have better reasons to avoid
it than I do. I think the vaguaries of how IB maps to Swing (GUI
alignment problems, etc) might still be problems you have with
Swing (from comments others have made).
As for Swing itself, well, it ain't bad if you consider what it
tries to do, and how it does it. Of course IB and nibs and Cocoa in
general are very fine in general (and oh, would I like to use it
again...), and Swing is a more hm, strange toolkit to use, due to
not having a specific platform to consider (and that painful
avoiding of statically defined sizes that comes with it, urgh...).
Well, just like some other Java solutions... And that is exactly
what makes nibs and Swing just not mapping fine enough. They are
made for different problems. Well, just my opinion.
Hope that helps a little
Ian
It were points we already saw. And where we ended up pursuing the
standalone Swing app idea, it fits more with what we want to end up
with... Still, thanks a lot for the reply, hope this makes it
clearer why we go for it. And since we have to invest time in both
approaches, it seems better to pursue the one we feel can do more
for us.
Flor
_______________________________________________
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