To me JDNC seems like a halfway house between webapps and rich client apps.
I personally like the way that webapps work (everything is written for the server and executed on the server then merely displayed at the client), but I hate the interface (html - and browser). The web interface lacks consistency across browsers and (simple) rich gui components. It also lacks an event model (ok, so you can use javascript to catch events and fire off forms/etc - but this isn't very eloquent) - and lets face it, rich, clever apps need a gui event model. I have been toying with the idea of an alternative browser - an application browser which is used to launch remote applications instead of an html browser. Basically you have a browser which is designed to display GUI components (including custom gui components). User interfaces are specified (xml, or similar) and it loads them and displays them. It then processes events, and events can either be handled locally through a scripting language, or remotely through an event in the application code. The application code itself is running on a server. Applications are mainly event->action driven. Applications have read/write access the user interface. As a developer you just code the app and declare the gui. The user uses a standard bit of software to access the app. Daniel. > -----Original Message----- > From: Erik Weber [mailto:[EMAIL PROTECTED] > Sent: 11 November 2004 15:20 > To: Struts Users Mailing List > Subject: [OT] Re: A new paradigm of Struts development > > > Vic, why we would want to continue to write apps for Internet Explorer > and Netscape after discovering a technology like this is beyond me. My > chips are in with you. I have been pushing my web-app minded clients > toward Swing all along, but technologies like Java Web Start and now > JDNC are really going to strengthen my case. > > I have a question for you. Sorry if the answer is obvious and I just > haven't read enough. > > I have invested a lot in writing custom UI classes, custom paint > methods, custom UI defaults properties, etc., to get my Swing components > looking the way I want (I'm sorry but, changing the background colors, > and other easily-scriptable stuff, doesn't cure Swing's out-of-the-box > ugliness). Also, I am amassing a collection of custom components, such > as self-validating forms and custom JTextPane-based browsers. > > In fact, one of my browsers builds layouts based on my own metalanguage > (soon to be XML). It embeds diagrams with captions and draws arrows from > the captions to the diagrams based on simple coordinates, etc. Seems > like I was doing JDNC without even really knowing about JDNC. ;) > > I do not intend to abandon my current set of GUI devices, but obviously > I would like to leverage JDNC if it's worth it, not to mention provide > compatibility. Will JDNC support my own look and feel (or pseudo look > and feel)? Can it be easily modified to work with my custom components? > > I'm not even sure if I should bring up the question of security. Suppose > I have a custom file chooser. Will there be a sandbox concept like that > of Applets? > > Thanks, > Erik > > > Vic wrote: > > > Adam Hardy wrote: > > > >> > >> What I want to see in the future for big apps is a DTD or xml schema > >> that brings JSP code and XHTML mark-up under control. Something that > >> is easily editable by my editor of choice, using syntax-highlighting > >> to show me where my XHTML is up the swanny. > >> > > > > > > Just in case you missed my posts about a great Sun open source project > > JDNC that will be a part of J26 Standard Edition (Mustang), it does > > above, one of the reasons that I am "raving" about it, check it out: > > > > http://javadesktop.org/jdnc/0_5/docs/tutorial/index.html > > > > And I am using it w/ a lot of success. Right now I am just doing the > > "Swing" extensions, but will tie in UI via XML (and will add code to > > make it work w/ Hessian SoA, it's trivial binding). > > > > My chips are behind JDNC. > > > > .V > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
