Added new handler metadata property cacheIncludeRcKeys#503
Conversation
This new metadata option gives developers more control over which RC scope variables are considered when generating the cachekey
|
This pull request has been mentioned on Ortus Solutions Community. There might be relevant details there: https://community.ortussolutions.com/t/coldbox-6-4-event-caching-and-ignoring-rc-scope/8886/11 |
|
@lmajano Let me know if you have any questions or need anything else from me? I'm curious to hear your feedback on the PR and tests. |
|
This also relates to https://ortussolutions.atlassian.net/browse/COLDBOX-1203 @lmajano I would recommend merging this one in and then we can address 1203 |
|
@homestar9 I am so sorry we never looked at this, if it's worth doing again, can we start again the convo on it. I apologize, I totally missed it. |
|
@lmajano thank you for following up. Yes, my PR would add significant value for ColdBox and also boost performance. Having the ability to use the new What are the next steps? I believe the PR should still be valid. |
This pull request is in response to this discussion in the Coldbox community.
This new feature for Coldbox gives developers more flexibility with event caching and different RC scopes. The end result should be more efficient caching and improved page load speed for many users.
The Problem:
Currently, event caching considers the entire
RCscope when generating a cache key. This means that changing any URL or FORM variable on a request will force Coldbox to generate a new cache entry. This behavior is problematic for a few reasons:utm_source). In this type of scenario, there is no need to create a new cached event for every unique URL.The Solution
I was inspired by Wirebox's populator include/exclude arguments which lets developers specify a list of keys to consider when populating an entity. My idea was to create a new metadata property called
cacheIncludeRcKeyswhich would allow specifying a list ofRCkeys to include when generating a cache key. All keys not in the list are ignored. To maintain backward compatibility, the default value forcacheIncludeRcKeysis*which considers all keys.How Does it Work?
Simply include a new metadata attribute
cacheIncludeRcKeysto a handler and specify a list ofRCkeys you want to be included in the cache key generation process. Here are some examples:The above code will ignore all
RCkeys except forslugwhen generating a cache key. So, if you had a routepages/:slugresolve topages.show, the following URLs would all utilize the same cache key:https://mysite.com/pages/foo
https://mysite.com/pages/foo?utm_source=google
https://mysite.com/pages/foo?utm_source=bing
You can also include multiple
RCkeys by specifying a list in the metadata attribute like this:@lmajano I know you are probably busy with preparations for Into The Box so no need to rush on this one. I'll be attending the conference in person if you would like to chat about this PR. Looking forward to catching up with you and the entire Ortus team. :)