I have just read through the PSR7 again and this time it dawned on me. I now know how to fix all that was bothering me.
This PSR needs a ServerResponse interface as a counterpart to ServerRequest. ServerRequest provides access to cookies via a separate methid and it seems logical for a ServerResponse to exists that also provides the ability to modify cookies.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/6zesbZWLY_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6sLcnf%3DUMCqAPpoePWSmH3%2BhGd2QeCNEZZqJCTXEDqs6ng%40mail.gmail.com.
The problem is with having to parse them into headers manually.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/6zesbZWLY_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6sJDQEdd-m0DmTigmD2LWr2-aHZB%3D9Te3KGRJbZYhGfPmQ%40mail.gmail.com.
There's a lot to account for when implementing that:We already have a good tool for setting cookies, that comes bundled with PHP in the standard library and is used by pretty much every app out there. Forcing everyone to switch from that working tool ( setcoockie() ) is kind of suboptimal
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/6zesbZWLY_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6s%2BOtO01c7pHEceH1a3Dq1JuET3ERTdk0kiiNxvTanMARQ%40mail.gmail.com.
Ok, I'm clearly not getting my point through, let me try to describe what I mean step by step.Important part: at no point do I suggest that any implementation of this PSR should have anything to do with setcookie(), I mean something different.You are right that the Response interface should only concern itself with representing, not printing. My original point was that since the response doesn't provide a getCookies(), getCookie(), setCookie() methods, the only way to add a cookie to a Response is this:->withAddedHeader('Set-Cookie', '<Cookie data parsed into header>')So as it is right now the PSR forces you to encode cookies into headers yourself.Now imagine a setCookie(), getCookie() etc. methods were added to the Response interface. This way cookie data would be represented as an array of CookieInterface instances. This way when printing out the response we would be able to do this:foreach($response->getCookies() as $cookie) {setcooke($cookie->getName()...);}So what I'm saying is that representing Cookies as parameters ( or CookieInterface instances ) is a much more flexible way that also enables us to use a native setcookie() function for writing the headers.With the current PSR7 Response interface this is not possible, since it requires you to treat cookies as any other header and set them in the parsed version.
However, MWOP (among others?) pointed out that a helper function/class/whatever can correctly format a Cookie header for insertion into the Message. As a follow-on, helper functions/classes can correctly format other kinds of specific-use headers (Cache, etc).
If you go down this "specific case scenario" way, you start having separate VOs for each kind of header (which is what some libraries do), and that' is already way too specific.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/6zesbZWLY_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6sL94kD%2B0XYmWxY1-mmo4nRvRkNgd%3D4mBcm-PyAkG7Kibw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANamvv1wBp3u9mDVVL15Pvu2cCruwdk9NW%2BBLw4N9QiVy%2BFnEQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6sL%2BhdCD%3DPEysVJkdUoA9Op15xKeWT2xW9ZmAvSiwkUoFQ%40mail.gmail.com.
There's no need to start a session for a user who just wants to change the language on the site.
PHP doesn't have native support for content negotiation nor cache control, so I really don't follow that line of thought.
Also, speaking of sessions, does the session cookie have to be represented when you call getHeaders() ? It is set by PHP itself.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/6zesbZWLY_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6sJPnP%2B%3D%3DjYYCoaCoCfZcq724Y8GaDg4AnPSP6JJ4LcD_g%40mail.gmail.com.
So how exactly will Accept and Content-Type help you if a user decides he wants to read your article in German?
some articles allow you to adjust font size, lets fire up a session for that too? Cookies are widely used for tracking too. Invoking geocities is really irrelevant.
for all the rest there's content negotiation (yep, language choice is part of it)
tracking can be done *without* cookies at all ( http://en.wikipedia.org/wiki/Evercookie )
Besides that, dealing with cookies directly causes more security issues than solutions.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/6zesbZWLY_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6s%2BN-z4DBV1AgKXr43TPJv_xkWd6%3Dv%3DLaExYpmFBfK1fCA%40mail.gmail.com.
I have just read through the PSR7 again and this time it dawned on me. I now know how to fix all that was bothering me.
This PSR needs a ServerResponse interface as a counterpart to ServerRequest. ServerRequest provides access to cookies via a separate methid and it seems logical for a ServerResponse to exists that also provides the ability to modify cookies.
With this API, you do not have to inject a CookieWriter or a CookieReader everywhere, you just ask for it when you need to access a cookie. If you only need one cookie, you can do it all in one line.
The big win here is that I just created a framework agnostic way to manage cookies for any potential PSR-7 implementation.
Neither PSR-7 nor the lack of setcookie/getcookie on the request/response hindered me at
Plus, if they ever need to, they can just swap out my cookie implementation for theirs or another of their choosing.
frameworks can provide this type of functionality in helpers that flow better with their style
With this API, you do not have to inject a CookieWriter or a CookieReader everywhere, you just ask for it when you need to access a cookie. If you only need one cookie, you can do it all in one line.Well I'm really not a fan of your static approach:$cookies = Cookies::fromRequest($request);
The big win here is that I just created a framework agnostic way to manage cookies for any potential PSR-7 implementation.I don't see how having setters/getters for cookies would somehow make it less framework agnostic.
Neither PSR-7 nor the lack of setcookie/getcookie on the request/response hindered me atYes they did because they forced you to do the CookieWriter thingy, which by the way is also not interpolable between frameworks. So now your middleware implementation has a hard dependency on a specific cookie writer.
Plus, if they ever need to, they can just swap out my cookie implementation for theirs or another of their choosing.Same would happen if you had cookie getters/setters. How would having cookie params as value object hinder any of the interpolability?
On 27 March 2015 at 08:06, Dracony <draco...@gmail.com> wrote:With this API, you do not have to inject a CookieWriter or a CookieReader everywhere, you just ask for it when you need to access a cookie. If you only need one cookie, you can do it all in one line.Well I'm really not a fan of your static approach:$cookies = Cookies::fromRequest($request);This is just a static constructor/factory: no side-effects, therefore static is OK.
The big win here is that I just created a framework agnostic way to manage cookies for any potential PSR-7 implementation.I don't see how having setters/getters for cookies would somehow make it less framework agnostic.It is just bloating up the API: more code to implement for everyone willing to write a PSR-7 implementation, plus cookie-specific mess to deal with, whereas it is a simple key/value map as-is.
It is just bloating up the API: more code to implement for everyone willing to write a PSR-7 implementation, plus cookie-specific mess to deal with, whereas it is a simple key/value map as-is.
Every implementor of PSR-7 would have to code:
- cookie handling inside the HTTP message logic
- merging with the headers array
Cookies are a very specific case and are much harder to format and parse than other headers. Otherwise we wouldnt have support for them in serverRequest
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/6zesbZWLY_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8531EB0D-E5B4-450F-970E-41E815F05F5D%40gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/6zesbZWLY_Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/E86B6DEE-5F08-4551-B5F9-A53C0B66EB4B%40gmail.com.
Thanks for your explanation. Though I dont really like it, I'll be implementing this for PHPixie today, for standards sake.
Can you also please answer my other question on immutability, so that I have all the info I need for my implementation ? Thanks
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myVgjp4ZKXiK2wX6GJR3D-sajM1L3jY%2B2hS%2BrpzbKoO%2BxQ%40mail.gmail.com.