Re: counts the number of hit on a website containing many JSPs
Jean-Baptiste Nizet wrote:
Oh come on! Sorry, but you need to read more on MVC in the context of
web apps. An application that doesn't use HTML correctly, tries to
Oh, yes, I need to do that. I've written over a dozen of these apps,
and read much on it. I hold my knowledge up against any standard you
like on this matter.
Just because I disagree with you doesn't mean that I'm ill read.
simulate hyperlinks with buttons, and makes your webapp look like a
Swing app IS what can be called as a bad web application. Hyperlinks are
"can be called" - sure, you can call anything anything. But it isn't
a bad web application, because using POST instead of links has
advantages, specific to web apps.
And you guys keep talking about "having a desktop [or Swing]
mentality" like that is some sort of criticism. How is that a bad
thing, and how is what I'm doing that?
And even more important, just what do you mean by "a desktop
'mentality'"?
what makes the web, and not using them is a very bad idea. Hyperlinks
may have parameters. Hyperlinks are part of any well-designed MVC
Not for internal links, no they are not.
application which, to the user, should most of the time behave like any
web site: be able to have links, to open in new tabs or windows, to
bookmark pages and to send URLs to friends.
Not if you want to restrict those URLs, and control the application
experience. Doing those things can be undesirable.
Using hyperlinks doesn't mean that all requests don't go through the
central point of access. I completely agree with Shakah: you're
bringing a desktop application mentality to web-based app design.
There's that "mentality" word. How about defining what you mean by
that?
POSTs, as are commonly done internally in good web apps instead of
hyperlinks, allow the tramsmission of data also. They avoid a round-
trip to the browser to forward to the next page, on account of
forwards are server side, unlike links. The POST technique allows
precise control of application state, and keeps the user from entering
screens for which the preconditions have not been met. There is
nothing in that design approach that precludes links to well-defined
screens, but such links will always lack the sort of contextual
information for which the OP was asking (distinguish internal
navigation from external).
If these benefits constitute a "desktop application mentality" then
that must be a good thing.
--
Lew