I can compromise with your #2, and give them both my vote. Passing it on...
*1. Allow $.ajax() to accept multiple expected dataTypes. 2. Setting to have $.ajax() auto-detect/translate via response content-type header.* Julian - your thoughts? On Mon, Dec 28, 2009 at 3:39 PM, webbiedave <webbied...@websiteguard.com>wrote: > Rick, your 1 (which I too have suggested in the past) might bring about > unease as folks would prefer any eval-ing to come through explicit request. > I also think it's imperative that the behavior of any dataType setting > (including null) shouldn't change (especially to one that suddenly evals!). > But that's just my opinion. My 1, 2 would be: > > 1. Allow $.ajax() to accept multiple expected dataTypes. > > 2. Setting to have $.ajax() auto-detect/translate via response content-type > header. > > > > On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron <waldron.r...@gmail.com> > wrote: > >> > >> We're struggling with the best way to inform .ajax() that we expect > >> multiple data types. Either, with a setting like "auto" or by passing an > >> array of data types (or maybe allowing both). > >> > > > > Perhaps it would help if we defined a list of goals. I'll start. > > > > 1. $.ajax() - if dataType has not been defined in the argument list, > > $.ajax() should respect the returned Content-type header and translate > > accordingly. > > > > 2. .... > > > > > > Fill it in! > > > > > > > > > > Rick > > > > > > > > > > > > On Sun, Dec 27, 2009 at 7:41 PM, <webbied...@websiteguard.com> wrote: > > > >> We're struggling with the best way to inform .ajax() that we expect > >> multiple data types. Either, with a setting like "auto" or by passing an > >> array of data types (or maybe allowing both). > >> > >> > >> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <erik.bee...@gmail.com> > >> wrote: > >> > Seems like a lot of awkward wheel reinventing going on here. Content > >> > type negotiation is a feature of HTTP; is there a reason we aren't > >> > using it? > >> > > >> > --Erik > >> > > >> > > >> > On Saturday, December 26, 2009, webbiedave > >> > <webbied...@websiteguard.com> > >> > wrote: > >> >> "Following your idea that a library has to keep exactly the same > >> >> behavior from versions to versions [...] then what happens if & when > >> >> jQuery introduces a new auto-detectable dataType in 1.4.1" > >> >> > >> >> Things could break *without* the introduction of new auto-detectable > >> >> types. If you use "auto" and are only handling json and html and > >> >> suddenly javascript is returned, that javascript will be eval'd and > >> >> things will will not turn out well. That's why you can't use "auto" > on > >> >> untrusted/incompetent servers. That's the whole point of "auto". You > >> >> are trusting the server to return the correct data. Use at your own > >> >> risk. But it's there if you need it. > >> >> > >> >> Having said that, #1 in my suggestions is passing an array (dataType: > >> >> ["json", html"]). > >> >> > >> >> > >> >> > >> >> On Dec 26, 6:41 pm, Julian Aubourg <aubourg.jul...@gmail.com> wrote: > >> >>> > As I mentioned in my previous > >> >>> > post, one of this approach's downside is "null vs auto" confusion > >> >>> > as > >> >>> > auto is like null plus more (json, script, future accepted > >> dataTypes). > >> >>> > The whole point is that "auto" means auto-detect type via > >> content-type > >> >>> > headers and null does not mean that (it means guess between html > or > >> >>> > xml) > >> >>> > >> >>> This is exactly where the solution is inconsistent. > >> >>> > >> >>> "auto", in your implementation, does not mean "null plus more (json, > >> >>> script, > >> >>> *future accepted dataTypes*)" but it just means "null plus json & > >> >>> script" > >> >>> and only that. Following your idea that a library has to keep > exactly > >> >>> the > >> >>> same behavior from versions to versions (which jQuery broke btw when > >> >>> ditching the @ syntax for attributes in selectors) then what happens > >> >>> if > >> >>> & > >> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You > >> >>> create > >> >>> an "auto2" dataType so that existing code running in 1.4 is > >> >>> unaffected > >> >>> (ie: > >> >>> the new dataType is not auto-detected)? How would you document such > a > >> >>> behaviour? What happens when there's another auto-detectable > dataType > >> >>> introduced in 1.4.2? > >> >>> > >> >>> Giving programmers a way to specify exactly the dataTypes they > expect > >> to > >> >>> be > >> >>> auto-detected is the way to go (would it be with an array or an > >> >>> expression). > >> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code > and > >> >>> you're > >> >>> done: no backward compatibility issue... plus you're safe for future > >> >>> developments in the dataType auto-detection area. > >> >>> > >> >>> 2009/12/27 webbiedave <webbied...@websiteguard.com> > >> >>> > >> >>> > "Second, auto seems like the weirdest thing ever to me used like > it > >> is > >> >>> > here. So dataType==null and dataType=="auto" act the same for xml > >> >>> > but > >> >>> > not for script & json? Seems completely inconsistant to me." > >> >>> > >> >>> > It's not that weird. I don't think that different settings > yielding > >> >>> > different results is necessarily inconsistent. There are two ways > >> >>> > to > >> >>> > get xml and now there'll be a third. As I mentioned in my previous > >> >>> > post, one of this approach's downside is "null vs auto" confusion > >> >>> > as > >> >>> > auto is like null plus more (json, script, future accepted > >> dataTypes). > >> >>> > The whole point is that "auto" means auto-detect type via > >> content-type > >> >>> > headers and null does not mean that (it means guess between html > or > >> >>> > xml). It is imperative that the behavior of dataType: null remains > >> the > >> >>> > same so this is a way to do that while affording multiple expected > >> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break > >> >>> > existing apps. Quite frankly, it usage makes simple sense to me > and > >> >>> > those who need it will know exactly what it means and how to use > it > >> >>> > (and will be relieved they can ditch their hacked libraries). > >> >>> > >> >>> > "If a coder does not want auto conversion, then he simply > specifies > >> >>> > a > >> >>> > dataType (namely "text")." > >> >>> > >> >>> > But null does not mean auto convert. It means guess between html > or > >> >>> > xml and that cannot change. > >> >>> > >> >>> > "But, please, do not introduce a behavior that will act > differently > >> >>> > for xml than it does for any other dataType deduced from content > >> >>> > type > >> >>> > headers." > >> >>> > >> >>> > I admit I don't share your fear of such behavior and, in fact, > >> greatly > >> >>> > desire such a new setting. I'll know that my live apps that are > >> >>> > using > >> >>> > dataType: null will be unaffected and in the future I'd be able to > >> >>> > write ajax calls that can respond to various data types. Also, > I've > >> >>> > suggested several approaches and look forward to reading what > >> >>> > others > >> >>> > think of them. > >> >>> > >> >>> > On Dec 26, 3:47 pm, Julian Aubourg <aubourg.jul...@gmail.com> > >> >>> > wrote: > >> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach as > >> >>> > > it's easy to use/implement and affords enough control. > >> >>> > >> >>> > > Well, so, first, I translated the dataType to "auto" when it was > >> >>> > > null/undefined in my rewriting (because I hate messy/undefined > >> >>> > > values). > >> >>> > But > >> >>> > > that's no biggy. > >> >>> > >> >>> > > Second, auto seems like the weirdest thing ever to me used like > >> >>> > > it > >> >>> > > is > >> >>> > here. > >> >>> > > So dataType==null and dataType=="auto" act the same for xml but > >> >>> > > not > >> >>> > > for > >> >>> > > script & json? Seems completely inconsistant to me. > >> >>> > >> >>> > > If a coder does not want auto conversion, then he simply > >> >>> > > specifies > >> a > >> >>> > > dataType (namely "text"). You just have to document it. But, > >> please, > >> >>> > > do > >> >>> > not > >> >>> > > introduce a behavior that will act differentely for xml than it > >> does > >> >>> > > for > >> >>> > any > >> >>> > > other dataType deduced from content type headers. > >> >>> > >> >>> > > 2009/12/26 webbiedave <webbied...@websiteguard.com> > >> >>> > >> >>> > > > I was referring solely to the "bitwise or" style. Regardless, > >> >>> > > > I'm > >> >>> > > > leaning towards the dataType: "auto" approach as it's easy to > >> use/ > >> >>> > > > implement and affords enough control. > >> >>> > >> >>> > > > Julian Aubourg wrote: > >> >>> > >> >>> > > > > As for string expressions not being in the calling style of > >> >>> > > > > jQuery... > >> >>> > > > > well... I really disagree here, since jQuery has expression > >> >>> > > > > parsed > >> >>> > parsed > >> >>> > > > > pretty much everywhere ;) > >> >>> > >> >>> > > > -- > >> >>> > >> >>> > > > You received this message because you are subscribed to the > >> Google > >> >>> > Groups > >> >>> > > > "jQuery Development" group. > >> >>> > > > To post to this group, send email to > >> >>> > > > jquery-dev@googlegroups.com > >> . > >> >>> > > > To unsubscribe from this group, send email to > >> >>> > > > > > > >> > <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> > <jquery-dev%252bunsubscr...@googlegroups.com<jquery-dev%25252bunsubscr...@googlegroups.com> > > > >> > <jquery-dev%252bunsubscr...@googlegroups.com<jquery-dev%25252bunsubscr...@googlegroups.com> > <jquery-dev%25252bunsubscr...@googlegroups.com<jquery-dev%2525252bunsubscr...@googlegroups.com> > > > >> > > >> >>> > >> >>> > > > . > >> >>> > > > For more options, visit this group at > >> >>> > > >http://groups.google.com/group/jquery-dev?hl=en. > >> >>> > >> >>> > -- > >> >>> > >> >>> > You received this message because you are subscribed to the Google > >> >>> > Groups > >> >>> > "jQuery Development" group. > >> >>> > To post to this group, send email to jquery-...@googlegroups.com. > >> >>> > To unsubscribe from this group, send email to > >> >>> > > >> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> > <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> > > > >> > <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> > <jquery-dev%252bunsubscr...@googlegroups.com<jquery-dev%25252bunsubscr...@googlegroups.com> > > > >> > > >> >>> > . > >> >>> > For more options, visit this group at > >> >>> >http://groups.google.com/group/jquery-dev?hl=en. > >> >> > >> >> -- > >> >> > >> >> You received this message because you are subscribed to the Google > >> Groups > >> >> "jQuery Development" group. > >> >> To post to this group, send email to jquery-...@googlegroups.com. > >> >> To unsubscribe from this group, send email to > >> >> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> > <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> > > > >> . > >> >> For more options, visit this group at > >> >> http://groups.google.com/group/jquery-dev?hl=en. > >> >> > >> >> > >> >> > >> > > >> > -- > >> > > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "jQuery Development" group. > >> > To post to this group, send email to jquery-...@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> > <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> > > > >> . > >> > For more options, visit this group at > >> > http://groups.google.com/group/jquery-dev?hl=en. > >> > >> -- > >> > >> You received this message because you are subscribed to the Google > Groups > >> "jQuery Development" group. > >> To post to this group, send email to jquery-...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> > <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> > > > >> . > >> For more options, visit this group at > >> http://groups.google.com/group/jquery-dev?hl=en. > >> > >> > >> > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > "jQuery Development" group. > > To post to this group, send email to jquery-...@googlegroups.com. > > To unsubscribe from this group, send email to > > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> > . > > For more options, visit this group at > > http://groups.google.com/group/jquery-dev?hl=en. > > -- > > You received this message because you are subscribed to the Google Groups > "jQuery Development" group. > To post to this group, send email to jquery-...@googlegroups.com. > To unsubscribe from this group, send email to > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/jquery-dev?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
