Op 9 nov 2009, om 17:30 heeft Mike Schrag het volgende geschreven: > I still go back to "why d2jc" -- why not just do d2w? you have the point, i > suppose, about the assistant -- if that's a requirement for you, then you're > probably a sad panda with d2w (why doesn't this work, again?that's gotta be > relatively easily fixable, though everyone i've ever heard says it produces > horrid rules). Other than the assistant, the swing approach just seems more > complicated in every respect. If you're truly not styling the app at ALL, > then I guess you don't care about the cost difference, but as far as "why not > get a swing person," the answer is because a swing person is going to cost > 50% more and the development cost to make custom swing controls is > dramatically higher than tweaking CSS and HTML. I'll grant you that admin > apps typically don't have the polish of end-user apps, and that you might not > want to bother much, but I still am not feeling why you'd ever do a d2j > client over a d2w client. I guess we'll leave it at "'cause you want to" and > move along :) >
I have heard the 'Assistant produces horrible rules use RuleModeler' over and over again by very outspoken, well versed into the Direct To Web technology developers that have tweaked the rulegeneration and parsing themselves (Anjo and Guido come to mind). They might be right about the WebAssistant, but that means that people that are not well versed in that technology do not have a possibility to learn how these rules work. 'Read the source code of the available rules' is for a lot of people not the first idea that comes to mind I the want to learn a new technology that is supposed to be based on rules. I think that one of the reasons that there seems to be a lack of new WebObjects developers (according to Pascal's research) has to do with the falling away of these gentle tools: displaygroups that were automagically generated, WebAssistant that made you whip up a crude interface to a database in an hour. I remember one of the CodeFab guys telling learning WebObjects is not difficult because of the steep learning curve, but because there is a learning cliff. A gentler introduction (like the WebAssistant was) into the whole rulesystem really helped people to get into WebObjects. I would be nice if these tools should at least not be broken (like they are now with the D2WebService Assisant, the D2WebAssistant) until something as gentle came up. > ms > > On Nov 9, 2009, at 10:48 AM, David Avendasora wrote: > >> I think we are talking about two different uses of D2JC. I'm not really >> suggesting that it should be used to create an end-user UI in most cases. >> I'm saying that it is a powerful tool to aid in the development process. >> >> On Nov 6, 2009, at 12:42 PM, Mike Schrag 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. >> >> I guess my point is that when D2JC is used as a development tool, I wouldn't >> put _any_ work into making it look better. Neither would I for an >> CRUD-focused admin app. Sure, a perfectly native UI would be even better, >> but the amount of work it would take to make either a Cocoa or a Web UI to >> simply aid in development or do CRUD work is more than I think it's worth in >> these situations. >> >>> 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. >> >> I don't style D2JC at all. I use what comes out of the box. How can D2W (or >> anything) be faster than that? Sure you can use D2W out-of-the-box too, but >> if you think D2JC looks terrible, then the default look of D2W must make >> your head explode. I don't use D2JC to design the end-user UI. I'm using it >> to help design the Model and the business logic and populate the DB through >> EOF instead of SQL. I can get immediate feedback and see the impacts of >> these changes without having to write any UI code at all. >> >>> 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. >> >> Couldn't you hire a Swing guy to do swing controls just like you hire a >> CSS/HTML guy? In addition to that, what about the time to write rules by >> hand? With D2W there is no functional Assistant. Now, maybe some people find >> the rule system easy to understand and intuitive and find writing rules by >> hand easy, but I certainly don't and I've been doing D2JC for years. For me >> the Assistant is fundamental to the Model and Business-Logic validating >> process I'm talking about. Besides, how is hiring someone else to do the >> work a reduction in over-all work? >> >>> 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." >> >> I guess I'm not talking about a shipping a D2JC application, and certainly >> not an app with multi-screen workflows. While I think in some situations you >> _could_ ship a D2JC app to end users for simple CRUD-type work, I agree with >> you that if you want/need any control over the UI or multi-window workflows, >> then D2JC is not a good tool for that. >> >> What I am really talking about here, using D2JC for prototyping and >> model-to-business context validation, is the equivalent of using Entity >> Modeler for creating/modifying EOModels instead of using Property List >> Editor. For the initial prototyping process, validating that the model >> matches the business context, initial CRUD work, etc. With D2JC you get a >> very attractive and usable interface with zero work, where D2W takes much >> more effort to use it in this way. >> >> I also use D2JC extensively in reverse-engineering existing DBs into EOF. I >> can create a fully functional UI instantly from a reverse-engineered model >> that is hugely useful in allowing me to see the DB from EOF's perspective >> and figure out how to setup relationships and integrations. I've done this >> for portions of both Microsoft Dynamics and Jive for integration with >> WebObjects applications. >> >> Dave >> >> >>> >>> 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 >>>> ***** >>>> >>> >>> >>> >>> >> >> 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/johan%40netsense.nl > > This email sent to jo...@netsense.nl Regards, Johan Henselmans http://www.netsense.nl Tel: +31-20-6267538 Fax: +31-20-6279159 _______________________________________________ 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
