Should a class directly reference $_SESSION?

[Daz]

Hi everyone. I'm just wondering if it's considered bad practice to
have a class read from and write to the $_SESSION super global. I was
just learning a little about object serialization, and I've come to
the conclusion that storing potentially large serialized objects in a
database is perhaps a bad idea. The data could also be stored in a
file, but in that case, I may as well use $_SESSION. If I'm going to
go down that road, why not store object states in the $_SESSION super
global?

I can see that this could cause problems with regards to ambiguous
names on larger projects, but will I be struck by lightening if I have
objects instantiate from the $_SESSION super global, and manipulate
is? Obviously, my object would check to see if there is a session
first, but $_SESSION can then be used by other classes and which can
do the same, and manipulate it also.

Also, perhaps security is an issue in the sense that variables could
be removed by other classes, which could lead to problems, but it's no
more dangerous than using $_GLOBALS IMHO.

What concerns me is that I've never actually heard of objects using
the $_SESSION super global like this which leads me to believe I might
be missing something.

I'd be interested to hear anyone's thoughts on the matter.

[Jerry Stuckle]

Daz wrote:

Hi everyone. I'm just wondering if it's considered bad practice to
have a class read from and write to the $_SESSION super global. I was
just learning a little about object serialization, and I've come to
the conclusion that storing potentially large serialized objects in a
database is perhaps a bad idea. The data could also be stored in a
file, but in that case, I may as well use $_SESSION. If I'm going to
go down that road, why not store object states in the $_SESSION super
global?

No, it's not necessarily bad for a class to use the $_SESSION
superglobal. But it's generally not a good idea to store any large
amount of data in the $_SESSION, a file or a database. It will slow
down the system and could take a lot of disk space. But it depends. If
the data comes from a database in the first place, I'll just store an ID
and refetch the data. It has the additional advantage of getting fresh
data (in case it was changed by someone else).

I can see that this could cause problems with regards to ambiguous
names on larger projects, but will I be struck by lightening if I have
objects instantiate from the $_SESSION super global, and manipulate
is? Obviously, my object would check to see if there is a session
first, but $_SESSION can then be used by other classes and which can
do the same, and manipulate it also.

When I do use the $_SESSION variable from a class, I normally prefix the
data with the class name. Multiple values I use an array, i.e.
$_SESSION['class_myclass']['x'] = $x;

Also, perhaps security is an issue in the sense that variables could
be removed by other classes, which could lead to problems, but it's no
more dangerous than using $_GLOBALS IMHO.

That's why I use the classname as a prefix.

What concerns me is that I've never actually heard of objects using
the $_SESSION super global like this which leads me to believe I might
be missing something.

I'd be interested to hear anyone's thoughts on the matter.

Not at all. Not necessarily all that common - but that's because a lot
of people aren't using objects.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[The Hajj]

Interesting Topic/Post

I, just out of the blue last week decided to use the
$_SESSION['class_myclass']['x'] = $x; with an application I writing.
I feel $_SESSION is rather secure. Now I'm wondering how much data is
too much data? My problem is, information is going into the database
mostly rather than out. Issue I have with an old application(whi ch
this one is replacing) is null records and fields. I'm eliminating
that by a better designed database and storing filtered data in
$_SESSION. Users don't like to click "cancel". The only problem I can
think of that I'll run into is if a user decides to upload a file, but
I don't have that in design, either text or a point(url) to the data.

[gardnern]

On Jul 28, 4:46*pm, Daz <cutenfu...@gma il.comwrote:

Hi everyone. I'm just wondering if it's considered bad practice to
have a class read from and write to the $_SESSION super global. I was
just learning a little about object serialization, and I've come to
the conclusion that storing potentially large serialized objects in a
database is perhaps a bad idea. The data could also be stored in a
file, but in that case, I may as well use $_SESSION. If I'm going to
go down that road, why not store object states in the $_SESSION super
global?

I can see that this could cause problems with regards to ambiguous
names on larger projects, but will I be struck by lightening if I have
objects instantiate from the $_SESSION super global, and manipulate
is? Obviously, my object would check to see if there is a session
first, but $_SESSION can then be used by other classes and which can
do the same, and manipulate it also.

Also, perhaps security is an issue in the sense that variables could
be removed by other classes, which could lead to problems, but it's no
more dangerous than using $_GLOBALS IMHO.

What concerns me is that I've never actually heard of objects using
the $_SESSION super global like this which leads me to believe I might
be missing something.

I'd be interested to hear anyone's thoughts on the matter.

I would say it is bad practice to have your classes alter or read any
$_SESSION variables. Instead, its best to pass these variables to the
method/class, and then return them and have your controller assign
them to sessions or whatever else.

[C. (http://symcbean.blogspot.com/)]

On Jul 28, 10:46 pm, Daz <cutenfu...@gma il.comwrote:

Hi everyone. I'm just wondering if it's considered bad practice to
have a class read from and write to the $_SESSION super global. I was
just learning a little about object serialization, and I've come to
the conclusion that storing potentially large serialized objects in a
database is perhaps a bad idea. The data could also be stored in a
file, but in that case, I may as well use $_SESSION. If I'm going to
go down that road, why not store object states in the $_SESSION super
global?

I can see that this could cause problems with regards to ambiguous
names on larger projects, but will I be struck by lightening if I have
objects instantiate from the $_SESSION super global, and manipulate
is? Obviously, my object would check to see if there is a session
first, but $_SESSION can then be used by other classes and which can
do the same, and manipulate it also.

Also, perhaps security is an issue in the sense that variables could
be removed by other classes, which could lead to problems, but it's no
more dangerous than using $_GLOBALS IMHO.

What concerns me is that I've never actually heard of objects using
the $_SESSION super global like this which leads me to believe I might
be missing something.

I'd be interested to hear anyone's thoughts on the matter.

It sort of depends on your version of 'large', and whether you really
need all the data/objects for every page invocation.

One caveat is to think about what will happen if the user opens a
second (or third or...) window using the same session but trying to
interact with a different subset of data.

C.