On Fri, 2013-10-04 at 20:38 +0200, Christian Stadler wrote:
Actually I like the idea of having an API to handle everything important
for the HTTP-request and respectively for the response.
e. g.:
HTTPRequest::getFormData(...), which could possibly be aliased by
HTTPRequest::getPOSTData(...)
Hi All,
Johannes Schlüter wrote (on 07/10/2013):
Why replace something? Are there flaws which can't be fixed? Adding too
many ways to do the same thing is confusing for everybody. If you want
it object oriented or such frameworks do great things. The language
should offer a good foundation. (It
Am 02.10.2013 23:40, schrieb Johannes Schlüter:
On Wed, 2013-10-02 at 19:59 +0200, Michael Wallner wrote:
On 2 October 2013 16:10, Johannes Schlüter johan...@schlueters.de wrote:
On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
Since ever people are confused by _GET and _POST
hi!
On Wed, Oct 2, 2013 at 8:15 AM, Nikita Popov nikita@gmail.com wrote:
On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner m...@php.net wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method.
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not
100% confident with the latter
On 02.10.2013, at 10:59, Michael Wallner m...@php.net wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase out
On 2 October 2013 09:17, Alexey Zakhlestin indey...@gmail.com wrote:
3. expose body-parsers via php-level API
+1. Hell, yes! Something like +1000, actually ;)
Uhmmm... I actually meant an interal API not userland :)
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing
Hi,
wouldn’t $_BODY be better - since it is the request body?
$_FORM is imho not very clear, since you can send data to $_POST without using
a form.
--
Cheers
Jannik
Am Mittwoch, 2. Oktober 2013 um 09:17 schrieb Alexey Zakhlestin:
On 02.10.2013, at 10:59, Michael Wallner m...@php.net
On 2 October 2013 09:25, Jannik Zschiesche he...@apfelbox.net wrote:
Hi,
wouldn’t $_BODY be better - since it is the request body?
$_FORM is imho not very clear, since you can send data to $_POST without
using a form.
I had it, but I'm not sure $_BODY fits either, because it should be an
On 02.10.2013, at 11:24, Michael Wallner m...@php.net wrote:
On 2 October 2013 09:17, Alexey Zakhlestin indey...@gmail.com wrote:
3. expose body-parsers via php-level API
+1. Hell, yes! Something like +1000, actually ;)
Uhmmm... I actually meant an interal API not userland :)
well,
Le 2 octobre 2013 à 07:59, Michael Wallner m...@php.net a écrit :
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase
Le 2 octobre 2013 à 10:58, Michael Wallner m...@php.net a écrit :
On 2 October 2013 11:56, Andrea Faulds a...@ajf.me wrote:
Backwards compatibility matters, so we should keep $_GET and $_POST but add
these as better aliases for them.
That's why I said phase out... or is it a german
On 2 October 2013 07:59, Michael Wallner m...@php.net wrote:
I propose to phase out $_GET and name it $_QUERY and
I propose to phase out $_POST and name it $_FORM
I have to say I'm against this aspect of the proposal. While the names
may not be 100% accurate, _most_ people are used to their
On 02.10.2013, at 15:12, Leigh lei...@gmail.com wrote:
On 2 October 2013 08:31, Michael Wallner m...@php.net wrote:
I had it, but I'm not sure $_BODY fits either, because it should be an
array. Currently only form data fits the purpose of de-serialisation
of a request body.
Not so
On 2 October 2013 12:00, Andrea Faulds a...@ajf.me wrote:
Le 2 octobre 2013 à 10:58, Michael Wallner m...@php.net a écrit :
On 2 October 2013 11:56, Andrea Faulds a...@ajf.me wrote:
Backwards compatibility matters, so we should keep $_GET and $_POST but add
these as better aliases for them.
On 2 October 2013 13:12, Leigh lei...@gmail.com wrote:
On 2 October 2013 07:59, Michael Wallner m...@php.net wrote:
I propose to phase out $_GET and name it $_QUERY and
I propose to phase out $_POST and name it $_FORM
I have to say I'm against this aspect of the proposal. While the names
Le 2 octobre 2013 à 13:27, Michael Wallner m...@php.net a écrit :
On 2 October 2013 13:12, Leigh lei...@gmail.com wrote:
On 2 October 2013 07:59, Michael Wallner m...@php.net wrote:
You certainly won't be able to remove $_GET / $_POST (implied by
phase out) in any 5.x release, it's
On Wed, 2013-10-02 at 14:50 +0100, Andrea Faulds wrote:
Le 2 octobre 2013 à 13:27, Michael Wallner m...@php.net a écrit :
On 2 October 2013 13:12, Leigh lei...@gmail.com wrote:
On 2 October 2013 07:59, Michael Wallner m...@php.net wrote:
You certainly won't be able to remove $_GET
On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase out $_POST
On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner m...@php.net wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase
Further, I propose to remove the POST method restriction for handling
request bodies and solely rely on the content type to trigger the
parser(s). (*)
+1
This would solve the with parsing multi-form data with PUT requests (and
possibly any future method types), thus enabling full REST support :)
On 2 October 2013 16:10, Johannes Schlüter johan...@schlueters.de wrote:
On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose
On 2 October 2013 17:15, Nikita Popov nikita@gmail.com wrote:
On Wed, Oct 2, 2013 at 8:59 AM, Michael Wallner m...@php.net wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I
On Wed, Oct 2, 2013 at 8:02 PM, Michael Wallner m...@php.net wrote:
There are already parsers for application/x-www-form-urlencoded and
multipart/form-data in the core. One could think of providing an API
to add content type handlers from extensions, ext/json may be an
example, like it
On 02.10.2013, at 10:59, Michael Wallner m...@php.net wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do not (really) depend on the
request method. Therefor I propose to phase out $_GET and name it
$_QUERY and I propose to phase out
On Wed, 2013-10-02 at 19:59 +0200, Michael Wallner wrote:
On 2 October 2013 16:10, Johannes Schlüter johan...@schlueters.de wrote:
On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote:
Since ever people are confused by _GET and _POST superglobals,
because, despite their name, they do
26 matches
Mail list logo
