@Dave : thanks, you got it right Also, jQueryLINT is not a plugin, it is version of jQuery itself. With checks all over the place inside ... If that effort is owned by jQuery team and efforts channelled, this should be a great help for addressing the user related issues ... And this will make everyone's lives much easier , the team and the rest...
--DBJ On Jan 15, 5:31 pm, Dave Methvin <dave.meth...@gmail.com> wrote: > > "Not technically demanding" uh? > > I beg to differ on this one. > > Conceptually it's a simple idea: Inspect the parameters being passed > to jQuery and its methods, then see if they match the API signature > and follow good practice. I started on it years ago but punted (hides > head in shame) because it was a lot of work, especially at that time > when the jQuery API was changing > quickly:http://markmail.org/message/wzkosk2s5jklpkv4 > > > First of all, what would the criteria be? > > Whatever the author thought was bad practice or a possible mistake. If > you've ever used the original jslint (http://www.jslint.com/) or the > (imo) better javascriptlint (http://www.javascriptlint.com/), you know > that lint occasionally complains about things that are not outright > errors but sometimes indicate problems or are just bad style. The $ > ("*") case that dbj mentioned is a good one. It's not an error but it > is generally not good to do something to every element on the page. I > also would flag the case of $("myid") versus the intended $("#myid") > on non-xml docs if the selector didn't return any elements--that's a > mistake I make a few times a month. > > > pretty much all of the JQuery classes and functions can use > > server side tags and code. > > I think dbj was proposing runtime analysis, not static analysis as > used with tools like jslint. By the time the jQuery code is called, > any server-side tags and code is irrelevant for the kind of checks > you'd want to do. > > > The library has *no* knowledge(and rightfully so, imho) of what tags > > and/or selectors will be used. > > True, so the messages it gives aren't going to be 100% correct in all > cases. That's okay, the developer needs to look at the messages and > decide whether it's found a problem or not. The volume of messages > could be controllable via options. See the lints above for examples of > how to do it. > > > This would slow things down *A LOT* with many checks. > > Performance could definitely be an issue; if the page gets 10 times > slower with jquery-lint, people aren't likely to use it regularly for > day-to-day development. But even if it *was* 10 times slower, it could > still be useful because when people come to a forum complaining their > code doesn't work we could point them to jquery-lint.js and tell them > to look for problems using that first. > > > Fourth: plug-ins would have to do the same checks. > > A plugin author could certainly write a linted version of their own > code, but if they include jquery-lint.js in the page the plugin will > automatically get the lint features for any jQuery methods it calls. > > > Fifth: *ANYONE* using improper selectors or using JQuery improperly > > deserves his/her fate. Reading the docs is the first thing you should do. > > It's easy to make mistakes, even if the docs are good and you read > them well. As I said in that old thread, "I would be embarrassed to > tell you how many times I've said $("myid") when I meant $("#myid") > and spent 10 minutes trying to figure out what was broken." A lint > tool helps find those mistakes, and people can learn things by reading > its advice which is always a good thing. It's like a code review in a > Javascript file.
-- 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.
