RE : Re: [haXe] POST forms in neko.Web

[Benjamin Dasnois]

I agree with Yanis. My  understanding is that both can coexist and the method is just a verb (understand "an indication of what to do")

Regards,

Benjamin Dasnois

Le 6 avr. 2010, 8:00 AM, "Yanis Benson" <[hidden email]> a écrit :

No, it's not.

get a1 = 111
post a2 = 222, a1 = 333

POST /index.php?a1=111
Content-Length: 13
Content-Type: application/x-www-form-urlencoded

a2=222&a1=333

On 04/06/2010 01:39 AM, Laurent Kappler wrote: > > > For what I understand about request there's nev...

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

[Laurent Kappler]

but I don't understand why that ?a1=111 should mean GET ... I think
having parameters for GET send with parameters for POST would make just
thing less clear.
And actually why stop with POST and GET... this ?a1=111 could mean PUSH,
DELETE ...

Laurent


Benjamin Dasnois a écrit :

>
> I agree with Yanis. My  understanding is that both can coexist and the
> method is just a verb (understand "an indication of what to do")
>
> Regards,
>
> Benjamin Dasnois
>
>> Le 6 avr. 2010, 8:00 AM, "Yanis Benson" <[hidden email]
>> <mailto:[hidden email]>> a écrit :
>>
>> No, it's not.
>>
>> get a1 = 111
>> post a2 = 222, a1 = 333
>>
>>     POST /index.php?a1=111
>>     Content-Length: 13
>>     Content-Type: application/x-www-form-urlencoded
>>
>>     a2=222&a1=333
>>
>> On 04/06/2010 01:39 AM, Laurent Kappler wrote: > > > For what I
>> understand about request there's nev...
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

[clemos]

Hi

I think this is traditionnally the way we make a distinction between
parameters passed in the body of the request (POST) and parameters
passed in url (GET).
This does not necessarilly mean that the request is actually of that
kind (POST request can carry parameters in its url).

There seem to be a neko.Web.getPostData method, so you can get the
data and parse it on your own...

This being said, I guess the haxe Web API is somehow confusing:
- GET and POST data are merged into "params", making it all simpler,
but in the other hand, why not merging Cookie data as well (that's
what PHP does with $_REQUEST) ?
- there should be common methods for accessing GET, POST and Cookie
data in a distinct way, maybe through method conventions
(getPostParams(), getCookieParams(), getGetParams() ... )

Or it is just a bit raw, and one should write a little library on top
of that low level API to clarify this while keeping the std lib
lighter... ?

++++++
Clément

On Tue, Apr 6, 2010 at 11:02 AM, Laurent Kappler
<[hidden email]> wrote:

> but I don't understand why that ?a1=111 should mean GET ... I think having
> parameters for GET send with parameters for POST would make just thing less
> clear.
> And actually why stop with POST and GET... this ?a1=111 could mean PUSH,
> DELETE ...
>
> Laurent
>
>
> Benjamin Dasnois a écrit :
>>
>> I agree with Yanis. My  understanding is that both can coexist and the
>> method is just a verb (understand "an indication of what to do")
>>
>> Regards,
>>
>> Benjamin Dasnois
>>
>>> Le 6 avr. 2010, 8:00 AM, "Yanis Benson" <[hidden email]
>>> <mailto:[hidden email]>> a écrit :
>>>
>>> No, it's not.
>>>
>>> get a1 = 111
>>> post a2 = 222, a1 = 333
>>>
>>>    POST /index.php?a1=111
>>>    Content-Length: 13
>>>    Content-Type: application/x-www-form-urlencoded
>>>
>>>    a2=222&a1=333
>>>
>>> On 04/06/2010 01:39 AM, Laurent Kappler wrote: > > > For what I
>>> understand about request there's nev...
>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org

[Laurent Kappler]

For now I've always been using the params this way, I nearly don't use
any url GET params.
Only urls like this /path/to/somethin/id/action + a request method which
allow a lot of possibilities.

Maybe the way mtwin.web.Handler class works should be ported to that php
project of Yanis.

I started reading this:
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 
<http://www.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm>

phd defining the RESTful interface, which state that everything on a
network application is a link to resume.
For what I understand shortly, no more GET params in url. I just read
the beginning and this is just a feeling I have :)

Laurent


clemos a écrit :

> Hi
>
> I think this is traditionnally the way we make a distinction between
> parameters passed in the body of the request (POST) and parameters
> passed in url (GET).
> This does not necessarilly mean that the request is actually of that
> kind (POST request can carry parameters in its url).
>
> There seem to be a neko.Web.getPostData method, so you can get the
> data and parse it on your own...
>
> This being said, I guess the haxe Web API is somehow confusing:
> - GET and POST data are merged into "params", making it all simpler,
> but in the other hand, why not merging Cookie data as well (that's
> what PHP does with $_REQUEST) ?
> - there should be common methods for accessing GET, POST and Cookie
> data in a distinct way, maybe through method conventions
> (getPostParams(), getCookieParams(), getGetParams() ... )
>
> Or it is just a bit raw, and one should write a little library on top
> of that low level API to clarify this while keeping the std lib
> lighter... ?
>
> ++++++
> Clément
>
> On Tue, Apr 6, 2010 at 11:02 AM, Laurent Kappler
> <[hidden email]> wrote:
>  
>> but I don't understand why that ?a1=111 should mean GET ... I think having
>> parameters for GET send with parameters for POST would make just thing less
>> clear.
>> And actually why stop with POST and GET... this ?a1=111 could mean PUSH,
>> DELETE ...
>>
>> Laurent
>>
>>
>> Benjamin Dasnois a écrit :
>>    
>>> I agree with Yanis. My  understanding is that both can coexist and the
>>> method is just a verb (understand "an indication of what to do")
>>>
>>> Regards,
>>>
>>> Benjamin Dasnois
>>>
>>>      
>>>> Le 6 avr. 2010, 8:00 AM, "Yanis Benson" <[hidden email]
>>>> <mailto:[hidden email]>> a écrit :
>>>>
>>>> No, it's not.
>>>>
>>>> get a1 = 111
>>>> post a2 = 222, a1 = 333
>>>>
>>>>    POST /index.php?a1=111
>>>>    Content-Length: 13
>>>>    Content-Type: application/x-www-form-urlencoded
>>>>
>>>>    a2=222&a1=333
>>>>
>>>> On 04/06/2010 01:39 AM, Laurent Kappler wrote: > > > For what I
>>>> understand about request there's nev...
>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>        
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>    
>
>  

--
haXe - an open source web programming language
http://haxe.org

[basvanmeurs]

Hi,

It is indeed possible to write a RFC implementation which parses the GET and POST parameters. Unfortunately, I also found out that the url is url decoded before you can get it via getUri. This is another design decision I don't understand and is again very different from what PHP and Java do. I like to pct-encode some other characters, like slashes, when I add them as a url segment. The fact that I can't get the original url in any way makes this impossible. This I can only work around by using another character for escaping which makes my urls less nice.

I think the neko.Web interface should be straightforward, to the point and without any 'extras'. Just give me the POST-, GET-parameters and original URL. All other major platforms supply this information so if Neko wants to be a serious contender this is absolutely necessary imo..