Re: Swing desktop app + EOF, three-tier
Re: Swing desktop app + EOF, three-tier
- Subject: Re: Swing desktop app + EOF, three-tier
- From: Florijan Stamenkovic <email@hidden>
- Date: Wed, 2 Nov 2005 13:52:57 +0100
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.
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