Last modified: 2014-04-29 14:13:08 UTC
as mv.Api.post() renders {foo:['a','b']} as foo[]=a&foo[]=b, either the API should allow those alternative, or the JavaScript function should change to have special logic to handle api specific syntax so people doesn't have to type foo: 'a|b' manually. (complex cases might warrant dynamic props variable for example)
(In reply to comment #0) > either the API should allow those alternative, or the JavaScript function > should change to have special logic to handle api specific syntax Or people could just supply the data in the correct format. > so people doesn't have to type foo: 'a|b' manually. Considering that's easier to type than "foo:['a','b']", I'm failing to understand why you're presenting this as a reason for your request.
(In reply to comment #1) > (In reply to comment #0) > > either the API should allow those alternative, or the JavaScript function > > should change to have special logic to handle api specific syntax > > Or people could just supply the data in the correct format. I would assume most programmers would think that it's perfectly logical to pass an array in those instances, and that either the module changes it to the "correct format" or that the api allows the normal syntax. > > > > so people doesn't have to type foo: 'a|b' manually. > > Considering that's easier to type than "foo:['a','b']", I'm failing to > understand why you're presenting this as a reason for your request. I'm referring to when you are building abstractions for the api in the code, where you might want to add a prop depending on the context. Also {foo:['a','b']} is imo easier to debug (syntax highlighting) than foo: 'a|b'.
Any chance this can be implemented?
*** Bug 64570 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 10262 ***
This is not a dupe, bug 10262 was about changing the basic api interface, not about allowing additional interface for simplicity of clients
See bug 64570 comment 5. In short, your title here is a dup of bug 10262, while your comment 0 is collectively a dup of both bug 10262 and bug 64570. I'd prefer to keep the two bugs with clear focus (and possibly different resolutions) rather than this one.
(In reply to Brad Jorsch from comment #7) > See bug 64570 comment 5. In short, your title here is a dup of bug 10262, > while your comment 0 is collectively a dup of both bug 10262 and bug 64570. > I'd prefer to keep the two bugs with clear focus (and possibly different > resolutions) rather than this one. Ah, I didn't see bug 64570 comment 5 before I reopened this one.
That's partially my fault: I closed this as a dup on reading the title, then actually read comment 0 here, then wrote comment 5 there, then came back here and saw you had already reopened. Sorry for the trouble. If you agree that the other two bugs cover the issues, I'd like to re-close this bug, preferably as a duplicate of one of the two (since bugzilla won't let us mark it as a duplicate of both).
Yea, that's fine for me(In reply to Brad Jorsch from comment #9) > That's partially my fault: I closed this as a dup on reading the title, then > actually read comment 0 here, then wrote comment 5 there, then came back > here and saw you had already reopened. Sorry for the trouble. > > If you agree that the other two bugs cover the issues, I'd like to re-close > this bug, preferably as a duplicate of one of the two (since bugzilla won't > let us mark it as a duplicate of both). Yea, that's fine to me
As noted above, this is an either-or duplicate of both bug 10262 and bug 64570. *** This bug has been marked as a duplicate of bug 10262 ***
