Caching dynamicly created HTML after login

[eluser]nZac[/eluser]
Caching to me has always been a mystery and I really don't understand it fully. I will attempt to explain my problem and see what suggestions I can get.

Previously
I have multiple sidebars on my site of which are used for different levels of security. Before now I had a simple function that would call the files based on a security INT that I saved in a session variable. it looked something like this:

Code:

$security = $_SESSION['security'];
$sidebar = "";

for($i = 0; $i < $security; $i++)
{
//The sidebars where named 1.php 2.php ect ect
$sidebar .=file_get_contents('path/to/sidebars'.$i . '.php');
}

return $sidebar;

It worked great because all the sidebars had a heirachy and based on your access level you got special privileges and the sidebars stacked nicely on each other. Until I needed special sidebars for special users that had special privileges. I had no real way of pulling special sidebars based on INT's because they where not incremental and calling this function hurt performance.

Future
I now intend of creating a new table in my database called 'access' or something like that and it will store the user ID and a sidebar number. Your security level will dictate page access and your sidebar access will be based on database entries. I will generate the sidebar based on these values and make it all fit together nicely.

This sidebar never changes after log-in, so what I want to do is cache the sidebar after its creation when the user log's in and just display it any time.

How would I go about caching JUST the sidebar HTML (it is all P,UL,LI and H tags)?

Anyone see any potential flaws with this method performance wise or for any other reason? I am all about doing stuff the right way so I am open to any suggestions. Please share, this is the only thing I am hung up on (for now)!

Cheers,
Nick

[eluser]jedd[/eluser]
I don't agree with your premise, but if I were going to head down this path I think it would be fairly straightforward.

Rendering your view(s) into a variable, saving the contents of that variable into a file, and then on loads a simple test for the presence of that file - you could get sophisticated here and check the staleness of the file before deciding whether to load it or regenerate it.

[eluser]nZac[/eluser]
[quote author="jedd" date="1257826285"]I don't agree with your premise, but if I were going to head down this path I think it would be fairly straightforward.

Rendering your view(s) into a variable, saving the contents of that variable into a file, and then on loads a simple test for the presence of that file - you could get sophisticated here and check the staleness of the file before deciding whether to load it or regenerate it.[/quote]

@Jed,

why don't you agree with the premise? Essentially, if this is not a good idea what would be a better solution?

[eluser]jedd[/eluser]
[quote author="nZac" date="1257828839"]
@Jed,

why don't you agree with the premise? Essentially, if this is not a good idea what would be a better solution?
[/quote]

Let's see ...

You state you're unfamiliar with caching, and yet you'd rather implement your own caching code than rely on the several layers of cache already provided by the system.

But bigger than this, you're attempting to solve a problem you don't have. Arguably that could be appended with '...yet.' - but the distinction is pretty subtle - you're going to optimise something that is an unknown (but likely trivial) burden. In doing so you'll introduce some complexity that might be non-intuitive to the next person (or you, six months from now).

A better solution? I'm very keen on the cunctatious approach to these kinds of ersatz problems.

[eluser]Phil Sturgeon[/eluser]
Have a look at my cache library for some EASY caching. Why not just add in a view() method as a new feature? It would do exactly what you want, and you can already see how it should be done based on the model() & libraries().

[eluser]nZac[/eluser]
Phil,

Thanks for the suggestion, I will look into it tonight!