[jquery-dev] Re: jQueryLINT
Diego,
I think you're still not quite understanding what Dave is suggesting.
He is *not* saying everyone running jQuery would be subjected to these
checks.
He *is* saying there is a completely new build of jQuery (let's call
it jQuery-1.4.lint.js) that a developer could *choose* to run against
just to test out their code. And in the documentation, it could be
strongly urged that new developers try this at least once.
Heck, let's take it a step farther... how about jquery-1.4.newb.js
that has some sort of 'tutorial' built in when it sees bad practices?
At least that's how I've interpreted it :)
_jason
On Jan 15, 11:02 am, Diego Perini wrote:
> 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 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] Re: new version policies - specifically RE: sibling selector in 1.3.2
Ah. I wasn't aware of the 1.3.3 skip. Two to three months sounds fairly ideal. Go, go, go! Thanks for the follow-up. _jason On Nov 13, 3:15 pm, John Resig wrote: > The problem is that, at this point, we're going for 1.4 so it'll be > hard for us to integrate it immediately. > > Although, the solution that you outline isn't completely ideal, > either. Having too many releases causes users to never upgrade, for > fear of another release coming out soon. We've found that the optimal > release cycle is around 2-3 months for point release, 1 year for major > release. Of course we missed the 1.3.3 release, but that's mostly > because the team decided to push through and go straight for 1.4, > instead. > > --John > > On Fri, Nov 13, 2009 at 2:41 PM, Jason Persampieri wrote: > > Pardon me for being a little late to this particular party :) > > > I just ran in to the "Broken sibling selector in 1.3.2" bug that was > > discovered and fixed at the end of March (7 months ago!). I've worked > > around it by removing the blocks of code specified in the bug report > > and re-minifying it. But I wonder why I had to do that. > > > Why not release a version 1.3.3 (or 1.3.2.1) that fixes this? It's > > seems to be a very simple fix for a relatively major feature and could > > potentially save a lot of debugging time. Should *every* bug get a > > point release? Of course not. But 1.3.2 has been the 'latest stable > > release' for quite a while, no? > > > Honestly, it may be close enough to 1.3.3 (or whatever the next big > > version is) for this particular issue to matter, but for future > > development, this would make jQuery seem even more "production-ready" > > than it already is. > > > Just for context, I actually had to upgrade from 1.3.1 in order to fix > > the "clone of a clone" issue in IE. > > > _jason > > > -- > > > 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 > > athttp://groups.google.com/group/jquery-dev?hl=. -- 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=.
[jquery-dev] Re: $.ajax feature matrix
On Nov 13, 6:39 am, Scott Sauyet wrote:
> On Thu, Nov 12, 2009 at 1:15 PM, John Resig wrote:
> >> I think the one area that would be troublesome is in the properties
> >> that xhr provides (like readyState, responseXML, etc.). I'm not sure
> >> how you'd build this mock XHR and keep those properties up to date.
>
> On Thu, Nov 12, 2009 at 10:14 PM, Julian Aubourg
>
> wrote:
> > As an example of what I'm talking about with an real xhr as a base:
> > - layer 0 is window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") :
> > new XMLHttpRequest()
> > - layer 1 is a standard compliant xhr implementation that delegates to layer
> > 0 while hiding browser incompatibilities. It listens to layer 0 through its
> > onreadystatechange event handler and propagates the event by calling its own
> > onreadystatechange if available
>
> I had briefly mentioned a similar idea in the other thread [1], but
> was rather scared of the actual implementation. I guess the question
> is whether there are possible state changes to the underlying XHR
> object that might affect the properties but that are not exposed
> through the onreadystatechange handler. I don't have nearly the
> knowledge of XHR to answer this. If there aren't any, I think this is
> quite a good idea.
>
> -- Scott
>
> [1]http://tinyurl.com/yl2lqjz#msg_1fa4cac00dbcedcf
Well, then. I had started working on something similar, but much
simpler. I had planned to intercept the return value of $.ajax and
extend it with 'success' and 'error' functions. Of course, I hadn't
gotten to the point of actually testing this, so who knows if it would
have worked. Your solution sounds much more robust and forward
thinking. Very nice.
_jason
--
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=.
[jquery-dev] new version policies - specifically RE: sibling selector in 1.3.2
Pardon me for being a little late to this particular party :) I just ran in to the "Broken sibling selector in 1.3.2" bug that was discovered and fixed at the end of March (7 months ago!). I've worked around it by removing the blocks of code specified in the bug report and re-minifying it. But I wonder why I had to do that. Why not release a version 1.3.3 (or 1.3.2.1) that fixes this? It's seems to be a very simple fix for a relatively major feature and could potentially save a lot of debugging time. Should *every* bug get a point release? Of course not. But 1.3.2 has been the 'latest stable release' for quite a while, no? Honestly, it may be close enough to 1.3.3 (or whatever the next big version is) for this particular issue to matter, but for future development, this would make jQuery seem even more "production-ready" than it already is. Just for context, I actually had to upgrade from 1.3.1 in order to fix the "clone of a clone" issue in IE. _jason -- 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=.
[jquery-dev] Re: Calling callback in $.post & $.get on error
I agree with pretty much everything Julian said. And while I don't
have a problem with $.get(url, onSuccess, onError), I can see how this
isn't "jQuery-like".
Right now, $.get returns an XmlHttpRequest object. What if that
object were extended a bit?
$.get(url, callback).error( onError )
Or, heck, go even crazier all $.ajax calls return a jQueryAjax
Object (that responds to everything XmlHttpRequest objects do... for
backwards compatibility)... that could lead to
$.get(url).success( callback ).error( callback ).
Interestingly, this would lead to the ability to cleanly request a
resource, then define how you want to handle it later on, even after
it's already come back.
That's at least a *little* more jQuery-like :)
_jason
On Nov 9, 9:49 am, Julian Aubourg wrote:
> OK and well I guess, but I'll go back to my original statement too then:
> "simple cases don't protect from temporary connection and/or server
> shutdowns, do they?". Like I said, I will use $.ajax anyway, but let me
> re-iterate that simple in design (rather in signature here) does not mean
> suitable for simple cases. The OP problem is quite clear: for "serious work"
> (ie: in real world production), error handling is mandatory because no
> matter how simple the ajax call, error can (and will) occur. I'm afraid the
> simple cases you're refering to are nothing more than proof of concepts and
> I personally don't use jQuery to do prototypes but real world web sites.
>
> That being said, the current status of $.get and $.post also pushes
> developers into ignoring errors altogether which makes for plugins you have
> to modify (or just plain rewrite) for production use (sadly talking from
> experience here).
>
> Finally, handling error cases with $.ajaxError in that case is like crushing
> an egg with a grand piano.
>
> And before anybody jumps at my throat, let me say again that I mean no
> disrespect: I admire the work you guys put into jQuery and I shudder to
> imagine how I would develop without this fantastic toolbox but, as of today,
> $.get and $.post are not "write less, do more", they are "write less, do
> half the work".
>
> But well, what do I care? I never use them anyway ;)
>
> 2009/11/9 John Resig
>
> > Ok, so I go back to my original statement: "Really the get and post
> > methods are meant to be simple cases, everything else should be
> > tackled with the ajax method."
>
> > --John
>
> > On Mon, Nov 9, 2009 at 4:48 PM, Julian Aubourg
> > wrote:
> > > Well, to be honest, I never ever use $.get or $.put (or $.getJSON). The
> > main
> > > reason is that there is no error callback which, in my opinion, makes
> > them
> > > completely useless in any production environment.
>
> > > Now I understand the convention being broken argument, but the two
> > callback
> > > solution:
> > > - does not break current code, ever,
> > > - does not necessitate jQuery to create a special error callback that
> > will
> > > redirect to the dual callback function,
> > > - does not necessitate branching in user code.
>
> > > I dunno, but for helper functions, I'd be willing to sacrifice some api
> > > purity and have them really useful yet backward compatible. But, then
> > again,
> > > I never had the responsibility of anything that's became as huge as
> > jQuery,
> > > so...
>
> > > 2009/11/9 John Resig
>
> > >> > Wouldn't it still break some scripts that actually expect the data
> > never
> > >> > to
> > >> > be undefined?
>
> > >> As I mentioned before - the application would just break in a
> > >> different way. Normally it would break in that the result would never
> > >> come in - now it would throw an exception (again, that's assuming that
> > >> if they're trying to do something directly with the object - a more
> > >> likely result is seeing "null" outputted somewhere).
>
> > >> > Why not the following:
>
> > >> > $.get("someurl", function(data) {
> > >> > // got results
> > >> > }, function(errorMessage) {
> > >> > // got error
> > >> > });
>
> > >> > That way, actual scripts behave as usual and new ones can provide an
> > >> > error
> > >> > callback.
>
> > >> > Thoughts?
>
> > >> I'm not a huge fan of this - having dual functions being passed in as
> > >> arguments is messy and against the current jQuery conventions. I feel
> > >> like if you're passing in so many functions why not just use $.ajax
> > >> and be done with it? Especially since $.ajax is so much more explicit
> > >> any way.
>
> > >> Either we should find a simple solution (like what I proposed) or do
> > >> no change at all.
>
> > >> --John
>
> > >> --
>
> > >> 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.
>
> > >
[jquery-dev] Re: jQuery(document).ready() Type error on WebKit based Browsers
Makes sense to me. I am slowly converting lots of our old JS from
Prototype. A platform of old Prototype and new jQuery makes Jason a
stressed-out programmer.
Thanks for the info.
On May 18, 10:36 am, John Resig wrote:
> Jason -
>
> I'm not sure if this is something that we want to handle, specifically
> (especially since that method has already been removed in current versions
> of Prototype).
>
> --John
>
> On Mon, May 18, 2009 at 1:27 PM, Jason Persampieri wrote:
>
>
>
> > (Solution found... more info provided for future searchers)
>
> > After completely ignoring this over the weekend, the answer was
> > blindingly obvious this morning. For legacy reasons, Prototype was
> > being included... and it was being included before jquery. Hence,
> > element.getElementsByClassName was some Prototype-bastardized
> > version. Moving the jQuery load before Prototype fixed the problem.
>
> > For the jquery devs, is this something that should (can) be detected
> > or worked-around?
>
> > _jason
>
> > On May 14, 9:57 am, Jason Persampieri wrote:
> > > (cross-posted on the users' group... hope this is the correct forum)
>
> > > My site works fine on Firefox and IE, but on Webkit-based browsers,
> > > any call to jQuery(function() {}) results in this error on line 83 of
> > > jquery-1.3.2.js --
>
> > > TypeError: Result of expression 'jQuery( document ).ready' [undefined]
> > > is not a function
>
> > > Basically, the jQuery.fn object is not getting extended with ready,
> > > hover, etc I have isolated the actual crash to line 2238 of
> > > jquery-1.3.2.js.
>
> > > if ( div.getElementsByClassName("e").length === 0 )
> > > return;
>
> > > I threw a try/catch block around the code and receive this exception -
>
> > > NOT_SUPPORTED_ERR: DOM Exception 9
>
> > > I am currently running Safari Version 4 Public Beta (5528.16), but
> > > apparently this bug is occurring in v3 as well (and of course,
> > > Chrome).
>
> > > By ignoring exceptions generated from the above, and the equivalent
> > > line 2 statements later, my page loads and everything executes
> > > perfectly.
>
> > > _jason
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@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
-~--~~~~--~~--~--~---
[jquery-dev] Re: jQuery(document).ready() Type error on WebKit based Browsers
(Solution found... more info provided for future searchers)
After completely ignoring this over the weekend, the answer was
blindingly obvious this morning. For legacy reasons, Prototype was
being included... and it was being included before jquery. Hence,
element.getElementsByClassName was some Prototype-bastardized
version. Moving the jQuery load before Prototype fixed the problem.
For the jquery devs, is this something that should (can) be detected
or worked-around?
_jason
On May 14, 9:57 am, Jason Persampieri wrote:
> (cross-posted on the users' group... hope this is the correct forum)
>
> My site works fine on Firefox and IE, but on Webkit-based browsers,
> any call to jQuery(function() {}) results in this error on line 83 of
> jquery-1.3.2.js --
>
> TypeError: Result of expression 'jQuery( document ).ready' [undefined]
> is not a function
>
> Basically, the jQuery.fn object is not getting extended with ready,
> hover, etc I have isolated the actual crash to line 2238 of
> jquery-1.3.2.js.
>
> if ( div.getElementsByClassName("e").length === 0 )
> return;
>
> I threw a try/catch block around the code and receive this exception -
>
> NOT_SUPPORTED_ERR: DOM Exception 9
>
> I am currently running Safari Version 4 Public Beta (5528.16), but
> apparently this bug is occurring in v3 as well (and of course,
> Chrome).
>
> By ignoring exceptions generated from the above, and the equivalent
> line 2 statements later, my page loads and everything executes
> perfectly.
>
> _jason
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@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
-~--~~~~--~~--~--~---
[jquery-dev] jQuery(document).ready() Type error on WebKit based Browsers
(cross-posted on the users' group... hope this is the correct forum)
My site works fine on Firefox and IE, but on Webkit-based browsers,
any call to jQuery(function() {}) results in this error on line 83 of
jquery-1.3.2.js --
TypeError: Result of expression 'jQuery( document ).ready' [undefined]
is not a function
Basically, the jQuery.fn object is not getting extended with ready,
hover, etc I have isolated the actual crash to line 2238 of
jquery-1.3.2.js.
if ( div.getElementsByClassName("e").length === 0 )
return;
I threw a try/catch block around the code and receive this exception -
NOT_SUPPORTED_ERR: DOM Exception 9
I am currently running Safari Version 4 Public Beta (5528.16), but
apparently this bug is occurring in v3 as well (and of course,
Chrome).
By ignoring exceptions generated from the above, and the equivalent
line 2 statements later, my page loads and everything executes
perfectly.
_jason
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@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
-~--~~~~--~~--~--~---
