Re: Rant: Why I hate Java Client
Re: Rant: Why I hate Java Client
- Subject: Re: Rant: Why I hate Java Client
- From: "Pierce T. Wetter III" <email@hidden>
- Date: Thu, 21 Feb 2008 10:11:48 -0700
Interesting situation. The eoaccess package is not provided because
it contains stuff that is irrelevant to the client. Mostly the
"connect to database" stuff. So it makes sense it is not there.
Like Lachlan says, log the exception on the server.
Yeah, I found that stuff on the Wiki and added that. My real problem
I suspect is that what I really need to do is figure out how .jar
files are supposed to be packaged up for the client side and send them
all across as well. This is an internal tool, so I don't really care
if our support people have to download bouncy castle, axis, etc. In
other words, I'd be perfectly happy with a brute force solution that
made the JC side include every jar referenced from the server side. Of
course all the Apple docs are for Project Builder, which doesn't exist
any more...
Plus none of this stuff works for me from Eclipse, because no one
ever got around to porting it fully to Eclipse when they moved the
rest of the projects over.
Meanwhile, the Support folks are whining, because I lowered the
boom and told them Java Client was going away,
Very much not true. Let the light of the JC sun shine on you and
realize: Apple is not dropping it! YAY! :)
Our JC app is going away because giving support folks a Direct-2-
Java-Client app as an admin app is stupid and lazy. (Or Direct2Web for
that matter.) The Support folks actually have a love-hate relationship
with it. They like that they can edit anything in the model but they
hate the "oops, I brought the site down because I hit return in the
wrong spot and it generated a table scan". Plus its buggy as all get
out, and engineering just blinks at them when they complain.
Our current app is like juggling chainsaws.
Meanwhile, support management wants them to STOP going through and
tweaking things in the model by hand. For 90% of what they do, there
should be a single link they can click on to fix the problem; not 5
different windows with 3 values each to edit. As we've started adding
those features to the new admin app, the support folks have taken to
calling it the "Easy Button".
In other words, long before I get to the annoyances with the JC app
architecture I run into the fact that it was never "designed" to begin
with, so it sucks just on that basis.
You should budget 5 admin pages for every dynamic page on your
website.
so they have to adjust to an app that isn't just a thin coat of
paint over Direct2JavaClient and actually come up with a
specification for what all they use this piece of shit for.
I've spent 40 hours over the last 2 weeks fighting with this stupid
thing. It takes me about an hour to build a screen in the new app
that will replace this crap.
The new app being based on which technology?
Something I've done at every company where I've deployed a WO
solution is create a series of components that give me sort of the
best of both worlds between writing everything by hand and a Direct 2
anything app. Basically, you provide an array and a list of key paths
in the wod file:
ilokTable: PACERCTable {
list = user.iloks;
displayPaths =
"alias
;serialNumber
;creationDate
;countAssets
;countLicenses;countIncidents;status.statusTitle;coveredByZDTString";
displayLabels = "Name;Serial;Creation
Date;Assets;Licenses;Incidents;Status;ZDT";
creationDateFormat = "%Y-%m-%d %H:%M";
countAssetsFormat = "___";
countLicensesFormat = "___";
aliasTunnel = "AdminiLokDetail;encryptedPrimaryKey;ILokID";
countAssetsTunnel = "AdminAssetSummary;encryptedPrimaryKey;iLokID";
countLicensesTunnel = "AdminLicenseSummary;encryptedPrimaryKey;iLokID";
countIncidentsTunnel =
"AdminIncidentSummary;encryptedPrimaryKey;iLokID";
actionLinks = "Transfer Ownership;AdminILokMail;iLokID";
sortSearch = true;
tableTitle = "iLok(s)";
includeCountInTitle = true;
}
PACERCTable then builds an HTML table with all the data using the list
of keypaths, formats, etc. The "Tunnel" specifiers specify a page, and
parameters for the page, that generates the link. You can have
additional links after the row.
The current revision also allows editing, and the engineer I have
working on it just integrated it with the DojoToolkit Grid stuff.
This ends up being superior to the JC stuff because:
1. Its way faster. A browser can display a table faster then
Swing can bring up a spreadsheet view, especially after having to
transmit a whole bunch of stub objects across the link.
2. You can have cross links between tables of data which makes it
trivial to follow
relationships.
3. It encourages you to actually design the damned thing, so
you're more selective about what columns to display.
4. It actually ends up with more features then JC, because you
can sort each column and do some other cool stuff that D2JC doesn't
supply.
5. No weird building problems.
6. Its faster to edit .wod files and click refresh than it is to
edit the whole rule thing.
7. You can probably figure out how to use RCTable from the .wod
file, but the rules system is pretty complex.
8. There are subclasses/variants that take the same parameters
but generating different views. HTable generates a table oriented the
other way and will take a single object instead of an array, which is
useful for detail/inspector type views. DownLink takes the same
parameters but emits a link which when clicked, downloads a
spreadsheet with the specified values. We have a version that lets you
specify which columns are editable.
9. YOU have control. See that "countAssets" key path? That's a
method on the ilok object that does ilok.assets.@count, but without
fetching ilok.assets, its based on stuff in our EOGenerator templates
that can do a count on any to-many relationship without fetching in
the relationship. Similarly, I could add lastMonthsTransactions as a
method to something, and then it would do a limited fetch instead of
everything.
Might I suggest switching to WO Java Client "the third way"? No
D2JC, no Interface Builder to Swing translation... It will still be
possible to get exception stack traces that are somewhat obscure
(until you get used to it at least, and apparently especially so if
the root of the problem is a thrown EOGeneralAdapterExeption), but
they will be shorter :)
Read that, won't help in this situation. Don't get me wrong, JC has
its place. There's definitely a use for a rich GUI client.
But an internal admin app is probably not the place, especially one
thoughtlessly churned out via D2JC. That's why I End-Of-Lifed it
internally. It's a bitch to support (in those 40 hours I could have
added/tested/debugged 40 pages to our new admin app or probably 5
"just fix it" links), it doesn't work, and its dangerous.
I also think that you want to really think about how the JC client
will work and interact with the server. I'm not sure that the standard
WOJC stuff encourages that. I think the objects on the JC side need to
be different objects then the server side.
Pierce
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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