Question: fragment caching about cachelite HOT 4 CLOSED

Great idea—fragment caching would make it much more powerful—I can't quite think of a simple way for it to work though. At the moment the extension intercepts the page request and either serves or caches the entire page.

For fragment caching to work we'd have to have some way of generating the fragments and then insert them into the cached page, but we obviously need to do that without generating the entire page again.

One solution might be to add a caching=true parameter into the page generation process and then use that to only generate the bits that change. That way we could pull them out and insert them into the whole cached page.

Do you have any other suggestions?

from cachelite.

Talking with Rowan he points out that most of the time in page generation is the XML build so the approach outlined above probably wouldn't save enough time to be useful :/

from cachelite.

Hrm yes, fair point. Of course, since at the point of rendering the page the DSs and XML have already been created and execute. Duh!

In which case the best option for fragment caching remains at the DS caching level. We're close to having something that can be pushed to Alistair as a core modification on this front, hopefully in the next 4–6 weeks.

On another note, I just realised I use this issue tracker as a soundboard/forum. Do you think it should be encouraged, to keep the forum cleaner? I wonder if the Extensions threads should remain as an "update" area, and the Issues on Github for bugs/suggestions etc?

from cachelite.

It's great that you're making some decent progress on the DS caching. I'll be really interested to see how it's implemented. The more speed the better :)

I think it's a good idea to have a canonical place for extension discussion. If the code is hosted on GitHub then the issues feature seems good way of keeping on top of requests, bugs, etc.

from cachelite.