Re: [Ldsoss] Non-Web Application Frameworks

[Paul Penrod]

I'd like to take your premise one step further. For years in the Unix, IBM, DEC and many other frame environments, network connections and the subsequent protocol and remote applications (such as Web, Gopher, FTP, etc.) were treated as resources and not requirements in many instances. I personally don't see an either or situation here. In a sense, this is mostly an academic exercise, as the original poster did not say what problem the application was going to solve, why he wanted to use JAVA in the first place, and other information that would have made the discussion (at least in his direction) more germane and helpful. Getting back to point here. I would suggest for consideration a more Unix like approach to the problem, where you have a client piece that can run independent of a network connection and the network piece that allows for functionality related to data/processing requiring such. For example, Legacy (a genealogy program) uses such a model, by operating as a standalone application until you need to get to the Internet for updates, searching for information, preparing files against the Church's Family Search website. This gives one a mobility advantage in that when you are "docked" with a network connection, you can perform those information management functions that require a connection, and then run "undocked" and use the application. One can make the argument: Lots of programs do this and have been for years.. My answer to them is "Yep, it's been that way since the 1950's". Just because it's been around a long time, doesn't mean it's not useful. It may not be fashionable , but really, nothing new has been invented for many years. We are seeing the migration of mainframe techniques and concepts making it's way towards the desktop. This mindset of it's either a standalone or a Web/Network/Client centric application is rather recent and rather narrow in my view. ...Paul Jay Askren wrote: There are still many advantages to client apps.  Even though the internet has boomed, not everyone has access to the internet every minute of the day and if I have my laptop with me, I would like to be able to use some applications even though I might not have access to the internet.  Sure, I could install a web app on my laptop, but then that defeats the purpose of having a web application in the first place.  If PAF were a web app, I'm sure I wouldn't use it.  I like not being tied to the internet.  For my Emergency Response Database, I have created a desktop app.  I do some things like call web services to geocoding so that I can display our ward members on a map, but the application isn't useless if the user doesn't have internet access.   Also, if I were running a scientific application that just crunched numbers for several hours and showed me the results, it would probably be much easier and sensible to create simple client application to do that.  There are a lot of applications that are just not suited to web applications at least at this point and time.    One can do some pretty cool things with AJAX, but I've found that AJAX over a 56k modem isn't much fun.     Jay   On 11/1/06, Mary Shaw <[EMAIL PROTECTED]> wrote: Have you fully considered the advisability of writing the application as a client app as opposed to a web-based app?   I've taken a few such full-blown applications and turned them into web-based apps.  As time goes on, I (and my bosses) find more & more reasons to develop new applications as web-based apps rather than client apps, or port existing client apps to the web.  There's a lot less fuss when it comes to creating installers, testing & deploying the app on different operating systems, and rolling out updates.  Users can access the site from computers other than their main computer (in case of power outages or vacations).  Things like look & feel, layout, and buttons & controls can be easily manipulated using CSS and the browser takes care of copy/paste and client-side file access.  You also have the ability to send out alert or reminder e-mails if the app requires it.   I started a personal project about 3 years ago as a client app but put it down after not very long (family reasons).  I'm going to pick it up again soon, and this time I'm going to build it as a web application.  I know it will be a better application as well as easier/faster to write.   One major concern when deciding between web & client apps is report printing.  At my last job, I had to create printed reports from the web, and it was a ROYAL pain - mostly because the customer required it to be exactly like the original app's printed report with pagination and special headers/footers for the first and subsequent pages.  But that port was from Perl on Linux to Perl on Windows (it wasn't my decision) and I couldn't find a PDF library.  I honestly don't know what kind of PDF creation you can find for Java.   If you have good reasons for doing it as a client app, it's my opinion that Swing can do it all and the best thing to tackle all that stuff with would be a good book.   Mary   On 10/31/06, Mitch Butler < [EMAIL PROTECTED]> wrote: I'm a low-level OS-type guy with a reasonable amount of Java knowledge. However, I'm a beginner at things like GUIs and Swing. I have an idea for a Java Application that I would like to develop. It will a standalone program that runs on a single machine and must have a reasonably good GUI.   I've been teaching myself Swing, and all that stuff is very cool. But I find myself having to write too much stuff from scratch that I know has been done before. Plus my framework stuff doesn't look very nice! I need an Application Framework to hang my code on.   I stayed up late last night (too late according to my wife!) searching the Web, and I found a few candidates: Aloe, JSR 296, JGoodies, Eclipse, XUI. There are also a whole host of other frameworks (too many!) that are targeted more at Web-type applications (AJAX, JLense, Radicore, etc.). I don't think I'm ready for those yet. But then I don't know, as I will want to learn Web App development eventually.   Anyway, does anyone have experience with those that I mentioned or others that I don't know about yet? I want to be able to quickly and easily prototype my ideas. I'm looking for something that helps me with the following kinds of things:   - Error/Exception handling - Logging (of events and special conditions) - Menus, buttons, controls - Window management (changing fonts and styles) - Look and Feel management (I want to try different L&Fs to see what I like) - Tables of data, sortable in different ways, and editable - Printing facilities for reports - Multi-threading (kicking off a background task, and updating the GUI with progress) - Copy/Paste - Message boxes - File access - Properties   The one thing I don't need is a database. My data is reasonably small, so I plan to just serialize the objects into a file and reload them into memory whenever the App starts up. That is actually the kind of code that I am pretty good at. It is the GUI stuff that gives me fits.   I'm using Eclipse as my IDE, and I especially like the idea of actually using Eclipse as the framework itself (RCP). But that sounds like a huge learning curve and perhaps overkill, and I want to have something working soon in my spare time.   Anyway, I suppose if I spent several weeks with each of the above technologies, I could eventually figure out which one meets my needs best. But I don't want to do that right now (lazy me!). So, I'm looking for advice from those who have more experience in this area. _______________________________________________ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss _______________________________________________ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss _______________________________________________ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.13.22/512 - Release Date: 11/1/2006

_______________________________________________
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss