http://coldfusion.com logo
Join Slack
Powered by
Using cbstorages, shouldn't `cookieStorage.getKeys...
# box-products
s
Using cbstorages, shouldn't 
cookieStorage.getKeys()
be an array of all the keys you see if you 
writedump( cookie );
?
b
@sknowlton Not neccesssarily
if you look at the 
getStorage()
method you can see it filters out specific keys with a prefix
So keykeys() would be a subset of the entire cookie scope
s
I've got:
Copy code
dump( cookie )
		dump( cookieStorage.getKeys() );
		dump( cookieStorage.getStorage() );
The first dumps a struct with 31 keys. The last two are empty
oh it's ONLY returning things with that prefix
huh
It's not filtering out specific keys, it's filtering out everything except those specific keys
b
Sorry, I should have said "filters out specific keys BASED ON a prefix" 🙂
So, a prefix is used to determine what keys you see
s
Why is that default behavior? If I ask for my cookie storage ... shouldn't I get all my cookies in storage? Prefixes are nice but seems like an extra hoop. What am I missing?
even the interface says:
Copy code
/**
	 * Get the entire storage scope structure, basically means return all the keys
	 */
	struct function getStorage();
I want basically
b
Because the cookie storage facade is not the same as your CF engine's cookie scope
It's a separate storage mechanism that happens to use the cookie scope under the covers to power it
Imagine calling someScope.clear() and you lose your cfid and cftoken session variables!
You'd rightly say that you never used the scope facade to set those so it never should have touched them
The session scope is the same way-- it uses a nested struct to demarcate what the storage set vs other variables set into that CF scope from somewhere else
basically, the storage facades are not a means to manage your cf scopes. They are a storage mechanism powered by your cf engine scopes
s
this decision appears to cater to the developer who arbitrarily blasts an entire scope at the expense of a use case where we are (legitimately) setting a cookie outside of Coldbox/CF and wanting to read it inside of Coldbox/CF and now cannot
seems unusually opinionated, even if, like most opinionated software positions, it's a perfectly good opinion
I don't want a storage mechanism powered by my cf engine scope, I want my nice Coldbox storage façade to do whatever I tell it to with the scope I tell it to use
b
I don't think it's a matter of opinion. It's a matter of design. Again, the storage facades are not a means to manage your cf scopes. They are a storage mechanism powered by your cf engine scopes
s
• 
Consistent API for dealing with all persistent scopes
"that will enhance the capabilities of the major ColdFusion (CFML) scopes:"
b
I'll let @lmajano speak to the wording in his docs 🙂
w
If you enhance the scopes, you cannot expect it to be totally transparent for reads and writes. The cookiestorage for example has an encryption option which would not work if you were allowing setting keys from outside cookiestorage.
Same is true for cache storage. you will need some prefix there, so it’s more or less an all or nothing with respect to setting and getting values. Most of the storages have some locking mechanisme which also doesn’t play well with access from outside. If you really need to access cookie access for external cookies, you could extend the cookiestorage (effectively creating your own storage facade ) and just change the key to an empty string in the init function.
I totally agree the docs should be a bit clearer here. Most of the scopes return just a subset of all variables available in cache, session, request, cookie etc, which means you will run into trouble if you don’t use the storage for both getting and setting.
s
Sure, but it's an option. I get why it is the way it is. It makes sense. But it is opinionated where it should be giving me a choice. It is an edge case, so I'm fine with a requirement that says 'if you really want to see the WHOLE scope, press this big red button.' Or else the docs should just say 'enhances the major CFML scopes, except for Sam'
wouldn't be the first time. 🙂
w
I had exactly the same problems with cookiestorage the first time I wanted to use it. And I had to fix some bugs which had been there for ages. Probably people were not using it a lot… although it can be very handy
s
We didn't use cbstorages for years because we didn't 'get' it. Because I was dumb
Now I'm less dumb, a little, and love them
Open in Slack
PreviousNext
Powered by