Re: Rant: Why I hate Java Client
Re: Rant: Why I hate Java Client
- Subject: Re: Rant: Why I hate Java Client
- From: David Avendasora <email@hidden>
- Date: Thu, 21 Feb 2008 13:41:53 -0500
On Feb 21, 2008, at 12:11 PM, Pierce T. Wetter III wrote:
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...
Any .jar files you want the client-side of the application to have
access to must be in the WebServerResources/Java/ directory. The
instructions here will help you setup an ant task to copy them over.
http://wiki.objectstyle.org/confluence/display/WO/Java+Client-Building.
If you have additional .jars for that directory, you'll have to add
additional ant statements to the build file to copy them in there.
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.
Sounds like more than Admins are using the Admin interface. There are
ways of paring down what a user can do in a D2JC app by simply adding
a rule to the .d2wmodel file, but I'd agree that with D2JC
deprecated, doing anything more than bug-fixing one is a waste of
effort. I have a rather large D2JC app that I find myself in the
position of trying to move away from, but the users of it have become
accustom to me being able to add significant new business logic in
just a few days because all I really have to do is add Entities,
write methods and modify the rules files. No messy Swing code to
refactor or write.
I also have the D2JC app as a separate app from the website. That way
they don't step on each other that much. Data freshness can be an
issue, but it is an issue no matter what.
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;countIncide
nts;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.
Huh. That's exactly the reason I am having such a hard time walking
away from D2JC. I can add a fully functional admin interface to new
tables in the database in just minutes (literally), and it will
follow the rules laid out by the EOModel which keeps people (mostly
me) out of farting around with the database directly and really
messing things up. Bug fixes are simple too because the only places
it can be are in the .eomodel file (which would likely mess up any
type of WO application) or in the .d2wmodel file, which is a PITA to
debug but once you learn the ins-and-outs of it, it's pretty easy to
figure out what is getting choked on.
Doing all this in a Web UI or pure Swing, will take me far longer.
And thats just to get the basic CRUD functionality. Don't even think
about adding the complexity of using AJAX to replicate the beauty of
having a rich GUI client.
I'll agree that D2JC as a general-release application is not a good
idea, especially now, but I will truly miss it for it's RAD/Proof-of-
Concept capabilities.
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.
_______________________________________________
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