Paul, I agree with you 100%. That's exactly the model I'm using on my application and that's really what I was trying to say. I don't know that I would call it a limux model since lots of applications use it.
I should also say to that I'm not arguing against web application, for Mitch's application. Since I don't know what the application is I can't do that. I use Google maps all the time if I quickly want to look something up or get quick directions. If I'm planning an across country trip though I would use something more powerful like Microsoft Streets/Trips instead of Google Maps. It all depends on the situation. We as developers have a habit of taking our favorite tool and use it everywhere even when it's not the best tool for the job. We happen to like hammers and we try to use a hammer when a screwdriver will work much better. In the end, we then wind up with frustrated users. I was only saying that we should not assume without even knowing what the domain is and who will use it that it should be a web app. There are many applications where a web app is the obviously the way to go. There are many where it is obviously not the way to go. There are also many shades in between. There are cases like with the map example that both are very useful. The best way to figure it out is to think about how ordinary every day people will use the application. Even better is to talk to them how they will or would use the application.
Jay
On 11/2/06, Paul Penrod <[EMAIL PROTECTED]> wrote:
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- PropertiesThe 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
