 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2007the right way to do rich clients
Hello, For years my basic architecture has been a Swing Applet for the client, an application on the server, rmi to connect the two, and straight jdbc for persistence (recently changed to Hibernate) at the server side. POJOs all the way. In a desire to drop rmi and use a more web-friendly comm scheme, I started reading about all the technologies that I've bee woefully ignorant of, including: JBoss, servlets, SOA-SOAP, jsf, jsp, ... possibly others. Everything I've seen seems to use form-based html for the UI. Ick. The apps I'm involved with simply require a Swing-like UI. So, my question is: In the years I've been under my rock, what technologies have come along that I should use to do rich clients in a web-like way? Also, I've seen disparaging remarks about using Applets for "real" projects -- what is the preferred technology (I suppose WebStart?)? All comments very welcome. iasS...@gmail.com wrote: ... > ...Also, I've seen disparaging remarks about using Applets > for "real" projects -- what is the preferred technology (I suppose > WebStart?)? Yep. It gives an applet (or web-started application, preferably) so much more than what an applet alone can do for the end user, as well as neatly side-stepping (most of*) the applet/browser/VM interaction problems. * To replace them with the single hurdle of getting a browser to handle JNLP files correctly. What is it about your application, that cannot be done in pure HTML? Andrew T. > Hello, > [quoted text clipped - 17 lines] > > All comments very welcome. Ajax seems to be a buzz-word. Certainly killed my buzz though :-) j/k >What is it about your application, that cannot be done in pure HTML? Well, I don't think *most* applications can be done in html...at least not very gracefully. Code PhotoShop, or the Swing demo as html. Anything that involves visual real-time manipulation of data seems ill-suited for either the html presentation capabilities or the submit-respond roundtrip for updates. >Ajax seems to be a buzz-word. Certainly killed my buzz though :-) j/k- Yea, not so interested in that myself. Seems very much the hack. Plus, aren't you still stuck w/ html presentation? (you just get a better update methodology?) So, put another way: (How) can a Swing-based client application use port 80 to ship messages and get data? thanks much. > So, put another way: (How) can a Swing-based client application use > port 80 to ship messages and get data? Use web services. There are two main ways to do it: Have an app server return SOAP messages. Use Axis or the like. Soap has lots of overhead and complexity, though. Have an app server return XML in response to an http fetch. Simple, easy, clean. In your app server all you have to do is create a JSP page that accepts the appropriate params and returns the appropriate page formatted as XML. You don't even need to dig into servlet programming unless you need to get fancy. > >What is it about your application, that cannot be done in pure HTML? > > Well, I don't think *most* applications can be done in html...at least > not very gracefully. Note that I was not asking about 'most applications', the question was why does *your* application require it? >...Code PhotoShop, or the Swing demo as html. > Anything that involves visual real-time manipulation of data seems > ill-suited for either the html presentation capabilities or the > submit-respond roundtrip for updates. JavaScript can do most of what is required, for the two stated applications, without any round-trip to the server. Andrew T. >For years my basic architecture has been a Swing Applet for the client, >an application on the server, rmi to connect the two, and straight jdbc >for persistence (recently changed to Hibernate) at the server side. >POJOs all the way. Sounds reasonable. >In a desire to drop rmi and use a more web-friendly comm scheme, What's the driver for this? How is some other transport more web-friendly, if you're still using a Swing app for the client? >I started reading about all the technologies that I've bee woefully >ignorant of, including: JBoss, servlets, SOA-SOAP, jsf, jsp, ... >possibly others. Again, what specific problems are you trying to solve? Picking a technology without having requirements isn't likely to lead to happiness. >Everything I've seen seems to use form-based html for the UI. Ick. The >apps I'm involved with simply require a Swing-like UI. Examples are likely to all be form-based. It's easy and works near-universally. That doesn't mean you have to do it that way. >So, my question is: In the years I've been under my rock, what >technologies have come along that I should use to do rich clients in a >web-like way? What do you mean by web-like? You just said you needed something swing-like. Please describe more specifically what you're looking for. AJAX is the hot new buzzword for getting more responsive apps in a webbrowser. It's basically writing your UI in html and javascript, and using javascript to make calls to the server to get data and display it without a complete page reload. For use inside a company, I'd far rather use Swing - it's so much easier to write and debug, and you get a lot more control over what actually happens. For public use, the compromizes that AJAX brings are worth it, as it's just incredibly valuable to have no plugins, no installation (except a semi-modern browser), and somewhat application-like in behavoir. >Also, I've seen disparaging remarks about using Applets >for "real" projects -- what is the preferred technology (I suppose >WebStart?)? I like WebStart for Swing clients. It seems to have fewer difficulties for users with plugin management than applets. I also like "download, unzip, and run" methodology, or actually writing an installer, depending on requirements. -- Mark Rafn dagon@dagon.net <http://www.dagon.net/> >What's the driver for this? How is some other transport more web-friendly, if you're still using a Swing app for the client? The driver is to largely to eliminate hassles w/ internet (as opposed to intranet) use -- not bieng so concerned about firewalls and all that. Your question to me is, in fact, my original question. >Picking a technology without having requirements isn't likely to lead to happiness. fair enough. Another strong driver for all of this is my desire to pull myself out from under my rock and learn something new. Hence the shotgun listing. >Examples are likely to all be form-based. It's easy and works near-universally. That doesn't mean you have to do it that way. Interesting. It always seemed to be html/form-based by necessity. How can one do it differently? thanks much. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.