Re: [Prototype-core] Re: Ajax.Request Interface
On Thu, Feb 4, 2010 at 17:29, Joran Greef wrote: > > Re: "But I also think that by default put/delete should not use method > overriding" > Agreed. They should be plain vanilla put/delete. If the client does > not support them put/delete should not exist. > I think that I've tested it more than a year ago and that all our supported browsers did HEAD, PUT, DELETE without problem. It was the other HTTP methods where there were more differences. > Propose we rename "onFailure" to "onError". Good looking. Faster to > type. > onFailure was chosen as opposite to onSuccess > Perhaps we could also look at incorporating support for cross-origin > HTTP? There a number of methods that could be abstracted over, such as > Kris Zyp's WindowNameRequest for example? I would be happy with JSONP. -- You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
Re: [Prototype-core] Re: Ajax.Request Interface
On Tue, 29 Dec 2009 15:13:44 +0300, Joran Greef
wrote:
Propose:
Http.get(uri, options) and Http.post(uri, options).
Where:
options = {
headers: {},
parameters: {},
body: '',
onSuccess: function(response) {},
onFailure: function(response) {},
onTimeout: function(response) {}
}
And:
response = {
status: Integer,
headers: {},
body: ''
}
Static methods: 'Http.get(uri, options)' as opposed to 'new Http.Get
(uri, options)'. The developer must explicitly set 'X-HTTP-Method-
Override' header or '_method' parameters or whatever he or she wants
to use to signal an unsupported method such as 'PUT' and
'DELETE' (depending on the capability of the server). The developer
I strongly disagree that put/delete methods are "unsupported". These are
only unsupported by some ancient proxies and firewalls. I think that
since these methods are described in the same spec as get/post, they must
be first class citizens in the library. So I'm for static
`Http.[Get|Post|Put|Delete]`. But I also think that by default put/delete
should not use method overriding. Instead there should be a simple way to
turn on legacy support, like subclass LegacyHttp, which will override.
must explicitly parse response.body. The Http object must be merely a
cross-browser wrapper for XMLHttpRequest and must not take on too much
responsibility or make assumptions on behalf of the developer, e.g.
with respect to JSON parsing etc.
I agree that core Http object should be plain wrapper. But also there
should be its subclass like JsonHttp, which would make all these
assumptions to simplify our code.
Same applies to other implicit defaults Joran Greef doesn't like. I agree
that base class should not be bloated. But all these features were
introduced because we do need them. This is why I propose to use some
hierarchy to provide web developer with convenient features and still
avoid bloat.
--
arty ( http://arty.name )
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
Re: [Prototype-core] Re: Ajax.Request Interface
+1 for static methods. Not sure about the implications of the rest yet.
Allen Madsen
http://www.allenmadsen.com
On Tue, Dec 29, 2009 at 7:13 AM, Joran Greef wrote:
> Propose:
>
> Http.get(uri, options) and Http.post(uri, options).
>
> Where:
>
> options = {
> headers: {},
> parameters: {},
> body: '',
> onSuccess: function(response) {},
> onFailure: function(response) {},
> onTimeout: function(response) {}
> }
>
> And:
>
> response = {
> status: Integer,
> headers: {},
> body: ''
> }
>
> Static methods: 'Http.get(uri, options)' as opposed to 'new Http.Get
> (uri, options)'. The developer must explicitly set 'X-HTTP-Method-
> Override' header or '_method' parameters or whatever he or she wants
> to use to signal an unsupported method such as 'PUT' and
> 'DELETE' (depending on the capability of the server). The developer
> must explicitly parse response.body. The Http object must be merely a
> cross-browser wrapper for XMLHttpRequest and must not take on too much
> responsibility or make assumptions on behalf of the developer, e.g.
> with respect to JSON parsing etc.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prototype: Core" group.
> To post to this group, send email to prototype-core@googlegroups.com
> To unsubscribe from this group, send email to
> prototype-core-unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/prototype-core?hl=en
>
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
Re: [Prototype-core] Re: Ajax.Request Interface
On Fri, 11 Dec 2009 21:02:52 +0300, Joran Greef wrote: > Thanks Artemy, 'set' vs 'put' took some consideration. Basically: many > Javascript APIs use 'get', 'set', 'unset' methods. I used to use POST > (as in 'create') but now find it's easier to deal with network failure > using only PUT (as in 'set') as POST is not idempotent. As mentioned > above, where the server supports PUT, your Http.set would be upgraded > from a POST to a PUT. Where it does not, your Http.set would remain a > POST so you get the best of both worlds. I guess you could do > Http.Get, Http.Post, Http.Put and Http.Delete static methods to get > around 'delete' being reserved. This then is quite extensible, one > downside being that the method names are then upper camelCase. > Although I would argue for point 2 above, I do think that Http.set, > get, unset sits better next to other Javascript APIs. Excuse me if > "memorable" came off as "better": what I meant is "easy to remember". So you propose to use only one of two methods: POST and PUT. This might seem useful in some cases, but any widely accepted library can't do that. Many developers do make distinction between POST and PUT, and library shouldn't decide for them. Also it looks like you think that 'X-Http-Method-Override' automatically makes server think that method wasn't POST. This is not true: I know many cases where you have to implement that manually (and know no case where this is automatic). The only idea I agree with is that such header is better than `_method` parameter. I understand that you want to make ajax calls look more like javascript APIs, however HTTP is quite different from them, and good library shouldn't hide too much from developer. I already know HTTP, and it's *easier to remember* HTTP-like terms, than proposed JS→HTTP mapping. > Re: "Why use 'representation' and not 'body'?" > REST = Representational State Transfer. HTTP RFC says that HTTP message consists of start-line, headers and body. Representation isn't there, sorry. -- arty ( http://arty.name ) -- You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
