Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69484
Return-Path: <php-php-dev@m.gmane.org>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 24470 invoked from network); 4 Oct 2013 18:40:09 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 4 Oct 2013 18:40:09 -0000
Authentication-Results: pb1.pair.com smtp.mail=php-php-dev@m.gmane.org; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=stadli@gmx.de; sender-id=fail
Received-SPF: pass (pb1.pair.com: domain m.gmane.org designates 80.91.229.3 as permitted sender)
X-PHP-List-Original-Sender: php-php-dev@m.gmane.org
X-Host-Fingerprint: 80.91.229.3 plane.gmane.org  
Received: from [80.91.229.3] ([80.91.229.3:44544] helo=plane.gmane.org)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 3D/65-24156-78B0F425 for <internals@lists.php.net>; Fri, 04 Oct 2013 14:40:09 -0400
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <php-php-dev@m.gmane.org>)
	id 1VSAIG-00019J-2p
	for internals@lists.php.net; Fri, 04 Oct 2013 20:40:04 +0200
Received: from dslc-082-082-132-229.pools.arcor-ip.net ([82.82.132.229])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <internals@lists.php.net>; Fri, 04 Oct 2013 20:40:04 +0200
Received: from stadli by dslc-082-082-132-229.pools.arcor-ip.net with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <internals@lists.php.net>; Fri, 04 Oct 2013 20:40:04 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: internals@lists.php.net
Date: Fri, 04 Oct 2013 20:38:01 +0200
Lines: 61
Message-ID: <l2n1te$q26$1@ger.gmane.org>
References: <CALJZF3hq1FVTJUGwq9PAt+6joDhmuoXPR9Z8cxTPvafUmek9wg@mail.gmail.com>  <1380723023.19591.24.camel@guybrush>  <CALJZF3g9WaXADPfBYgn5FQCv7njcpSRgo0gERbjYCirvbx0maQ@mail.gmail.com> <1380750003.19591.55.camel@guybrush>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Gmane-NNTP-Posting-Host: dslc-082-082-132-229.pools.arcor-ip.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
In-Reply-To: <1380750003.19591.55.camel@guybrush>
Subject: Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing
 PUT data)
From: stadli@gmx.de (Christian Stadler)

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 <johannes@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 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 yet, though).
>> >
>> > The later is certainly misleading. The current naming corresponds to
>> > HTML forms.
>> >
>> >    <form method="GET">   -> $_GET
>> >    <form method="POST">  -> $_POST
>> 
>> Heh, pretty good observation! Didn't think about that. Still not
>> buying. $_FORM is derived from "application/x-www-form-urlencoded"
>> resp. "multipart/form-data" and $_QUERY is obvious.
> 
> Out of curiosity I did some browsing:
> 
> - ASP uses Request.QueryString(string name) and Request.Form
> - Java Servlets and JSP use ServletRequest.getParameter() for both
> - Perl CGI.pm has a param hash for both.
> 
> I didn't look really deep though for further specifics :)
> 
> So, ASP seems to agree with you, while I see a e difference: In ASP
> those are methods which, when used, are always qualified by the Request
> Object's name.

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(...) or HTTPRequest::getPOST(...);
as well as
HTTPRequest::getQueryData(...) aliased by
HTTPRequest::getGETData(...) or HTTPRequest::getGET(...);
and HTTPRequest::filterXXX(...) as a replacement for filter_var()
and so on

HTTPResponse could include a replacement for htmlspecialchars and
htmlentities (not quite sure, if this fits better to HTTPRequest or
probably into both)
HTTPResponse::buildQuery() would be a replacement für http_build_query
and so on.

To make a long story short: IMHO Every function and superglobal related
to the HTTP-request or -response should be moved to their respective
classes so eveything is under one hood rather than making userland
guessing which function/superglobal/whatever is for what purpose.
As it is now, it is kinda chaotic and confusing to me and probably to
userland, too.

Just may 2 cents about that topic.

Regards,
  Christian Stadler