This PR begins migrating away from the CMS' JCacheStorage class chain to enable PSR-16 support. Changes thus far:
The joomla/cache 2.0 package is pulled in which is implementing the PSR-16 interface
A service provider is added which will return the appropriate adapter based on the local configuration
JCache has new methods and a class property to support injection and retrieval of these adapters
The get(), store(), and remove() methods of JCache now use the PSR-16 interface
Testing Instructions
Pending - Things may not work 100% as expected since as of this writing some methods hit the cache store in one way and some methods hit it in another way
Documentation Changes Required
The intent is to be able to deprecate and remove JCacheStorage in favor of the Framework cache package. Once this is in a merge ready state, documentation regarding the transition should be created.
TODO Items
JCache::getAll() needs to be converted (PSR-16 nor the Framework adapters specify a method similar to this, there is a getItems() interface method but it requires specifying all the keys of items to return)
JCache::clean() needs to be converted (this is essentially deleting a group of items, again it pretty much relies on the ability to get a bunch of items)
JCache::gc() needs to be converted (same issue with being able to fetch a bunch of items)
Locking/unlocking of items needs to be converted
Rewrite JCache tests to use the PSR-16 adapters instead of JCacheStorage
After re-evaluating, decided this isn't practical.
The core Joomla API requires features that are not in either caching PSR, including a group/tag system, predictable file names, and the ability to acquire a unique lock (this last piece though could potentially be moved out of the handlers and into the controllers and something like Symfony's new Lock component evaluated for use instead)
Even if the core API could depend only on the PSR definitions, the number of additional features required means that at best only a very small piece of the overall cache system could be PSR compliant and it's the piece that really doesn't matter much for us as it relates to interoperability
joomla-cms-bot
- 
brianteeman
- 
After re-evaluating, decided this isn't practical.