On 12/21/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > Interestingly, this example confirms the counter argument that Hubert is > raising :-). Double clicking an Open Office document causes that document > to be opened, but *not* where it was when you closed it, or what you might > have captured in the clipboard. That is the difference between an > identifier (a URL for the web, a document path for the word processor) > versus the associated state information that needs to be kept about the > dynamic "position" you are with respect to that document.
I don't expect Office to open the document where it was when I was last in it. And I don't expect, say, the Mail Archive to go to the paragraph I was reading when I was last looking at some message. But if I provide it the path to the document I want to open, I want to be able to open it without having to go through a wizard, or a file open dialog, etc. If I know the ID of my yahoo groups, I don't want to have to go through its front page, run a search, select from a list of similarly named groups, just to get to my group. > Put another way, please show me how a Swing app is supposed to handle > bookmarks (or the back button, for that matter). > > "What?" you say? "There IS no such thing!" > > My point exactly :-). My point too. There's no such thing on a swing app, because it's not a web app. If I work on a swing app, I won't impose web app limitations on it. Why would I impose client app limitations on a web app? Why prevent web apps from doing something normal in its environment? > In a Swing world, it's totally up to the application to maintain and restore > any state information it wants to deal with. But, for applications that do > *not* care about such state, dealing with URLs is a distraction to > accomplishing the goals of building the app -- for those folks, let's PLEASE > not make it harder. I don't have anything against making that easier. But making one easier shouldn't have to mean the other one is disallowed. I appreciate that JSF is applying a different approach to web development, making it more like client side development, but it was disappointing when I learned that the cost is difficulty in providing basic web app features as well. > Craig > > Hubert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
