And this is precisely the point that I was trying to make. A browser is not
(currently) a suitable environment for writing desktop applications. But
the problem is not HTML. HTML is markup, and is perfectly fine for what I
need to do.
The problem is that if I use a browser for writing desktop applications,
then I have to jump through a lot of hoops just to get basic stuff like
this working, just to prevent a user from doing something silly.
You said that 'This is not how a web page is supposed to work'. I agree
completely. But this thread is about desktop applications. Not web pages.
Two different things.
Speaking from personal experience, the clients we talk to are interested in
having web/browser based applications because:
1) It makes their deployment a lot easier. All they have to deploy is a
server. To update their applications, they deploy a new war. That's it.
2) The development is thought to be cheaper. Whether it is or not is a
different matter, but that is how it is perceived to be.
Unfortunately, you are not my client. In general, my clients do not
understand that clicking on the back button is a bad idea. They don't
understand that it's a bad idea to hit backspace outside of a textbox or
text area. So as a developer, I have to create code to ensure that if my
client does something silly, then it doesn't screw his data.
The problem is not that web browsers were not designed for use as desktop
applications. You said elsewhere that it wasn't designed for it. Agreed.
The problem is that they are being used for desktop applications. I could
say no to my clients, but then I wouldn't earn any money :-)
Matthew.
Le 5 nov. 2010 18:24, Rob Ross <rob.r...@gmail.com> a écrit :
On Nov 5, 2010, at 2:52 AM, Matthew Farwell wrote:
> For me, the main advantage of using a browser for RIA is you don't need
to install anything on client machines. However, there are a couple
things that always irritate me when I'm doing RIA for clients, as opposed
to a traditional application.
> Please note that I'm not talking about public web sites, I'm talking
about internal applications that are not exposed to the public. So please
don't respond 'I wouldn't want this to happen on my browser', it's not
going to happen on your browser. You will never see this application, you
won't even know it exists.
> 1) Disabling navigation/back button functionality. This gets me every
time. I NEED to be able to prevent the user from going back a page. No
discussion, no 'You should educate the user not to do that'. Taking
firefox as an example, you can go back a page in (at least) three ways:
backspace, click on the back button, right click on the page. That means
I have to somehow prevent the user from doing these three things. And not
counting refresh, multiple submits and preventing them from entering a
different URL. What is needed is the option to disable navigation. Full
stop.
No, you are doing it wrong. This is NOT how a web page is supposed to
work, whether on a corporate LAN or via the Internet at large.
I ** HATE ** it when web apps try to get around the fact that they are
web apps by playing little tricks like hiding the menu or trying to
disable the back button.
I'd suggest if you *really* need to do this, HTML is the wrong tool for
the job you are trying to do. Write a real desktop application for god's
sake, in Swing for example. Not every problem can be solved by HTML!
Rob
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
