You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More control since you could send() manually now (if really necessary) - cookies are cleared after sending to prevent sending them twice
CakeResponse now slimmer, Component now slim, maybe even a short read-only CookieHelper possible (for cookie infos regarding which tabs are currently open or which button is selected and other View related cookie information similar to Session stuff used this way)
Configuration like Session via Configure class instead of beforeFilter hacks etc
keeping BC for component access (and configuration via beforeFilter access)
I like that configuration would become like configuration elsewhere in the framework. Instead of reading from $_COOKIE directly, couldn't that be an input parameter to the class' constructor? If you're going to make a constructable instance, why are all the properties/methods static? Wouldn't it make more sense to have instances be separate and share the instance?
It wasn't my intension to make it constructable, but to ensure, init() and all the configuration setup is only triggered once (therefore the started attribute). Is there a better way of doing it? or is the instance maybe even a desired result?
My guideline here was the "Pseudo constructor" of CakeSession.
I tried to keep it as similar to CakeSession as possible, with full static access.
You should be able to do
$res = CakeCookie::read('foo');
right away, and if init() has not been invoked yet, it will do so internally. but only once, of course.
Not sure if we should keep the separate class attributes (copied over from CookieComponent). The CakeSession class sets Configure::write() and uses those then. No need to write them to the CakeCookie class as static attributes only to re-read them for each operation IMO.
PS: CakeCookie itself is up and running (all tests pass), I need to assert now that BC for CookieComponent is given.
After furthing working on it, I am pretty certain that the configuration should completely be covered by core/boostrap and Configure::write() and not be set in beforeFilter etc. This will be the only (small) non-BC-change here which can be added to the upgrade guide.
I think not too many actually modify the cookie configuration so far and even if, moving it into Configure should be fairly easy to manage.
To keep things even smoother, you could also just replace beforeFilters'