"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+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.
