bug in jQuery 1.4rc1

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug in jQuery 1.4rc1

Jonas Åradsson
Hey jQuery team

I got the attached error when I substituted jQuery 1.3.2 with 1.4 rc1.

A working example of the same page running 1.3.2 can be found here:
http://www.boliga.dk/map.aspx?id=374261

Regards
/Jonas

----------------------------------------
Boliga
Jonas Åradsson
Partner and founder

[hidden email]

TEL +45 4358 3071
MOB +45 4099 2636

Boliga ApS
Blegdamsvej 104 A, 2.
2100 København Ø

www.boliga.dk


--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

1.4rc1-error.JPG (171K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: bug in jQuery 1.4rc1

John Resig
Administrator
Hello -

This is due to the fact that we removed the ability to bind data()
(and thus events) to object, embed, and applet elements in 1.4.
Allowing it was causing uncatchable exceptions to be thrown when used
along with with Java applets.

The commit:
http://github.com/jquery/jquery/commit/59802928566b6be3a66d65e77c2418fff37e6f5f

Looking at your code I see:
                $("*").keypress(function(e) {
                        if (e.which == 13) {
                                Login();
                        }
                });

You should probably change that to (not only will it be significantly
faster but it'll work just fine with 1.4rc1):
                $(document).keypress(function(e) {
                        if (e.which == 13) {
                                Login();
                        }
                });

Regardless, I just landed a fix to make sure that no exception is
thrown (silently fails instead).
http://github.com/jquery/jquery/commit/1960f28c0bf75b16e88460d6135058fd93202322

--John



On Wed, Jan 13, 2010 at 10:13 AM, Jonas Åradsson
<[hidden email]> wrote:

> Hey jQuery team
>
> I got the attached error when I substituted jQuery 1.3.2 with 1.4 rc1.
>
> A working example of the same page running 1.3.2 can be found here:
> http://www.boliga.dk/map.aspx?id=374261
>
> Regards
> /Jonas
>
> ----------------------------------------
> Boliga
> Jonas Åradsson
> Partner and founder
>
> [hidden email]
> TEL +45 4358 3071
> MOB +45 4099 2636
>
> Boliga ApS
> Blegdamsvej 104 A, 2.
> 2100 København Ø
>
> www.boliga.dk
> LinkedinFacebookTwitter
>
> --
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: bug in jQuery 1.4rc1

DBJDBJ
@John : your patience has no limits ...

Although "silent failures" are a "big no-no" in computing, since
primordial times ?

Nice and fresh text :
http://partnerteamblog.shavlik.com/2009/09/02/the-silent-failure-that-leads-to-the-destruction-of-the-system/

And something *much* closer to jQuery users :
http://cafe.elharo.com/programming/in-praise-of-draconian-error-handling-part-1/

1.5 perhaps ...

On Jan 13, 4:26 pm, John Resig <[hidden email]> wrote:

> Hello -
>
> This is due to the fact that we removed the ability to bind data()
> (and thus events) to object, embed, and applet elements in 1.4.
> Allowing it was causing uncatchable exceptions to be thrown when used
> along with with Java applets.
>
> The commit:http://github.com/jquery/jquery/commit/59802928566b6be3a66d65e77c2418...
>
> Looking at your code I see:
>                 $("*").keypress(function(e) {
>                         if (e.which == 13) {
>                                 Login();
>                         }                      
>                 });
>
> You should probably change that to (not only will it be significantly
> faster but it'll work just fine with 1.4rc1):
>                 $(document).keypress(function(e) {
>                         if (e.which == 13) {
>                                 Login();
>                         }                      
>                 });
>
> Regardless, I just landed a fix to make sure that no exception is
> thrown (silently fails instead).http://github.com/jquery/jquery/commit/1960f28c0bf75b16e88460d6135058...
>
> --John
>
> On Wed, Jan 13, 2010 at 10:13 AM, Jonas Åradsson
>
>
>
> <[hidden email]> wrote:
> > Hey jQuery team
>
> > I got the attached error when I substituted jQuery 1.3.2 with 1.4 rc1.
>
> > A working example of the same page running 1.3.2 can be found here:
> >http://www.boliga.dk/map.aspx?id=374261
>
> > Regards
> > /Jonas
>
> > ----------------------------------------
> > Boliga
> > Jonas Åradsson
> > Partner and founder
>
> > [hidden email]
> > TEL +45 4358 3071
> > MOB +45 4099 2636
>
> > Boliga ApS
> > Blegdamsvej 104 A, 2.
> > 2100 København Ø
>
> >www.boliga.dk
> > LinkedinFacebookTwitter
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jQuery Development" group.
> > To post to this group, send email to [hidden email].
> > To unsubscribe from this group, send email to
> > [hidden email].
> > 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: Re: bug in jQuery 1.4rc1

John Resig
Administrator
Well, before we had a very "non-silent" failure - and that was causing
his, and others, applications to break. I'm a firm believer that good
documentation is a proper anecdote to silence (hence the API docs are
updated to mention this change in 1.4 and it'll be in the release
notes).

--John

On Wed, Jan 13, 2010 at 11:40 AM, DBJDBJ <[hidden email]> wrote:

> @John : your patience has no limits ...
>
> Although "silent failures" are a "big no-no" in computing, since
> primordial times ?
>
> Nice and fresh text :
> http://partnerteamblog.shavlik.com/2009/09/02/the-silent-failure-that-leads-to-the-destruction-of-the-system/
>
> And something *much* closer to jQuery users :
> http://cafe.elharo.com/programming/in-praise-of-draconian-error-handling-part-1/
>
> 1.5 perhaps ...
>
> On Jan 13, 4:26 pm, John Resig <[hidden email]> wrote:
>> Hello -
>>
>> This is due to the fact that we removed the ability to bind data()
>> (and thus events) to object, embed, and applet elements in 1.4.
>> Allowing it was causing uncatchable exceptions to be thrown when used
>> along with with Java applets.
>>
>> The commit:http://github.com/jquery/jquery/commit/59802928566b6be3a66d65e77c2418...
>>
>> Looking at your code I see:
>>                 $("*").keypress(function(e) {
>>                         if (e.which == 13) {
>>                                 Login();
>>                         }
>>                 });
>>
>> You should probably change that to (not only will it be significantly
>> faster but it'll work just fine with 1.4rc1):
>>                 $(document).keypress(function(e) {
>>                         if (e.which == 13) {
>>                                 Login();
>>                         }
>>                 });
>>
>> Regardless, I just landed a fix to make sure that no exception is
>> thrown (silently fails instead).http://github.com/jquery/jquery/commit/1960f28c0bf75b16e88460d6135058...
>>
>> --John
>>
>> On Wed, Jan 13, 2010 at 10:13 AM, Jonas Åradsson
>>
>>
>>
>> <[hidden email]> wrote:
>> > Hey jQuery team
>>
>> > I got the attached error when I substituted jQuery 1.3.2 with 1.4 rc1.
>>
>> > A working example of the same page running 1.3.2 can be found here:
>> >http://www.boliga.dk/map.aspx?id=374261
>>
>> > Regards
>> > /Jonas
>>
>> > ----------------------------------------
>> > Boliga
>> > Jonas Åradsson
>> > Partner and founder
>>
>> > [hidden email]
>> > TEL +45 4358 3071
>> > MOB +45 4099 2636
>>
>> > Boliga ApS
>> > Blegdamsvej 104 A, 2.
>> > 2100 København Ø
>>
>> >www.boliga.dk
>> > LinkedinFacebookTwitter
>>
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "jQuery Development" group.
>> > To post to this group, send email to [hidden email].
>> > To unsubscribe from this group, send email to
>> > [hidden email].
>> > 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 [hidden email].
> To unsubscribe from this group, send email to [hidden email].
> 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: bug in jQuery 1.4rc1

ajpiano
The fact that $("*").bind() is WAY worse than $(document).bind()
really ought to be shouted from the rooftops.


On Jan 13, 11:46 am, John Resig <[hidden email]> wrote:

> Well, before we had a very "non-silent" failure - and that was causing
> his, and others, applications to break. I'm a firm believer that good
> documentation is a proper anecdote to silence (hence the API docs are
> updated to mention this change in 1.4 and it'll be in the release
> notes).
>
> --John
>
>
>
> On Wed, Jan 13, 2010 at 11:40 AM, DBJDBJ <[hidden email]> wrote:
> > @John : your patience has no limits ...
>
> > Although "silent failures" are a "big no-no" in computing, since
> > primordial times ?
>
> > Nice and fresh text :
> >http://partnerteamblog.shavlik.com/2009/09/02/the-silent-failure-that...
>
> > And something *much* closer to jQuery users :
> >http://cafe.elharo.com/programming/in-praise-of-draconian-error-handl...
>
> > 1.5 perhaps ...
>
> > On Jan 13, 4:26 pm, John Resig <[hidden email]> wrote:
> >> Hello -
>
> >> This is due to the fact that we removed the ability to bind data()
> >> (and thus events) to object, embed, and applet elements in 1.4.
> >> Allowing it was causing uncatchable exceptions to be thrown when used
> >> along with with Java applets.
>
> >> The commit:http://github.com/jquery/jquery/commit/59802928566b6be3a66d65e77c2418...
>
> >> Looking at your code I see:
> >>                 $("*").keypress(function(e) {
> >>                         if (e.which == 13) {
> >>                                 Login();
> >>                         }
> >>                 });
>
> >> You should probably change that to (not only will it be significantly
> >> faster but it'll work just fine with 1.4rc1):
> >>                 $(document).keypress(function(e) {
> >>                         if (e.which == 13) {
> >>                                 Login();
> >>                         }
> >>                 });
>
> >> Regardless, I just landed a fix to make sure that no exception is
> >> thrown (silently fails instead).http://github.com/jquery/jquery/commit/1960f28c0bf75b16e88460d6135058...
>
> >> --John
>
> >> On Wed, Jan 13, 2010 at 10:13 AM, Jonas Åradsson
>
> >> <[hidden email]> wrote:
> >> > Hey jQuery team
>
> >> > I got the attached error when I substituted jQuery 1.3.2 with 1.4 rc1.
>
> >> > A working example of the same page running 1.3.2 can be found here:
> >> >http://www.boliga.dk/map.aspx?id=374261
>
> >> > Regards
> >> > /Jonas
>
> >> > ----------------------------------------
> >> > Boliga
> >> > Jonas Åradsson
> >> > Partner and founder
>
> >> > [hidden email]
> >> > TEL +45 4358 3071
> >> > MOB +45 4099 2636
>
> >> > Boliga ApS
> >> > Blegdamsvej 104 A, 2.
> >> > 2100 København Ø
>
> >> >www.boliga.dk
> >> > LinkedinFacebookTwitter
>
> >> > --
> >> > You received this message because you are subscribed to the Google Groups
> >> > "jQuery Development" group.
> >> > To post to this group, send email to [hidden email].
> >> > To unsubscribe from this group, send email to
> >> > [hidden email].
> >> > 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 [hidden email].
> > To unsubscribe from this group, send email to [hidden email].
> > For more options, visit this group athttp://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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: bug in jQuery 1.4rc1

Jonas Åradsson
@John

Thx a lot for the help, excellent service :)



On Jan 13, 8:16 pm, ajpiano <[hidden email]> wrote:

> The fact that $("*").bind() is WAY worse than $(document).bind()
> really ought to be shouted from the rooftops.
>
> On Jan 13, 11:46 am, John Resig <[hidden email]> wrote:
>
> > Well, before we had a very "non-silent" failure - and that was causing
> > his, and others, applications to break. I'm a firm believer that good
> > documentation is a proper anecdote to silence (hence the API docs are
> > updated to mention this change in 1.4 and it'll be in the release
> > notes).
>
> > --John
>
> > On Wed, Jan 13, 2010 at 11:40 AM, DBJDBJ <[hidden email]> wrote:
> > > @John : your patience has no limits ...
>
> > > Although "silent failures" are a "big no-no" in computing, since
> > > primordial times ?
>
> > > Nice and fresh text :
> > >http://partnerteamblog.shavlik.com/2009/09/02/the-silent-failure-that...
>
> > > And something *much* closer to jQuery users :
> > >http://cafe.elharo.com/programming/in-praise-of-draconian-error-handl...
>
> > > 1.5 perhaps ...
>
> > > On Jan 13, 4:26 pm, John Resig <[hidden email]> wrote:
> > >> Hello -
>
> > >> This is due to the fact that we removed the ability to bind data()
> > >> (and thus events) to object, embed, and applet elements in 1.4.
> > >> Allowing it was causing uncatchable exceptions to be thrown when used
> > >> along with with Java applets.
>
> > >> The commit:http://github.com/jquery/jquery/commit/59802928566b6be3a66d65e77c2418...
>
> > >> Looking at your code I see:
> > >>                 $("*").keypress(function(e) {
> > >>                         if (e.which == 13) {
> > >>                                 Login();
> > >>                         }
> > >>                 });
>
> > >> You should probably change that to (not only will it be significantly
> > >> faster but it'll work just fine with 1.4rc1):
> > >>                 $(document).keypress(function(e) {
> > >>                         if (e.which == 13) {
> > >>                                 Login();
> > >>                         }
> > >>                 });
>
> > >> Regardless, I just landed a fix to make sure that no exception is
> > >> thrown (silently fails instead).http://github.com/jquery/jquery/commit/1960f28c0bf75b16e88460d6135058...
>
> > >> --John
>
> > >> On Wed, Jan 13, 2010 at 10:13 AM, Jonas Åradsson
>
> > >> <[hidden email]> wrote:
> > >> > Hey jQuery team
>
> > >> > I got the attached error when I substituted jQuery 1.3.2 with 1.4 rc1.
>
> > >> > A working example of the same page running 1.3.2 can be found here:
> > >> >http://www.boliga.dk/map.aspx?id=374261
>
> > >> > Regards
> > >> > /Jonas
>
> > >> > ----------------------------------------
> > >> > Boliga
> > >> > Jonas Åradsson
> > >> > Partner and founder
>
> > >> > [hidden email]
> > >> > TEL +45 4358 3071
> > >> > MOB +45 4099 2636
>
> > >> > Boliga ApS
> > >> > Blegdamsvej 104 A, 2.
> > >> > 2100 København Ø
>
> > >> >www.boliga.dk
> > >> > LinkedinFacebookTwitter
>
> > >> > --
> > >> > You received this message because you are subscribed to the Google Groups
> > >> > "jQuery Development" group.
> > >> > To post to this group, send email to [hidden email].
> > >> > To unsubscribe from this group, send email to
> > >> > [hidden email].
> > >> > 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 [hidden email].
> > > To unsubscribe from this group, send email to [hidden email].
> > > For more options, visit this group athttp://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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: Re: bug in jQuery 1.4rc1

wycats
In reply to this post by ajpiano
Do people not know that $("*").anything is very slow?

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325


On Wed, Jan 13, 2010 at 2:16 PM, ajpiano <[hidden email]> wrote:
The fact that $("*").bind() is WAY worse than $(document).bind()
really ought to be shouted from the rooftops.


On Jan 13, 11:46 am, John Resig <[hidden email]> wrote:
> Well, before we had a very "non-silent" failure - and that was causing
> his, and others, applications to break. I'm a firm believer that good
> documentation is a proper anecdote to silence (hence the API docs are
> updated to mention this change in 1.4 and it'll be in the release
> notes).
>
> --John
>
>
>
> On Wed, Jan 13, 2010 at 11:40 AM, DBJDBJ <[hidden email]> wrote:
> > @John : your patience has no limits ...
>
> > Although "silent failures" are a "big no-no" in computing, since
> > primordial times ?
>
> > Nice and fresh text :
> >http://partnerteamblog.shavlik.com/2009/09/02/the-silent-failure-that...
>
> > And something *much* closer to jQuery users :
> >http://cafe.elharo.com/programming/in-praise-of-draconian-error-handl...
>
> > 1.5 perhaps ...
>
> > On Jan 13, 4:26 pm, John Resig <[hidden email]> wrote:
> >> Hello -
>
> >> This is due to the fact that we removed the ability to bind data()
> >> (and thus events) to object, embed, and applet elements in 1.4.
> >> Allowing it was causing uncatchable exceptions to be thrown when used
> >> along with with Java applets.
>
> >> The commit:http://github.com/jquery/jquery/commit/59802928566b6be3a66d65e77c2418...
>
> >> Looking at your code I see:
> >>                 $("*").keypress(function(e) {
> >>                         if (e.which == 13) {
> >>                                 Login();
> >>                         }
> >>                 });
>
> >> You should probably change that to (not only will it be significantly
> >> faster but it'll work just fine with 1.4rc1):
> >>                 $(document).keypress(function(e) {
> >>                         if (e.which == 13) {
> >>                                 Login();
> >>                         }
> >>                 });
>
> >> Regardless, I just landed a fix to make sure that no exception is
> >> thrown (silently fails instead).http://github.com/jquery/jquery/commit/1960f28c0bf75b16e88460d6135058...
>
> >> --John
>
> >> On Wed, Jan 13, 2010 at 10:13 AM, Jonas Åradsson
>
> >> <[hidden email]> wrote:
> >> > Hey jQuery team
>
> >> > I got the attached error when I substituted jQuery 1.3.2 with 1.4 rc1.
>
> >> > A working example of the same page running 1.3.2 can be found here:
> >> >http://www.boliga.dk/map.aspx?id=374261
>
> >> > Regards
> >> > /Jonas
>
> >> > ----------------------------------------
> >> > Boliga
> >> > Jonas Åradsson
> >> > Partner and founder
>
> >> > [hidden email]
> >> > TEL +45 4358 3071
> >> > MOB +45 4099 2636
>
> >> > Boliga ApS
> >> > Blegdamsvej 104 A, 2.
> >> > 2100 København Ø
>
> >> >www.boliga.dk
> >> > LinkedinFacebookTwitter
>
> >> > --
> >> > You received this message because you are subscribed to the Google Groups
> >> > "jQuery Development" group.
> >> > To post to this group, send email to [hidden email].
> >> > To unsubscribe from this group, send email to
> >> > [hidden email].
> >> > 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 [hidden email].
> > To unsubscribe from this group, send email to [hidden email].
> > For more options, visit this group athttp://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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

jQueryLINT

DBJDBJ
Imagine having a version of jQuery which will tell you that your code
is slow,bad etc ... ?
jQueryLINT
That would not be technically demanding but would be very usefull ...
Just a "slector analyzer" interceptor inside $() would be truly
usefull ...

if ( selector === "*" ) console.warn("Are you really sure you want to
do $('*') ?") ;

Or inside bind() :

if ( jqLint.not_suitable_for_binding( this.selector ) ) console.warn
("Are you relly sure you want to bind to " + this.selector )

--DBJ

On Jan 14, 2:49 pm, Yehuda Katz <[hidden email]> wrote:

> Do people not know that $("*").anything is very slow?
>
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
>
>
> On Wed, Jan 13, 2010 at 2:16 PM, ajpiano <[hidden email]> wrote:
> > The fact that $("*").bind() is WAY worse than $(document).bind()
> > really ought to be shouted from the rooftops.
>
> > On Jan 13, 11:46 am, John Resig <[hidden email]> wrote:
> > > Well, before we had a very "non-silent" failure - and that was causing
> > > his, and others, applications to break. I'm a firm believer that good
> > > documentation is a proper anecdote to silence (hence the API docs are
> > > updated to mention this change in 1.4 and it'll be in the release
> > > notes).
>
> > > --John
>
> > > On Wed, Jan 13, 2010 at 11:40 AM, DBJDBJ <[hidden email]> wrote:
> > > > @John : your patience has no limits ...
>
> > > > Although "silent failures" are a "big no-no" in computing, since
> > > > primordial times ?
>
> > > > Nice and fresh text :
> > > >http://partnerteamblog.shavlik.com/2009/09/02/the-silent-failure-that.
> > ..
>
> > > > And something *much* closer to jQuery users :
> > > >http://cafe.elharo.com/programming/in-praise-of-draconian-error-handl.
> > ..
>
> > > > 1.5 perhaps ...
>
> > > > On Jan 13, 4:26 pm, John Resig <[hidden email]> wrote:
> > > >> Hello -
>
> > > >> This is due to the fact that we removed the ability to bind data()
> > > >> (and thus events) to object, embed, and applet elements in 1.4.
> > > >> Allowing it was causing uncatchable exceptions to be thrown when used
> > > >> along with with Java applets.
>
> > > >> The commit:
> >http://github.com/jquery/jquery/commit/59802928566b6be3a66d65e77c2418...
>
> > > >> Looking at your code I see:
> > > >>                 $("*").keypress(function(e) {
> > > >>                         if (e.which == 13) {
> > > >>                                 Login();
> > > >>                         }
> > > >>                 });
>
> > > >> You should probably change that to (not only will it be significantly
> > > >> faster but it'll work just fine with 1.4rc1):
> > > >>                 $(document).keypress(function(e) {
> > > >>                         if (e.which == 13) {
> > > >>                                 Login();
> > > >>                         }
> > > >>                 });
>
> > > >> Regardless, I just landed a fix to make sure that no exception is
> > > >> thrown (silently fails instead).
> >http://github.com/jquery/jquery/commit/1960f28c0bf75b16e88460d6135058...
>
> > > >> --John
>
> > > >> On Wed, Jan 13, 2010 at 10:13 AM, Jonas Åradsson
>
> > > >> <[hidden email]> wrote:
> > > >> > Hey jQuery team
>
> > > >> > I got the attached error when I substituted jQuery 1.3.2 with 1.4
> > rc1.
>
> > > >> > A working example of the same page running 1.3.2 can be found here:
> > > >> >http://www.boliga.dk/map.aspx?id=374261
>
> > > >> > Regards
> > > >> > /Jonas
>
> > > >> > ----------------------------------------
> > > >> > Boliga
> > > >> > Jonas Åradsson
> > > >> > Partner and founder
>
> > > >> > [hidden email]
> > > >> > TEL +45 4358 3071
> > > >> > MOB +45 4099 2636
>
> > > >> > Boliga ApS
> > > >> > Blegdamsvej 104 A, 2.
> > > >> > 2100 København Ø
>
> > > >> >www.boliga.dk
> > > >> > LinkedinFacebookTwitter
>
> > > >> > --
> > > >> > You received this message because you are subscribed to the Google
> > Groups
> > > >> > "jQuery Development" group.
> > > >> > To post to this group, send email to [hidden email].
> > > >> > To unsubscribe from this group, send email to
> > > >> > [hidden email]<jquery-dev%2Bunsubscribe@googlegrou ps.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 [hidden email].
> > > > To unsubscribe from this group, send email to
> > [hidden email]<jquery-dev%2Bunsubscribe@googlegrou ps.com>
> > .
> > > > For more options, visit this group athttp://
> > 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 [hidden email].
> > To unsubscribe from this group, send email to
> > [hidden email]<jquery-dev%2Bunsubscribe@googlegrou ps.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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: jQueryLINT

Andrea Raimondi-2
On Fri, Jan 15, 2010 at 1:27 PM, DBJDBJ <[hidden email]> wrote:
> That would not be technically demanding but would be very usefull ...

"Not technically demanding" uh?
I beg to differ on this one.

First of all, what would the criteria be?
If you can't see why this is a problem, maybe someone will explain it to you.

Secondly: pretty much all of the JQuery classes and functions can use
server side tags and code.
The library has *no* knowledge(and rightfully so, imho) of what tags
and/or selectors will be used.

Thirdly: you'd have to scan what tag(s) is(are) associated with the selector.
This would slow things down *A LOT* with many checks.
Mind you, a JQuery tabs class may have any number of tabs for instance.
Now do the checks for *all objects*.

Fourth: plug-ins would have to do the same checks. Alternatively, they
would have to be limited by the
checks performed in JQuery. Both solutions are - imho - unacceptable.

Fifth: *ANYONE* using improper selectors or using JQuery improperly
deserves his/her fate.
Reading the docs is the first thing you should do.

All this, of course, imho.

> --DBJ

--
Andrea Raimondi
Senior Software Analyst&Developer

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: jQueryLINT

dave.methvin
> "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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: jQueryLINT

DBJDBJ
@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 <[hidden email]> 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: Re: jQueryLINT

jaubourg
In reply to this post by dave.methvin
I so agree with you here, Dave.

Design by contract is all I have to say.

2010/1/15 Dave Methvin <[hidden email]>
> "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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: jQueryLINT

Diego Perini
In reply to this post by dave.methvin
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 <[hidden email]> 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: jQueryLINT

Jason Persampieri-2
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: Re: jQueryLINT

Scott Sauyet-2
In reply to this post by Diego Perini
On Fri, Jan 15, 2010 at 2:02 PM, Diego Perini <[hidden email]> wrote:
> 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 ?

I think you miss the point.  This would not be a production version of
jQuery.  It would be either a stand-alone jquery version, called
somthing like jquery-1.4-lint.js, or a plug-in that could run
alongside a particular version of jQuery.  Or it could simply be an
external tool like JSLint which runs against your jQuery-related
source code.

It would be meant to help you track down bad practices in your code
before you put it into production, but you would never use it in a
live site.

I like the idea, and I think it would be possible to do this as a
plug-in, which replaces calls to jQuery functions with calls that
check the parameters, store errors, then delegate to the the original
function.  But have no time at the moment to help implement it.

I'd love to see it.

  -- Scott

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: Re: jQueryLINT

Scott Sauyet-2
In reply to this post by Jason Persampieri-2
On Fri, Jan 15, 2010 at 2:11 PM, Jason Persampieri <[hidden email]> wrote:
> I think you're still not quite understanding what Dave is suggesting.

Timing!  :-)

  -- Scott

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: jQueryLINT

Matt Kruse-3
In reply to this post by Scott Sauyet-2
On Jan 15, 1:11 pm, Scott Sauyet <[hidden email]> wrote:
> I like the idea, and I think it would be possible to do this as a
> plug-in, which replaces calls to jQuery functions with calls that
> check the parameters, store errors, then delegate to the the original
> function.  But have no time at the moment to help implement it.

Check the archives. This comes up every few months, everyone agrees it
would be cool, everyone agrees it could be implemented relatively
easily, yet no one wants to spend the time to build, test, and release
it. Bummer.

Matt Kruse


--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: Re: jQueryLINT

Andrea Raimondi-2
In reply to this post by Scott Sauyet-2
On Fri, Jan 15, 2010 at 8:11 PM, Scott Sauyet <[hidden email]> wrote:
> I think you miss the point.  This would not be a production version of
> jQuery.  It would be either a stand-alone jquery version, called

IME, that's a big red flashing "ALERT!!!!!" sign with white bulbs around it!

Something that isn't meant to be in production shouldn't be in testing
either, let alone a
different version of the library? Geez, would you take the risk of
doing something like that?
I mean, dude, this is stuff that *has to be used* by users - not techies.

Another version of JQuery, gosh! What happens if the two versions are
not synchronized?
What happens if, for some reason, the internal code changes and the
right people aren't notified?
No no no no no no no no, big red signs flashing all over!

> somthing like jquery-1.4-lint.js, or a plug-in that could run
> alongside a particular version of jQuery.  Or it could simply be an

I don't like the idea of a "particular version of jQuery".
Call me conservative, if you want, but I would rather be able to
switch versions
without one more variable floating around and ready to strike you in that place
alongside the others(changing version, a bad idea with worse results,
but sometimes
there is no choice...).

> external tool like JSLint which runs against your jQuery-related
> source code.

*This* is an entirely different matter. "External tool", possibly
native, possibly cross
platform(CONSOLE!), this could indeed be interesting and even useful!
Performance here isn't an issue: even if it takes one hour to check,
you can cron it,
schedule it, even run it with a batch file if you really want!
You could even have a GUI version if you have a compulsion towards
double-clicking
(yes 1, I am in Windows, but I always have a dos prompt ready to fire...).
(yes 2, I know I'm using the wrong platform :D but Delphi(aka:
Windows) programming
pays my bills, so...  :-) ).

> It would be meant to help you track down bad practices in your code
> before you put it into production, but you would never use it in a
> live site.

It would *never* step in the cable line to production if it was my server.

>  -- Scott

--
Andrea Raimondi
Senior Software Analyst&Developer

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: jQueryLINT

DBJDBJ
In reply to this post by Jason Persampieri-2
@Jason: yes , you are (also) right, and also :
>
> I think you're still not quite understanding what Dave is suggesting.
>
Funny .. I could swear it was I who suggested this first  ;o)

--DBJ

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: jQueryLINT

DBJDBJ
In reply to this post by Matt Kruse-3
Of course by "first" I meant: first , but only on this latest thread.
This is just the latest incarnation of the idea which is not mine...

-- DBJ

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


12