Dave,
I completely agree with Andrea Raimondi above and everything he said
make sense to me.
Why should we inflict these no sense conditionals onto everybody.
Should we then check every parameter of every method too, just to be
helpful to one people not remembering signatures or lazy to lookup a
documentation page ?
Not useful, none of those checks should be in core, if necessary, for
DBJ and people needing that, an external checker will be ok, I would
not like to be the one writing that though :-) Those writing $('*')
should be returned what they asked, it is "incorrect" to assume
everybody is a beginner and "time wasting" trying to guess what they
would do with those selectors.
Diego
On 15 Gen, 18:31, 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.
