On Tue, 29 Dec 2009 15:13:44 +0300, Joran Greef <jorangr...@gmail.com>
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
