Re: counts the number of hit on a website containing many JSPs
Jean-Baptiste Nizet wrote:
The web has its rules and idioms, and web design is not the same as
rich application design. Webapps are usually more open, indexable,
bookmarkable, linkable. If you do everything with POSTs, good luck
with that. And go explain your customer that your webapp apears at the
56784th position when doing a Google search, because Google is not
able to index your web app and nobody links to it.
Right, like the web couldn't see the app just because it controls its
internal navigation. Every hit to that site is still a hit to that
site, just not necessarily to certain pages within it.
As I stated upthread, there is nothing in what I suggest to preclude
opening up certain URLs in the app to direct access. Your argument
here does not refute what I suggested.
HTTP is a standard as well, and GETs are supposed to be used for
requests that don't modify the server state (navigate to a page,
consult items in a repository, search, etc.). POSTs are supposed to be
used to modify state, and not for everything else. You choose not to
respect the standard and that's your right, but it's also the sign of
Huh? Who says the POSTs I suggest do not affect program state? In
general, they likely do.
bad design (as IE has always be considered as a bad browser by techies
because it doesn't respect the HTML and CSS standards, which doesn't
mean it doesn't work or do something useful).
Not related to my points.
Maybe you should teach Google, Ebay, Amazon, Slashdot, Yahoo and so on
how to design webapps, because I see many many hyperlinks in their
apps. And they're pretty successful.
Maybe you should teach Sun and others who do what I suggest, and teach
what I suggest, how to redesign their sites not to use the principles
I describe. They're pretty successful, too.
It can be undesirable. Most of the time, it IS desirable. That's what
"Most" of the time? How are you deriving that statistic?
users expect from web apps. Would you like it if Ebay, Google or Yahoo
didn't let you open several tabs in their webapp?
Nothing I suggest prevents opening tabs in the web app.
How would a GET need additional round-trip to the server just to go to
another internal page or search through a repository? How are your
You're right here.
users supposed to refresh a page or use their back button when using
your POST-only webapp. Oh, they are not supposed to do that? So your
Huh? None of the apps I've written or seen that follow the pattern I
suggest have trouble with back button or refresh. I don't get your
argument here.
Of course they're supposed to use those controls. I would never stop
them.
webapp doesn't work well with the most-used browser buttons? That's
what I call a bad webapp.
If you were right I would agree with you, but you're wrong. Web apps
that follow what I suggest have no trouble at all with those buttons.
Plpppt.
How so? A POST carries information to the server just as a GET does
it: through request parameters. They're just not visible in the
Actually, I was wrong to limit it to POST. It's sessions that hold
that information.
Preconditions must be verified by your server-
side code. HTTP is stateless, and a POST request is not more difficult
to do than a GET for any script kiddie. Whether your action is being
called through a GET or through a POST, you have to check your
preconditions, because a good webapp *always* checks what comes from
the browser.
Right again.
No. You may add a parameter to a hyperlink just as you add a parameter
to your POST request. Doing everything by POST just makes it much more
difficult to link to your webapp from the outside. That's what I call
Nonsense.
"desktop application mentality". The web is about hyperlinks between
pages around the world. Your webapp will tend to be an insulated
island in the web, that nobody can link to. Just as if your
application was a desktop app.
Nonsense. Nothing in what I suggest blocks the outside world from
linking to the app. Bogus argument.
--
Lew