In my opinion that's kind of like saying that Access is evil because it
doesn't scale well. Pretty much anything can be "evil" if you use it without
understanding it.

Using hidden fields makes the code more complex and less easy to understand
and maintain. In many cases that's a price you have to pay. But if you're
developing a solution that you know will never be farmed (an intranet,
perhaps) then using the Session Object is quite Ok in my book.

The Session Object is not evil, ignorance is.

/Gunnar

Lior Amar <lior_amar@hotmail.com> skrev i
diskussionsgruppsmeddelandet:395b9935@news.devx.com...
> You're absolutely correct that the session object can be useful but my
> cousin recently had hemorrhoids and that got him out of an exam...useful

but
> the price is too high. I just mentioned it and specifically pointed out
> that this will be a problem if the system grows. On one machine it will
> work but I've had to many companies that come see me cause they're in deep
> trouble with the session object. A lot of programmers that come off

Client
> Server development are completely unaware of State Management for the web
> and fall into the trap of using the SESSION OBJECT. I am just pointing

out
> that it takes 10 seconds more to use hidden fields in a form. I

personally
> utilize the database for my state management but hidden fields in forms

will
> do the job better then any SESSION object.
>
> But you're right the session object will work perfectly on a one machine
> system that will never be expanded....it still doesn't change the fact

that
> it's evil.
>
> It's easier to learn good habits then unlearn bad habits!
>
>
> --
> Hope this Helps,
>
> Lee Amar
> CTO OSTNet OpenSource Technologies
> Advanced Computing Demands
> Advanced Gaming Breaks
> lior_amar@hotmail.com
>
> "Gunnar Syren" <gunnar.syren@datapoint.se> wrote in message
> news:395b5333@news.devx.com...
> > Lior,
> > Isn't this generalising things a bit? The KB article you point to refers

> to
> > "Web Farms".
> > This would be normal if you're in e-business, but there is nothing (as

far
> > as I could see)
> > in the original question that indicates that this is about e-business

(or
> > any other kind
> > of Web Farm).
> >
> > Session objects can be quite useful if you understand their limitations.
> >
> > /Gunnar
> >
> > Lior Amar <lior_amar@hotmail.com> skrev i
> > diskussionsgruppsmeddelandet:395a20ff$1@news.devx.com...
> > >
> > > OOh man...Session objects are evil...just have a parm that you pass

from
> > one
> > > form to another or be more advanced and have values stored in a

database
> > > that you check. This code will work no problem but Session objects

are
> > > evil. Assume your user logged in and should have access to that form

> but
> > he
> > > logged in on ServerA. He now clicks on a button on that form and goes

> to
> > > ServerC, will this code work? No because the client session info is

on
> > > ServerA. The only way this will work is if you have a load balancer

> that
> > > permits for "Sticky Sessions" (affinity) which in itself is EVIL.

> Take
> > a
> > > look at this little document, I mean even microsoft doesn't recommend

> > using
> > > the Session object.
> > >
> > > http://support.microsoft.com/support.../Q258/6/99.ASP
> > >
> > > Although once again Devins message is 100% correct cause it will

> work...I
> > > still though you might want a second opinion. Remeber, the Web

business
> > has
> > > proven that the dumbest ideas in the world can make money on the net

> which
> > > means a small program that was ment to only work on one machine can
> > > overnight need to be placed on a webfarm.
> > >
> > > Once again, SESSION = EVIL
> > >
> > > Just my two cents,
> > >
> > > --
> > > Hope this Helps,
> > >
> > > Lee Amar
> > > CTO OSTNet OpenSource Technologies
> > > Advanced Computing Demands
> > > Advanced Gaming Breaks
> > > lior_amar@hotmail.com
> > >
> > >
> > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote in message
> > > news:3953be1f$1@news.devx.com...
> > > > OK. The easiest way to do this is by setting a simple Session
> > > > Variable. From your login page, once you have determined that the
> > > > login is valid set something like:
> > > > Session("blnGoodUser") = True
> > > >
> > > > Then at the top of each page to be protected, check this flag, and
> > > > if it is not present, redirect the browser to the login page:
> > > >
> > > > If Not Session("blnGoodUser") Then
> > > > Response.Clear
> > > > Response.Redirect("login.asp")
> > > > Response.End
> > > > End If
> > > >
> > > > Hope This Helps!
> > > >
> > > > --
> > > >
> > > > -Devin
> > > > ______________________________________________
> > > > Get on your feet and do the Funky Alphonso!
> > > >
> > > >
> > > >
> > > > "portly" <portly@coolemail.com> wrote in message
> > > > news:3953aaec@news.devx.com...
> > > > >
> > > > > I want to have it so you must enter though another page to view
> > > > the new page.
> > > > >
> > > > > I have online forms that I want to keep from being directly
> > > > accessed. They
> > > > > must go throught a client login first.
> > > > >
> > > > >
> > > > > Portly
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Devin Knutson" <devin@_NOSPAM_webnw.com> wrote:
> > > > > >I'm not quite clear on you question. Do you want to block
> > > > > >everyone from viewing a specific page(es), or are you wanting
> > > > to
> > > > > >block a specific user(s) from viewing anything?
> > > > > >
> > > > > >--
> > > > > >
> > > > > > -Devin
> > > > > > ______________________________________________
> > > > > > Get on your feet and do the Funky Alphonso!
> > > > > >
> > > > > >
> > > > > >
> > > > > >"Portly" <portly@coolemail.com> wrote in message
> > > > > >news:3953a3f5$1@news.devx.com...
> > > > > >>
> > > > > >> Does anyone know to eliminate a user from accessing a page by
> > > > > >just putting
> > > > > >> in the address? I know that can be eliminated by script code
> > > > > >but how???
> > > > > >>
> > > > > >>
> > > > > >> thanks in advance
> > > > > >>
> > > > > >> Portly
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >

> >
> >

>
>