While this sounds fine in theory (and is actually an approach I use
from time to time), it has some practical problems that mean I'm hesitant to
go down this road in large apps. The biggest is that relying on the server
to store lots of state information (a backing descriptor for every rendered
link on a form) gobbles memory on the server. For small to mid sized apps,
this is probably moot, but for really big apps, per-client memory footprint
is a very big deal.
If you think about it the client is a great big block of "free"
memory that you really need to use efficiently if you want your app to
scale. Want to put up a list of 100 airline tickets with a "buy now" link
next to each one? You can A) Store 100 ticket IDs in a server side map in
the session and then put map keys out on the links or B) store the actual
IDs (or some encrypted variant thereof) in the outbound links themselves.
Option B saves you a minimum of 3.6k of sever side memory per screen (100
links * (32 bit guid + 4 bit integer map key + map overhead) and that's
*huge* in my book.
The other advantage of using the client this way, of course, is that
it guarantees perfect session management. You'll never be carrying around
data in the session that references back to a page the user has long since
thrown away. Conversely, you'll never expire the backing map of a page only
to have the user press back three times and select a different ticket only
to get a stale link.
--- Pat
> No, You save the user's ID in the session (ASO). just an Integer,
> does'nt take much place.
> Then you link to showProfile - which takes the id of the user from the
> session and *never* from the GET/POST.
> When editting any resource which has an owner, owner verification should
> rely on server/session state only, and not on GET/POST variables.
> What you do here is duplicating the session integration of the servlet
> specification. It already has an implementation (cookie or URL based)
> for just what you do - its called session - so why not use it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
