> Right, but I thought you suggested that approach?
The approach I suggested didn’t require modifying any core files.
Regarding the ticket I asked you to put in-- that would obviously require core changes, but I would do it differently. I was imaging overriding the serializer for the whole provider as a config setting that would be passed into the provider and available to the store’s init(). I personally think choosing a serializer on a key-by-key basis is bad idea. It will prevent things like the cache monitor from working correctly since the cache provider wouldn’t know what serializer it needed to use in order to perform maintenance on the cached objects or display them unless you also modified the store to keep track of the serializer that was used to set it. If you want some objects to use a different serialization scheme, I would say that should be a different cache.
Even if I did allow overrides on a get/set level, I would use the “extra” struct attribute. However, it should be noted that “extra” only exists on set, not get. I’m not sure why, but I think we should change it. However, that will require an update to the interface which will break any existing cache implementations. Though, if the store kept track of the serialization in use, I guess “extra” wouldn’t be needed on get() anyway.
> Regardless of the approach (subclass or not), there is still the stumbling point of how to serialize an object on one engine which can be read on another. That’s essentially the core issue.
What about my suggestion to simply use JSON? You haven’t told me what kind of cached items you need to share between CFML engines so I can’t provide any more ideas right now since I don’t know what kind of serialization constraints you might have.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com