Implement a workaround. Just write an errback that turns 2xx into a
successful response, that way your code will still work if the
behavior eventually changes.
On 7/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So is this yet another thread on success codes that ends without
consensus or
So is this yet another thread on success codes that ends without
consensus or a final word on success code meaning in MochiKit?
Obviously I would prefer it if MochiKit treated all 2** as successes
but if the decision is that this wont change then I'll just implement
the work around and take it
On Jul 6, 10:11 am, Bob Ippolito [EMAIL PROTECTED] wrote:
It works 100% of the time. If you're doing something obscure with
status codes (anything obscure, even successful codes that aren't
2xx), you need to use an extra three lines of code in this case. That
doesn't mean it's broken.
The
On 7/5/07, Karen J. Cravens [EMAIL PROTECTED] wrote:
On Jul 5, 8:19 pm, Bob Ippolito [EMAIL PROTECTED] wrote:
with (the ones that you actually run into in the wild). It's easy to
Given the increasing popularity of REST, seems pretty likely you'll
start running into a wider range of
On 7/6/07, Karen [EMAIL PROTECTED] wrote:
On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote:
As demonstrated it's effectively three lines of code to do whatever
you want to do with HTTP status codes, and you only have to write it
once. If that really makes such a difference, then I doubt
On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote:
As demonstrated it's effectively three lines of code to do whatever
you want to do with HTTP status codes, and you only have to write it
once. If that really makes such a difference, then I doubt MochiKit is
the right choice for you. There are
On 7/6/07, Karen [EMAIL PROTECTED] wrote:
On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote:
It works 100% of the time. If you're doing something obscure with
status codes (anything obscure, even successful codes that aren't
2xx), you need to use an extra three lines of code in this case.
On 7/6/07, Karen [EMAIL PROTECTED] wrote:
It means it's not RFC-compliant out of the box. I'm not saying that's
a bad thing overall (the other 99% of the time, you don't want
overhead for bits that almost no one uses), I'm just saying it's a bad
fit for me.
Three lines of code for this fix
On 7/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I have been working with Async to build an inhouse web app, we have
ended up using the return codes to implement some interesting
behaviour in our clients.
MochiKit is just one of the clients that uses the web service and some
of our
On Jul 5, 8:19 pm, Bob Ippolito [EMAIL PROTECTED] wrote:
with (the ones that you actually run into in the wild). It's easy to
Given the increasing popularity of REST, seems pretty likely you'll
start running into a wider range of response codes in the wild.
It's kind of disturbing to learn
10 matches
Mail list logo
