The reason for the naming is simple, request contains request parameters, the parameters that are in the request body.
It is unfortunate that it conflicts with PHP's notion of $_REQUEST, which was a giant mess to begin with, but so it goes. Having request()/query()/.. helpers might make sense for conciseness, but the naming shouldn't change imo. I wanted it to change too at first, but in the end what do you prefer? Stick to your old php-biased view of the world, or learn proper names for things? $_REQUEST, $_POST and $_GET are irrelevant in the Sf2 context, you shouldn't use them, so why even think about them? Cheers On Tue, Apr 5, 2011 at 9:39 AM, Catalin Costache <[email protected]> wrote: > That is why I proposed the proper getters: > $this->get('request')->getPost() > $this->get('request')->getQuery() > $this->get('request')->getCookies() > etc > > or Lukas's helper methods: > > $this->get('request')->post() > $this->get('request')->cookies() > > On Tue, Apr 5, 2011 at 10:05 AM, Magnus Nordlander <[email protected]> > wrote: >> >> But that would not be the full syntax. The full syntax would >> be $this->get('request')->get->get('foo'), which looks ridiculous. I do >> agree that basically having $request->request->get('foo') looks weird, but I >> am far more annoyed that the parameter bags are public properties than I am >> with the naming. >> Magnus >> >> On Mon, Apr 4, 2011 at 10:23 PM, Catalin Costache >> <[email protected]> wrote: >>> >>> I agree, that's why I didn't insisted on the query bag. >>> But RFC's aside I think that $this->get('request')->get is more self >>> describing >>> than $this->get('request')->query because of the direct analogy with the >>> well known >>> $_GET and $_POST globals. >>> Anyway this name makes sense for this property because in the case of a >>> getter will be a little weird >>> to write $this->get('request')->getGet() >>> Regards, >>> Catalin >>> On Mon, Apr 4, 2011 at 11:13 PM, Marc Weistroff >>> <[email protected]> wrote: >>>> >>>> As for the $query property, the HTTP rfc defines the parameters given in >>>> an url after the question mark as "query". >>>> You can check section 3.2.2 at http://www.ietf.org/rfc/rfc2616.txt >>>> Cheers, >>>> Marc >>>> On Mon, Apr 4, 2011 at 6:45 PM, Catalin Costache >>>> <[email protected]> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I will like to propose a backward incompatible change to the naming of >>>>> the public $request ParameterBag >>>>> from the Symfony\Component\HttpFoundation\Request >>>>> >>>>> In my opinion it should be called $post instead of $request because: >>>>> 1. is obvious what part of the request is handled >>>>> 2. the current naming is deceiving (I expect to find GET, COOKIE or >>>>> other types of request parameters in this ParameterBag) >>>>> 3. finally but less important, in a controller you have to write >>>>> $this->get('request')->request->get('parameter') instead of >>>>> $this->get('request')->post->get('parameter') - a superficial argument, I >>>>> know. >>>>> >>>>> The same arguments stand also for the $query bag, but that makes more >>>>> sense >>>>> >>>>> What do you think? >>>>> I will make a pull request if you think that this is ok. >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> If you want to report a vulnerability issue on symfony, please send it >>>>> to security at symfony-project.com >>>>> >>>>> You received this message because you are subscribed to the Google >>>>> Groups "symfony developers" group. >>>>> To post to this group, send email to [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/symfony-devs?hl=en >>>> >>>> -- >>>> If you want to report a vulnerability issue on symfony, please send it >>>> to security at symfony-project.com >>>> >>>> You received this message because you are subscribed to the Google >>>> Groups "symfony developers" group. >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> For more options, visit this group at >>>> http://groups.google.com/group/symfony-devs?hl=en >>> >>> -- >>> If you want to report a vulnerability issue on symfony, please send it to >>> security at symfony-project.com >>> >>> You received this message because you are subscribed to the Google >>> Groups "symfony developers" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/symfony-devs?hl=en >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- Jordi Boggiano @seldaek :: http://seld.be/ -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
