The attached patch segments the static cache in token_get_values() by language. This allows token to be language aware. Additionally, taking a hint from token in D7, the patch allows for the $options argument to ask for a token in a specific language. While it's left up to the token provider to respect that language, this at least opens the door to handle languages properly.
This patch is just a first run, and has only **very** light testing.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | token_options.patch | 4.78 KB | jose reyero |
| #1 | 854688_2010-07-16.patch | 6.88 KB | jmiccolis |
| token_segment_cache.patch | 2.18 KB | jmiccolis |
Comments
Comment #1
jmiccolis commentedWhile working with this patch a bit I realized that the $options argument that I was leveraging is quite misleading and should probably be removed. Because token keeps a cache of values between calls to `token_replace`, unless specifically asked to flush them, the options array is fundamentally flawed, the pretty much useless. If you do use it you must run `token_replace` with $flush = true or your options will almost certainly be ignored.
The attached patch disposes of $options, and replaces it with $language, and uses that value to segment the static cache.
Comment #2
dave reidYou can't change the API this late in the module's lifetime.
Comment #3
jmiccolis commentedOk, but what do you think about cache segmentation? The first patch leaves the function signature alone.
Comment #4
jmiccolis commentedThe initial patch doesn't change the API.
Comment #5
jose reyero commentedThis is a new patch based on Jeff's first version, but going a little further.
The main idea is to be able to use tokens with batch processing or to do something as simple as sending a message to a different user than the one logged in (subscriptions, notifications) we need the tokens not to depend on global variables, or at least that these dependencies can be overridden.
So what we do is passing around the $options array to be used instead of globals. This affects dates too, that should depend on the user the text is intended for, instead of any global variable.
As you can see this should be 100% backwards compatible with all the existing token_values hooks so we are not really changing the API, just extending it.
Comment #6
dave reid#5: token_options.patch queued for re-testing.
Comment #8
dave reidMost of these improvements with regards to caching tokens by $options were implemented via #1174472: Improve token generation and caching. The rest no longer applies to 6.x-1.x-dev.
Comment #9
bluegeek9 commented