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