Julian, is your rewrite of ajax.js available for peer preview anywhere? I'm really curious to see what you're cooking up
Rick -- Sent from my Palm Prē Julian Aubourg wrote: First of all, merry christmas ;) This affords the most control but may be difficult to implement elegantly as the obvious choice of an array has already been taken by other functionality. Julian suggested an "or" like string but I'm of the opinion that such a calling style is not cohesive enough with the rest of jquery usage. I'd say yes and no. I didn't brought the array issue as something "forbidden" but I rather wanted to let everyone know the current state of my ajax rewriting makes use of them. If you were to use arrays for multiple possible dataTypes, then you'd end up with arrays in array... ie: [ [ json, xml ] , otherDataType ]. 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 ;) Anyway, this gave me the idea of symplifying my current transformation chain system and go for something like: "json > otherDataType" which could be used as "json | xml > otherDataType" and make things much clearer than arrays imo. But I'm on my mom's comp here... and it's slow as hell and I don't have time to work on all this right now anyway. 2009/12/24 webbiedave <webbied...@websiteguard.com> I'm also a bit curious as to how I'm going to implement this as I wasn't aware there was already an effort underway to have dataTypes accept an array for a different purpose. The "why" is that I don't want to have to limit my returned data to be exclusively either html or json. Much of this can be taken care of on a case-by-case basis in the complete callback but that requires duplicating much of what httpData does. So, if my original suggested code (similar to Rick's) is fine with everyone, then great! But Tobias then brought up the issue of server competence when auto-evaling json so I began looking for a way to explicitly specify multiple datatypes. Below are some approaches for allowing varying datatypes (you can skip to the conclusion below if you want the short story): 1) Create some way to pass multiple expected dataTypes and httpData will do its best to detect which was received. This affords the most control but may be difficult to implement elegantly as the obvious choice of an array has already been taken by other functionality. Julian suggested an "or" like string but I'm of the opinion that such a calling style is not cohesive enough with the rest of jquery usage. 2) Detect and parse data as json when: content-type == "application/json" && !dataType This was my original suggestion. It could -- and has already-- brought about some unease from developers as it isn't out of the realm of possibility that scripts could be eval'd when dataType isn't specified. 3) Detect and parse data as json when: content-type == "application/json" && !dataType && parser is available This approach deserves a scolding as it alters application behavior depending on whether or not a json parser is present. 4) Detect and parse data as json when: content-type == "application/json" && !dataType && autoEval (some new option that will parse script/json if received) Yields documentation like "autoEval will only parse the returned content when set to true and dataType has not been specified." Its usage is strange. 5) Detect and parse data as json when: content-type == "application/json" && autoEval Completely ignores datatype and will eval with code like: dataType: "html", autoEval: true. That just doesn't look great. 6) dataType: "auto". httpData will detect xml, html, text, script or json via content-type header. This could cause some confusion for developers when they're initially learning the difference between "auto" and dataType's default behavior (xml/html). Obviously, people using this setting should ensure they are calling trusted, competent servers. 7) dataType: "auto" and autoEval (defaults to true). Setting autoEval to false returns script/json as text. In practice, with the currently allowed dataTypes, you'll just be using dataType's default behavior instead of typing dataType: "auto", autoEval: false. CONCLUSION: There's something to hate about all of them. I like #6. When you use it, you know exactly what kind of trouble you're getting yourself into. On Dec 23, 5:28 pm, Julian Aubourg <aubourg.jul...@gmail.com> wrote: > I'm a bit curious as to how (and why) you intend to implement this, seeing > as the ajax revamping I've been working on uses an array of dataTypes. > > For example s.datTypes = ["jsonp","xml"] means: get an object (a string in > that case) over jsonp that'll get parsed as xml (and this is actually > working and being unit tested ;)) > > If your intention is to give a list of accepted dataTypes, I'd rather go for > a string of the form "json | xml" if you get my idea. > > 2009/12/23 webbiedave <webbied...@websiteguard.com> > > > I'll rewrite so dataType can also accept an array. That way there's > > explicitness. I'll report back after some real world usage. > > > On Dec 23, 3:56 am, Tobias Hoffmann <smilingt...@googlemail.com> > > wrote: > > > On Wed, Dec 23, 2009 at 5:16 AM, John Resig <jere...@gmail.com> wrote: > > > > Is there an open ticket on this? If so I don't see a reason not to land > > it. > > > > Well, if there is no safe json decoder (i.e. just eval()) it's not > > > immediatly clear to me, that I really want this. > > > Yes, all the other jscripts also come from the server and are thus > > somehow > > > equally trustworthy. > > > And the Content-Type on the HTTP header can not easily be spoofed. But I > > > don't want jquery to evaluate some > > > unsafe user content (e.g. CMS, Guestbook, ... ) that wasn't ever meant to > > be > > > json ... > > > > Tobias > > > > > Could we change the $.ajax() function to treat the server's response > > > > > as json if dataType is unspecified and the response content-type is > > > > > "application/json"? > > > > > > Thanks, > > > > > Dave > > > -- > > > 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.
