Does cache key includes GET parameters in Revo?

Hi all,
it seems to me that the caching scheme does not account for GET parameters, but only URLs (resource ids?), is this correct?

Quote from: MadMage at Aug 20, 2010, 08:58 AM

Hi all,
it seems to me that the caching scheme does not account for GET parameters, but only URLs (resource ids?), is this correct?

BUMP

This may provide you with more information: http://rtfm.modx.com//display/revolution20/Caching

As far as $_GET goes, why would you need it cached. Once you have it you can do what you want server-side, such as $_SESSION vars etc.

In many instances it is much smarter / faster to let apache handle the get query string and modx catch the final result of that processing.

Quote from: wshawn at Aug 28, 2010, 08:09 PM

This may provide you with more information: http://rtfm.modx.com//display/revolution20/Caching

As far as $_GET goes, why would you need it cached. Once you have it you can do what you want server-side, such as $_SESSION vars etc.

In many instances it is much smarter / faster to let apache handle the get query string and modx catch the final result of that processing.

I think that the usual caching scheme of a browser is to use the whole request URL for caching purposes. One of the old-days trick to avoid caching, for example, was to add a dummy random GET variable at the end of the URL request (this was to be sure also with browsers that do not behave properly with caching meta tags and request headers).

If you ask twice for a page with the same GET parameters, it is higly probable that you want the same result. Aren’t you actually doing this when asking twice the same resource in MODx? You are requesting the same page (index.php) using a different GET query variable (q=...).

I’m not sure I understood your last sentence. What do you mean with "let apache handle the get query string"?

This is the purpose of partial resource caching. You cache the parts of the resource that is the same on every request, and any dynamic portions are called uncached so they can make use of any $_REQUEST variables. You can also add custom caching for individual snippets now using $modx->cacheManager; see getPage for an example of how this snippet can cache data for paged result sets using the modCacheManager API. Another possibility is to create a derivative class of modRequest and override the getResource() method to automatically cache like requests, though if user/session data was also involved, the GET or POST variables might not be unique enough to do this kind of caching and handling it in the snippets themselves would be more practical.

Quote from: OpenGeek at Aug 30, 2010, 02:47 PM

This is the purpose of partial resource caching. You cache the parts of the resource that is the same on every request, and any dynamic portions are called uncached so they can make use of any $_REQUEST variables.

Do you mean to cache the resource and then call the snippets with the "!" before the name? Ok, this can be a solution, but, again, I need to process over and over the same GET request in the non-cached snippets.

Quote from: OpenGeek at Aug 30, 2010, 02:47 PM

You can also add custom caching for individual snippets now using $modx->cacheManager; see getPage for an example of how this snippet can cache data for paged result sets using the modCacheManager API. Another possibility is to create a derivative class of modRequest and override the getResource() method to automatically cache like requests, though if user/session data was also involved, the GET or POST variables might not be unique enough to do this kind of caching and handling it in the snippets themselves would be more practical.

The custom caching seems to be a good solution. However, I wonder how many times MODx developers need this solution and if it is not easier for all of us to use the whole http GET request URL as a key for caching, as browsers and proxies are used to do. I mean: why do we need a different standard, it there is already one (de-facto) standard for caching keys?

Quote from: MadMage at Aug 31, 2010, 04:23 AM

The custom caching seems to be a good solution. However, I wonder how many times MODx developers need this solution and if it is not easier for all of us to use the whole http GET request URL as a key for caching, as browsers and proxies are used to do. I mean: why do we need a different standard, it there is already one (de-facto) standard for caching keys?

There is no de-facto standard. Again, if you have user/session-based customization, you need more than just GET parameters to form your identifying key. Plus, since you can combine many different Snippets on a single page, it does not make sense to put default caching at the page level this way, but maybe just my opinion. Just consider pages that might take different parameters for different Snippets; this is why the primary partial-page caching mechanism caches the output of individual Elements per Resource. The responsibility then should lie with the Elements themselves to provide further caching of the dynamic information they are presenting.