You could argue that it doesn't matter much if a JavaClient looks awful on the Mac since 90% of your user will be running Windows - and probably more for a business application. Also, the Nimbus<http://bp0.blogger.com/_B11qFTiSj3U/SF-fNZv6DKI/AAAAAAAAAAM/D7NvQQzwYzQ/s1600-h/nimbus.gif>look and feel introduced in Java 1.6 is pretty nice, and available for Java 1.5 with a separate library. It is very aqua-like, but not native, so you don't have to worry about it not quite matching the native look, sort of like the way browser apps do.
Still, I agree that I prefer SWT's appearance to Swing's. You can also make a JavaClient app with SWT (not a D2JC one though). John On Fri, Nov 6, 2009 at 11:42 AM, Mike Schrag <msch...@mdimension.com> wrote: > 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 (Webobjects-dev@lists.apple.com) >>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>> >>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>>>>>>>> >>>>>>>>> This email sent to msch...@mdimension.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> >>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com >>>>>>> >>>>>>> This email sent to webobje...@avendasora.com >>>>>>> >>>>>>> >>>>>>> >>>>>> 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 (Webobjects-dev@lists.apple.com) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> >>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>>>>> >>>>>> This email sent to msch...@mdimension.com >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> 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 (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/johnthuss%40gmail.com > > This email sent to johnth...@gmail.com >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
