On Nov 28, 2007, at 12:07 PM, Stut wrote:
Jason Pruim wrote:
On Nov 27, 2007, at 6:01 PM, Stut wrote:
Jason Pruim wrote:
Just for my own curiosity, why do you think sessions are evil? I
haven't found a better way to store my variables between
different pages... Other then always posting them in either
$_POST or $_GET each time... But that can add up quite a bit on a
complicated site though...
Sessions in the way that most PHP developers think about them are
an enemy of horizontal scalability, but if slightly alter the way
you think about how your app works you can effectively remove the
need for this type of session.
Think about how much info you need to store between page requests
that isn't already available to you some other way, in a database
for example. Now consider that if your app needs to scale then
chances are you'll end up with your session storage in a database.
What do you gain by extracting that data from it's natural home in
the database and putting it into another location in the database
for the duration of a users visit?
One of the things I have in a session variable, is a search
function through the database, and then an export to excel option.
Would I be better to store that in a cookie rather then a session
variable?
Not sure what you mean by this. If you mean the results of a search
then unless your search query takes longer than your average user
will wait then you really need to optimise your search system.
Duplicating the results into a session is extremely inefficient.
However, if you mean something else could you explain it so an idiot
(that's me) can understand it.
The search results arn't stored in a session, just the search variable
(IE: What they searched for) It was the only way I could get it to
export the search results to my excel file... It may be because I have
everything in separate files that I'm running into issues...(The main
page is a separate file, as well as the edit, add, export, & search
pages) I think I need to understand more about programming basics to
figure out how to put it all in 1 file and have it work...
The one thing you do need to transfer from request to request is
something to identify the logged in user. This is done in the same
way sessions pass their identifier, in a cookie or in the URL. The
only difference is that you need to encrypt it to make it a bit
harder to fake. I generally include a timestamp in the encrypted
cookie so I can impose a hard limit on the lifetime of a session.
Normal rules for good encryption apply here, but bear in mind that
every single request will need to decrypt it, and potentially
encrypt it too so don't go overboard.
Of course it's possible that the app you're working on will never
need to scale beyond one machine, but I have been involved in
scaling too many sites that weren't designed to do it to not plan
for the possibility in everything I do now.
Anyway, that's why I avoid using 'sessions' wherever possible -
IMHO there are better ways to achieve the same goal for most
applications.
I'll have to look more into cookies before I can comment much on
the rest of the e-mail which I shall start doing now I believe :)
Like I said it's possible you'll never need to scale beyond one
machine, or if you do maybe you're working for a company with pots
of spare cash. Having said that, IMHO being good at avoiding
sessions is a worthy skill to gain.
Definitely no pots of cash... Least not that I have found :)
But this is all good stuff for me to know... Especially when I go back
to school to learn how to be a true computer programmer instead of
just a hack who manages to put a few things together from code
examples and the amazingly helpful people on this list :)
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruim@xxxxxxxxxx
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
