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-...@googlegroups.com. >>> > > > To unsubscribe from this group, send email to >>> > > > > > <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. >> 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. -- 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.
