Slightly better caching

[eluser]KJSDFHASD78FASDF78SA[/eluser]
I have extended the Output class to serve multiple versions of the same page to different types of users.

The problem: You need to cache a page, but it is not possible, because it differs for logged-in users and guests.

The solution: If we store information about the user in $_SESSION array, we may well cache the page, substituting the the user specific output such as name, number of unread messages, etc. with some tokens. Then, when we serve the cached page to the user, we substitute these tokens with values from the $_SESSION array.

The implementation: Download the class and move it into the application/libraries directory. Now you need to add two configuration options to your application/config/config.php file:

Code:

/*
|--------------------------------------------------------------------------
| Cache page type source
|--------------------------------------------------------------------------
*/
$config['cache_type_source'] = array(':user:','type');

/*
|--------------------------------------------------------------------------
| Cache data source
|--------------------------------------------------------------------------
*/
$config['cache_data_source'] = array(':user:');

The first one determines where to find the user type in the $_SESSION. In this example $_SESSION[':user:']['type'] will be used for that purpose.

The second one determines where to find all user specific data in the $_SESSION. When outputting the cached file the script will use the $_SESSION[':user:'] all key => value pairs to substitute all {cached::key} tokens with values.

Now change your application so that all user data is stored in the $_SESSION (for instance, use PHP native session implementations from the wiki). Whenever you want to output this data inside your views, use tokens instead. For instance (very crude example):

Code:

<?php if ( isset($SESSION[:user:]) ): ?>
    Hi {cached::name}. You are logged in as {cached::type}.
<?php else: ?>
    You are not logged in.
<?php endif ?>

[eluser]louis w[/eluser]
I like this idea a lot.

Wouldn't this cache the page the same for each user thou?
UPDATE: Nevermind, I did not fully understand your token idea at first. This def looks cool.

Have you run any performance tests comparing the extra processing this requires for the str_replace?

[eluser]Xperia[/eluser]
I was just thinking of a way to cache a page for different users...
And find the solution here.. great , thanks a lot.

[eluser]KJSDFHASD78FASDF78SA[/eluser]
[quote author="louis w" date="1206643683"]Have you run any performance tests comparing the extra processing this requires for the str_replace?[/quote]

No, I didn't. I needed something simpler than Sparks library, which I can drop into my app without rewriting it. The performance did increase and that's all I need to know ;-)

While we are on the subject of performance, I think replacing the str_replace loop with a single str_replace (by passing an array of tokens and an array of values) will yield better performance, but that's only in theory.

I am currently working on my own cache library, that will store real php code instead of tokens, but I can't say when it will be ready...

[eluser]Wilker[/eluser]
it's cool

but i recomend to you to use cookies instead of sessions because cookies is too much faster.

and be carefull with this... because imagine you have a system with a lot a users (let's mind 10000 users), and has a big page to cache (40kb of total code generated), this means you will have 10000 x 40kb = 400.000kb (400mb) of cached files... and it's only for one page... when the system grows this space will increase to much... sometimes is better to save process and use hard drive, but not ever... you need to mind if this is really saving resources or not.

take this as a construtive critic

[eluser]KJSDFHASD78FASDF78SA[/eluser]
[quote author="Wilker" date="1206721370"]and be carefull with this... because imagine you have a system with a lot a users (let's mind 10000 users), and has a big page to cache (40kb of total code generated), this means you will have 10000 x 40kb = 400.000kb (400mb) of cached files... and it's only for one page... when the system grows this space will increase to much... sometimes is better to save process and use hard drive, but not ever... you need to mind if this is really saving resources or not.[/quote]

You actually missed the only point of this library. ;-) One page is cached for ALL users. Than user specific data is inserted into the cached page, without making a call to the controller. In most systems 2 copies of the page are saved: (1) for guests and (2) for authenticated users.

[eluser]Wilker[/eluser]
humm, nice, sorry i didn't looked at this, good job

[eluser]beemr[/eluser]
I found a suffix caching system elsewhere in these here forums, and I think it's a good complement to Chromice's addition. I've uploaded a version to the wiki at Suffix cache.

Since I like to use global login forms, I made a couple of other additions that keep the cache clean of singletons like flashdata and form validation. You can find them in the wiki at No Flash Cache and Clear Cache by POST.

Anybody else out there using global login forms and encountering cache problems?

If so, how did you avoid them?

[eluser]beemr[/eluser]
I'm also sending flashdata to cached pages other than the form origination page, so I added Clear Page Cache.

You can use it to pick off the page's cache before redirecting to it.