--- Rick Reumann <[EMAIL PROTECTED]> wrote:
<snip>
> The thing to realize here is time is money. Does you company want to
> spend a ton money creating code that is a pain to maintain? I'll bet
> you
> in the long run, it's cheaper to add more RAM than it would be to
> maintain various solutions simply to avoid using the Session. I like
> web
> applications to be easy to code and maintain. And don't just think of
>
> the now, think of the developers that have to be on the project 6
> months
> from now when requirements change.
>
> Some of the approaches that are often described to avoid using the
> Session simply do not make sense to me when you weigh out the
> maintenance costs. Invariably non-Session using solutions involve
> persisting a bunch of hidden variables. This just gets really messy
> from
> my experience especially later on when people inherit the code and
> aren't positive if they no longer need X hidden variable so they just
>
> leave it and then that code gets maybe copied to some other part of
> the
> application. Things just get ugly over time. Again, I don't use the
> Session when I do not need to, but if I need to maintain state across
>
> multiple requests, I use it, and don't feel bad about it....
those are very good points. from a cost point-of-view it is definitely
cheaper to buy hardware than to face potentially higher code
maintenance costs in the long run.
how do you handle browser back button issues? (the bane of all web
developers who use session objects)
>
> "Hi my name is Rick and I use the Session to store objects."
>
> "Hi Rick!"
>
> <SUA - Session Users Anonymous - meeting/>
lol!
"hi! my name is woodchuck and load the entire database into the
session!"
haha ;)
woodchuck
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
