Re: Uses for D2JC (was: Gianduia and WO)
Re: Uses for D2JC (was: Gianduia and WO)
- Subject: Re: Uses for D2JC (was: Gianduia and WO)
- From: Mike Schrag <email@hidden>
- Date: Fri, 6 Nov 2009 12:42:56 -0500
Sure, I agree yours is real and mine's a picture, but that wasn't
really my point. My point was about visual mismatch with the native
platform. If you're OK with the app looking .... like Java ... , by
all means, ship it. I find Java desktop apps to be mostly visually
repugnant (the same reason that I work on Maclipse, but at least SWT
has a fighting chance), and I don't believe you can actually make it
un-gross without a huge amount of work. It's a question of what
matters to you, though.
That said, pretty much everything in the main chunk of your email
isn't really D2JC, it's just D2*. I'm sold already on the RAD value of
D2* technologies, I'm just not at all convinced that D2JC is the right
D2 to choose in most cases. If time-to-market is the primary concern,
it seems to me that you have dramatically faster styling and design
capabilities with D2W. You can hire an designer off the street to do
CSS/HTML work for you, whereas you'd dump a pile of hours into custom
Swing controls. This is essentially the same argument I have against
the IB/Cocoa style of development. The RAD time in IB/Cocoa is just
way longer than making the equivalent UI web-based. Maybe one screen
you can layout a little quicker, but start doing multiscreen
workflows, and you're just sinking time into Cocoa work (you can
really see this when you try to RAD an iphone app -- i find it to be
very expensive to do in contrast to web RADing). The flip-side, of
course, is that it looks awesome. It's the trade-off again.
So I guess the question is really "given a project spec, what feature
in the project would cause on to choose D2JC over D2W."
ms
On Nov 6, 2009, at 11:48 AM, David Avendasora wrote:
On Nov 6, 2009, at 9:54 AM, Mike Schrag wrote:
couple mins of Interface Builder mockup (mac-up?):
<PastedGraphic-2.png><PastedGraphic-3.png>
Nice looking and it shows how powerful Interface Builder can be in
making UIs, but mine isn't just a mock-up it's a fully functional
application - warts and all. It really talks to the server, sync
ECs, validates, etc. etc. Again, I dropped an EOModel into my
template project and launched it. Then used the EOAssistant to
configure which attributes showed, what type of widget they used
(PopUp, text field, explorer, etc) and where they appeared on the
screen. That's it. No code. There's not a single Java Class besides
Application, DirectAction, Session and two components: Main and
JavaClient, none of which are modified beyond the stock template.
So D2JC is certainly _passable_, but it's far from being a proper
mac app (those default old style boxes are the dead giveaway for
java apps, though there's a Swing client property to switch box
styles, IIRC). Now, certainly, if you spent enough time, you could
tweak things and make it a lot closer, but it's always going to be
off.
Yes, and so will any web app, only more so. Now, your point about
the uncanny valley is very true. D2JC comes almost too close to the
look of a native app. If it were further off like a web app people's
expectations would be lowered and no one would complain. But being
uncanny hardly seems a valid reason to throw away something that
saves literally _hundreds_ of hours of development time, especially
for internal, CRUD-type admin applications.
But I don't think that using D2JC to create shipping CRUD-type
applications is really its most appropriate or useful application.
To me, it's all about lowering project risk by getting stake-holders
involved as soon as possible in the development process and as a
prototyping and model-validating tool.
D2JC is an incredibly powerful tool when used as a means to an end.
WIth D2JC you can have a _fully functional_ application with just an
EOModel. This allows you, as a developer, to get a true feel for how
well your model represents the business context without having to
write any code. You can immediately start creating records in the
database, setting relationships, deleting objects, orphaning them,
etc. through EOF which will verify that the relationships are
properly setup including that your deletion rules and ownership
settings work as you expect. Again, you can do all this without
writing any code! You don't have to ever show it to an end-user if
you don't want to.
Change your model? No problem. Rebuild (copy the revised EOModel to
the build directory) and relaunch your app and your changes are
immediately reflected in the UI. Since you haven't written any code,
you don't have to refactor! What's better than Eclipse's refactoring
tools? Not needing to refactor at all. D2JC greatly speeds the
process of modeling and validating that the model reflects reality.
On top of all this, since you have a fully functional application,
with all CRUD functions, revert functionality, validation, etc, it
_can_ transition into the initial data-entry, data-cleanup
application to populate/scrub the database and even be used by non-
developers (business users). How many times have you created
spreadsheets for users to do data entry into so you can then import
them into the DB? With D2JC what you give them can be a real
application that writes directly to the DB.
Keep in mind that you can do all of this - requirements to working
prototype - in ONE DAY with no code. It is easy to start with some
basic requirements, create a model, then an app, and take it to the
stake-holders to show how various pieces fit together and get even
better feedback on workflows because you are giving them something
they can see and understand not an abstract diagram. You can then
make revisions and return with a revised, working application
_minutes_ later. Yes, I said minutes!
Once you've validated that the Model accurately reflects reality by
having actually putting it to use, you can now start the labor-
intensive process of creating the finely tuned UI that looks and
works exactly how you want it to. Because you have already done a
substantial amount of model and business context validation there
will be far less risk of having to tear it all apart due to having
missed something fundamental in the model.
I'd like to see any other technology do that, WO-based or not.
And we're just talking chrome, not behavior of the app, which is
often even more off.
D2JC certainly has some UI clumsiness to it, especially when working
with many-to-many relationships and dealing with Inheritance.
Of course you have to do all these tweaks for each platform, too --
though you're a fair bit closer than my CocoaClient app is running
on Windows :)
I think what it comes down to is that I would not suggest using D2JC
in a situation where you have to have complete control over the UI
or have even reasonably complicated work-flows. On top of that, I
don't think it would be worth the effort to tweak the UI for one
platform, let alone multiple ones. The fact that it runs "passibly"
on all Java platforms without writing any UI code at all, to me is
simply amazing and incredibly powerful.
Whew, that's more than I intended to write. :-)
Dave
ms
On Nov 6, 2009, at 8:50 AM, David Avendasora wrote:
On Nov 6, 2009, at 8:17 AM, Mike Schrag wrote:
So if we're stirring the pot here ... For me, it's not being cool
in the browser, it's about Java apps looking terrible. You can
immediately tell when you're using a Java app ... Things are just
never quite right, but they try to sell themselves as being
native. It's an uncanny valley situation. Eclipse/SWT are using
native controls for lots of things and they get it wrong, too.
Swing just doesn't have a chance. Go try IDEA -- it looks
TERRIBLE. Look at their preference panels. I tweeted when IDEA
went free that I can see how to make Eclipse right, but I'd never
be able to make IDEA right.
I understand the uncanny valley. In most cases you are absolutely
right. Here's a screen grab from my current D2JC project, I think
it looks pretty good, although it doesn't look like a modern OS X
app (iTunes, etc):
<PastedGraphic-3.png>
For browser apps, it's obvious they're not native apps, and the
bar is set low in the browser at this point, so you can make a
slick looking app, and it doesn't have to be perfectly native,
and people are still OK with it. I would be far more interested
in CocoaClient where you actually have a chance of pulling off a
nice end-user deliverable.
I agree. For me a WO Cocoa Client is the Holy Grail of Client-
Server. I want it. Badly.
That said, I recognize that there are plenty of apps where
"looking slick" doesn't really matter -- that you just need to
get some business app out there. But what does Java bring to the
table that you're not getting in the browser?
With plain WebObjects JavaClient, you get
1) Real Java on the client. No messing around learning JavaScript
(or waiting for the "next great JS framework") to implement UI
logic.
2) EOF on the Client with
- automatic syncing of Client and Server EditingContexts (works
very similar to Child ECs)
- batching
- faulting
- validation
Why not just use D2W? Drag and drop is about the only thing, and
that will be in the good browsers pretty soon.
For me, it's not about the features you get in the client,
although there's some cool stuff that way too. It's the dead-
simple development side that makes it so awesome to me. With
WebObjects D2JC you don't have to write _any_ code at all. No
HTML. No CSS. No JavaScript. Not even rules! You hear that D2W
guys? The D2JC EOAssistant works great and it will write most of
the rules you need! Here's a screen capture of it (it's also a
Java Client app that communicates with WOLips to update the
user.d2wmodel file):
<PastedGraphic-6.tiff>
Anyway, I didn't mean to hijack this thread with Java Client, but
hey Anjo brought it up! :-P
Dave
I do, however, think D2JC is a _neat_ technology, in that it's
amazingly clever what it's doing under the covers, I just am not
sold on the end result.
ms
On Nov 6, 2009, at 7:41 AM, David Avendasora wrote:
Hey! Did I hear "JavaClient"?! :-D
Yeah, it will be cool if someday we get the tools to do
something client-server like JavaClient.
Oh wait! We already _have_ WebObjects-based JavaClient, and
Direct-To-JavaClient and it works today and has for _years_.
Sure, it's not as "cool" as a browser-based solution, in the
same way WO isn't as "cool" as Ruby.
**ducks, runs for cover and scrambles to get the D2JC project
template updated**
Dave
On Nov 6, 2009, at 7:32 AM, Anjo Krank wrote:
Not really sure... basically you'd need something totally new,
as this would be more like JavaClient and not like a web app.
But all this is *moot* until we don't have it.
Cheers, Anjo
Am 06.11.2009 um 13:05 schrieb Mike Schrag:
Yeah .. I suspect there could be a GianduiaLook, and that
would make a lot of sesnse.
ms
I think we've seen with the SproutCore stuff that it's not.
Apart from *maybe* a JS D2W.
Cheers, Anjo
Am 06.11.2009 um 02:54 schrieb Mike Schrag:
rom my perspective, I don't know that it's worth building a
server stack on top of it as much as I think it would be
nice to leverage the development tools we already have to
make it easier to write the Javascript.
_______________________________________________
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
_______________________________________________
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
David Avendasora
Senior Software Engineer
K12, Inc.
*****
WebObjects Documentation Wiki : http://wiki.objectstyle.org/confluence/display/WO/
*****
WebObjects API: http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html
*****
_______________________________________________
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
David Avendasora
Senior Software Engineer
K12, Inc.
*****
WebObjects Documentation Wiki : http://wiki.objectstyle.org/confluence/display/WO/
*****
WebObjects API: http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html
*****
David Avendasora
Senior Software Engineer
K12, Inc.
*****
WebObjects Documentation Wiki : http://wiki.objectstyle.org/confluence/display/WO/
*****
WebObjects API: http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/index.html
*****
_______________________________________________
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