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.
