$session->set($name, $value) - When to use?

[GuruMeditation]

Hello, I've searched the forums and API page etc, but I've not really found a great deal of information regarding $session->hello = "Hello World!"; etc. I know what it does, but I don't know the technicalities of it. By this I mean, is it safe to temporarily store a couple of paragraphs of text in a session variable while a page is redirected for example?

e.g

$session->quotedText = "A couple of paragraphs of text would go here.....";
$session->redirect($someUrl);
// Get the stored text from the new page
$value = $session->$quotedText;
Echo "Quoted text from the previous page... " . $value;

I can't see anything wrong with this idea, but I'm probably missing something as I can't seem to find many uses of it?

Is this an improper use for session variables?

Thanks.

[MindFull]

Short answer: do what your site/application requires and whatever is within the limit of your server's resources.

My 2 cents:

One question I always ask myself when dealing with session data is whether or not I want that data to reflect the same exact information that I saw while visiting the page the next time I visit. If I revisit the page after I log out, close the browser, or hit the back button, what should that data look like?  Typically, if (other) users, applications, functions, methods, etc. need to modify this data, then a session variable is out of the question for me. But if I want this data to be the same after I enter it, (ie: shopping cart information that I have added a shirt to when at work that I want to review when I get home) then that information might be alright for me to use in a session.

Nonetheless, I still prefer to store only enough information concerning the session.  I usually reserve session variables to hold information (user name, id, department, specific date of something important - maybe sale end date, shirt item number, etc) directly related to the user, application, or page that is being served.  Then, based on those parameters, I make Processwire fetch the needed page(s) information (cost of the shirt, quantity remaining, etc) because these things are subject to change.  

[GuruMeditation]

Thanks for that.

One of the scenarios I have is to allow my users to quickly edit some content from the front end. There will be an edit button on the page for a piece of content they can edit, and then when clicked I'll use Fancybox to pop up the content from the item. So I was planning to use a session variable to temporary store that content, and then when they have cancelled or updated the content, the session variable will be cleared.

I'd also use it to allow my users to quote text for the custom comments system I have in place. So again there would be a quote button, and that content would be stored in a session variable to be used in a textarea etc. It would then be cleared when the task is complete.

So would this be a yay or nay? It just seems a straight forward and clean method to use, but I don't want to misuse it if it's not meant for things like that.

Thanks.

[teppo]

For your first scenario I can't quite see what the big benefit of session would be, though that depends on the structure of your page and the way you build this thing in the first place. Some possible solutions I'd consider:

• If the edit view opened in modal box is an external page (not part of this page or put together on the fly) then you'll have to somehow let it know what it is that you want to edit.. and in that case I'd rather provide it with page ID and field ID (or name) as GET params.
• If the edit view is generated and filled out on the fly (and submitted by AJAX, I'd assume) you can just grab the content from page using JS without the need to store anything in session variables.

In your second scenario I'd also consider using GET params (specify comment ID to quote from) or storing either the comment ID or even the whole quoted text (unless you really need to support storing *a lot* of data) in JS cookie. This is an example of situation where you probably don't need to make sure that quoted text is somehow protected (in most cases user can edit it upon posting anyway), so storing that data in session provides very little extra value.

--

Considering sessions vs. other methods of storing run-time data in general:

Biggest reason I tend to avoid sessions is that as the amount of data stored in session grows in size, so do the memory requirements (and, in extreme cases, also the disk space requirements) of your site. At least some PHP versions load whole session data to memory when session is started, so you can imagine what having tens of kilobytes, hundreds of kilobytes or even megabytes of data (a worst case scenario, but still) does on a site with a lot of simultaneous users.

With sessions you'll also want to make sure that you're cleaning stored session files properly (which, by the way, isn't always as trivial as it may sound) and preferably clearing stored values run-time too, especially if you're storing a lot of content. GET params, on the other hand, don't consume any extra memory.. and storing stuff in JS cookies only consumes client resources.

As for why one would prefer to use sessions, biggest benefits are that a) session variables make it possible to "hide" the mechanism behind this all from the user and b) session data is much harder (practically impossible, unless you've made it possible yourself) to tamper with (it's easy to try out different values for GET params or alter data stored in JS cookies).

Ease of use is a very real benefit too, of course. Storing data in session variables is often the least painful route.

Tradeoffs, tradeoffs.. but then again, isn't that what web / software development is always about?

[GuruMeditation]

Hi Teppo,

Thanks for the easy to understand explanation. I now know that session variables probably aren't the way forward. A lot of the time I over think things, and make life a lot harder for myself. But in the docs, session variables seem tempting.

I think I'll have a look into JQuery and see if I can use GET as you suggested.

Thanks again.