Of course it is :) http://github.com/jaubourg/jquery
Still a work in progress. I plan a simplification of the ajax to transport communication but the general idea is implemented (I also need to implement a full xhr emulation -- including readyState & onreadystatechange events and the possibility to re-use the fake xhr after an ajax call is complete). Just take a look into the ajax unit tests to see what it can do. 2009/12/25 Rick Waldron <waldron.r...@gmail.com> > 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> >> <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<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<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.
