Rob Nagler wrote: > Solved with refresh? JavaScript and Java can also help here.
Yes, solved with refresh. Of the entire page. Which may be quite complex and have some hefty SQL queries, etc...not to mention other issues such as network latency, the re-rendering of the page, etc...all distract from the user experience, which may or may not be an issue for the particular application. For example, I once coded an HTML-based game where you guessed movie quotes and if you got it right, you replaced it with one of your own. Two of the issues were 1. I wanted a list of who was currently playing but it quickly got out of date and to update it would mean to refresh the entire page, go to frames, or put the list in a separate window, all messy. 2. When one user correctly guessed a quote, I would have liked to have all the other users' screens update with that new info, but that's impossible without having something like a java applet embedded in the page checking for new data and forcing a refresh of the page. Yes it works, but it's messy once again. These are real issues, and issues which I have solved as best as possible on the web but that are easier in other systems. >Cookies work fine. > You oversimplify. Cookies do work fine. What creates, reads, modifies, validates the cookies? What ties the cookies to useful state information that is stored server-side? There's a lot of coding potentially involved. Yes, perl modules exist. Yes, they'll most likely need customization (in my case, I've customized AuthCookie, and tied it to Apache::Session. It wasn't the end of the world, but it wasn't trivia. A cookie by itself is of rather limited usefulness. >Tedious is questionable. Impossible, I seriously doubt. Remember, >you can always delegate part of your screen to a Java applet, although >I strongly recommend you avoid this. > Reinventing common widgets by coding up in HTML, CSS, JavaScript something that's a one-liner in a typical GUI environment is not tedious? I think you're oversimplifying again. As for a Java applet, a java applet ceases to be a web frontend. It's a GUI front end using the web as a communication/distribution layer. Once it's launched, you use stateful sockets to talk back to the server, etc... If you find yourself doing a majority of your interface via java applet (which is not something you want to try if cross-browser implementation is a desired feature, by the way), then you might as well make it a standalone java app, especially since you're apt to hit the applet security sandbox on any sort of robust app. There are a TON of positives to web frontends. I'm not arguing. I have made my living for the past 8 years building these things, I'm a friend of the web front end. =) You've captured the positives quite well, so I don't need to reiterate. But let's not fall into the trap of saying the web is the best tool for every front end usage imaginable. The user has said fancy menus and graphs are to be the mainstay of the app. I speak from first-hand experience, hell my current project has both of these things in a web interface, and neither were trivial. I crafted an expandable-tree menu (think Windows Explorer style menu) from HTML, CSS, JavaScript and HTML::Template. I have graphs dynamically generated using GD::Graph. Both took time, lots of trial and error, and lots of hair-pulling. Massaging the data for GD::Graph was just one chore I remember being harder than expected. These tools worked and are great tools that enable things on the web that aren't otherwise possible, but it was hard -because- it was a web app with all the inherent limitations - these things are much more native to traditional GUIs. In my case, we have a -need- to be a web app and so I'm willing to jump through hoops to make the interface richer where we need it to be, but if I was choosing between web and traditional, and I didn't -need- web, and I knew that graphs and fancy widgets were the mainstay of my app, I'd think twice before trying web. Fancy widgets especially are not that much fun to code on the web when a very robust library of them already exist for most GUI systems. Yes, it can be done (though there are still some things which I found impossible, some widgets which I don't think can be duplicated acceptably on the web. I like clicking on column headers and have them resort without doing a round-trip, for instance) but it's not much fun sometimes. That's my only point. -Fran
