Hi,
OK, I did a count on the session.inc file and there appears to be 37
variables accessed through the $_SESSION object. By and large they all
appear to be scalar variables that contain a counter or a path or a boolean.
Nothing that looks like a big object. Mostly stuff like" MaxDisplayRecords,
DefaultDisplayRecords, Theme, DefaultTheme, CustomerId, RealName,
CustomerBranch, Module, UserStockLocation, PageSize, AccessLevel,
AttemptsCounter, Language, PageSecurityToken, DatabaseName...etc.
Initially, when you hit the index page the session.inc file is included.
>From there, depending on what choices you make from the options displayed it
assembles a page by calling the a php file that calls the database if
needed, includes a header.inc file and a footer.inc file and builds the
appropriate html for the body and of course, includes the session.inc file.
My question is, assuming 37 variables of this type in the
session.inc file, at what level of concurrent user access do you consider
changing the way you do business here. Bare in mind that I don't comprehend
a whole lot about server and database clustering and big enterprise big iron
stuff like that. I'm just a guy trying to learn how to write decent php
code that I don't have to be embarassed of when I shift gears in a new
direction to add a marketable skill in my career development path.
Thanks,
Mark
"Paul M Foster" <paulf@xxxxxxxxxxxxxxxxx> wrote in message
news:20090709010528.GX14822@xxxxxxxxxxxxxxxxxxxx
> On Wed, Jul 08, 2009 at 06:55:24PM -0500, Shawn McKenzie wrote:
>
>> D.M.Jackson wrote:
>> > Thanks guys. I was just wondering if it was common practice to pass
>> > all
>> > those variables in the SESSION object or if I was following a bad
>> > example
>> > because it was the first time that I had seen so many variables passed
>> > this
>> > way. If this is the typical way of handling this in php then I don't
>> have a
>> > problem with it, I just wanted to make sure that I wasn't getting off
>> > to a
>> > bad start and picking up bad habits while learning php.
>> >
>> > Thanks,
>> > Mark
>>
>> Again, it depends upon whether you "need" those variables in the next
>> page for example. Think of a wizard, where you fill some values in a
>> form, click next, fill more values, click next, etc and then click
>> finish. You may want to pass the values from each page to the next via
>> the session and ultimately have them all available in the last page.
>> There are others ways to do this, such as adding them as hidden inputs
>> in the next pages, but I personally would use sessions.
>>
>> One other example might be user info, id, username, firstname, lastname,
>> current access role etc. You may use these on every page, so once you
>> retrieve them from the db, you can store them in the session. Any other
>> info like email, age, register date whatever, you can retrieve only when
>> needed.
>
> Just to provide a counterpoint to this, I would discourage using
> $_SESSION for more than absolutely necessary. If I have a situation such
> as Shawn mentions above, I pass values via hidden fields in the form.
> Most of the forms I create are backed by a database, so mostly I capture
> data from there. In addition, you can serialize data you wish to save
> and store it in a database or hidden field, and then unserialize it upon
> painting the next page.
>
> If I'm not mistaken, there's a limit to the data which can be stored in
> a session variable. I don't want to mistakenly hit that limit and wonder
> what happened. And besides, I just think $_SESSION should be reserved
> for *special* cases.
>
> And, as mentioned before, it's worthwhile asking yourself if you
> *really* need to remember a bunch of information from page to page. The
> need to do so may well be a result of lazy programming habits.
>
> Paul
>
> --
> Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
