"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+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. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
