Searched hist:"791 e1550678744da5dbeb2c759336aa863a05a88" (Results 1 – 3 of 3) sorted by relevance
| /plugin/include/syntax/ |
| H A D | include.php | 791e1550678744da5dbeb2c759336aa863a05a88 Fri Dec 10 00:22:35 UTC 2010 Michael Hamann <michael@content-space.de> Restructuring, first version of new cache handling
This commit replaces user dependent include keys by just one cache for
each page. This means the cache needs to be regenerated more often when
e.g. the edit permissions are different. As this is just a renderer
cache this shouldn't be a big problem. The main reason for this is that
the metadata won't be correctly updated when a different cache file is
used for every user.
In the metadata all include instructions are stored so when the cache is
checked the list of pages that actually should be included can be
reconstructed and then compared to the list of pages that has been
included when the page/metadata has been rendered.
The order of the includes and the respective parent pages are taken into
consideration so something like the inclusion of two user-dependent
pages that include each other won't break this cache handling. I'm not
sure if all scenarios are handled by this cache correctly, but I
can't think of a scenario where the page should be rendered but
neither the order nor the parent id nor one of the included pages has
been changed. When one included page is replaced by another one because
of these placeholders all sub-includes of that page will still be
checked but as then the cache will be purged anyway this doesn't matter.
I've decided against just storing one level of include instructions in
the metadata of every page and for storing everything in the root as
reading a lot of files should imho be avoided. The metadata that is read
might be outdated, but outdated metadata can only be a result of a
change in one of the included pages which is handled by the
file dependencies.
|
| /plugin/include/ |
| H A D | action.php | 791e1550678744da5dbeb2c759336aa863a05a88 Fri Dec 10 00:22:35 UTC 2010 Michael Hamann <michael@content-space.de> Restructuring, first version of new cache handling
This commit replaces user dependent include keys by just one cache for
each page. This means the cache needs to be regenerated more often when
e.g. the edit permissions are different. As this is just a renderer
cache this shouldn't be a big problem. The main reason for this is that
the metadata won't be correctly updated when a different cache file is
used for every user.
In the metadata all include instructions are stored so when the cache is
checked the list of pages that actually should be included can be
reconstructed and then compared to the list of pages that has been
included when the page/metadata has been rendered.
The order of the includes and the respective parent pages are taken into
consideration so something like the inclusion of two user-dependent
pages that include each other won't break this cache handling. I'm not
sure if all scenarios are handled by this cache correctly, but I
can't think of a scenario where the page should be rendered but
neither the order nor the parent id nor one of the included pages has
been changed. When one included page is replaced by another one because
of these placeholders all sub-includes of that page will still be
checked but as then the cache will be purged anyway this doesn't matter.
I've decided against just storing one level of include instructions in
the metadata of every page and for storing everything in the root as
reading a lot of files should imho be avoided. The metadata that is read
might be outdated, but outdated metadata can only be a result of a
change in one of the included pages which is handled by the
file dependencies.
|
| H A D | helper.php | 791e1550678744da5dbeb2c759336aa863a05a88 Fri Dec 10 00:22:35 UTC 2010 Michael Hamann <michael@content-space.de> Restructuring, first version of new cache handling
This commit replaces user dependent include keys by just one cache for
each page. This means the cache needs to be regenerated more often when
e.g. the edit permissions are different. As this is just a renderer
cache this shouldn't be a big problem. The main reason for this is that
the metadata won't be correctly updated when a different cache file is
used for every user.
In the metadata all include instructions are stored so when the cache is
checked the list of pages that actually should be included can be
reconstructed and then compared to the list of pages that has been
included when the page/metadata has been rendered.
The order of the includes and the respective parent pages are taken into
consideration so something like the inclusion of two user-dependent
pages that include each other won't break this cache handling. I'm not
sure if all scenarios are handled by this cache correctly, but I
can't think of a scenario where the page should be rendered but
neither the order nor the parent id nor one of the included pages has
been changed. When one included page is replaced by another one because
of these placeholders all sub-includes of that page will still be
checked but as then the cache will be purged anyway this doesn't matter.
I've decided against just storing one level of include instructions in
the metadata of every page and for storing everything in the root as
reading a lot of files should imho be avoided. The metadata that is read
might be outdated, but outdated metadata can only be a result of a
change in one of the included pages which is handled by the
file dependencies.
|