Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #23873 > unrolled thread

jQuery hurrah

Back to article view | Back to comp.lang.javascript

Contents

  jQuery hurrah Andrew Poulos <ap_prog@hotmail.com> - 2014-04-16 16:37 +1000
    Re: jQuery hurrah Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-16 07:25 +0000
    Re: jQuery hurrah Chris Winter <thepoet@a-za-z0-9.de> - 2014-04-16 11:34 +0200
      Re: jQuery hurrah Andrew Poulos <ap_prog@hotmail.com> - 2014-04-17 07:52 +1000
        Re: jQuery hurrah Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-17 00:48 +0200
          Re: jQuery hurrah Andrew Poulos <ap_prog@hotmail.com> - 2014-04-17 09:03 +1000
        Re: jQuery hurrah Chris Winter <thepoet@a-za-z0-9.de> - 2014-04-17 14:25 +0200
          Re: jQuery hurrah Andrew Poulos <ap_prog@hotmail.com> - 2014-04-18 08:20 +1000
            Re: jQuery hurrah Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-18 00:41 +0200
              Re: jQuery hurrah Andrew Poulos <ap_prog@hotmail.com> - 2014-04-18 19:40 +1000
            Re: jQuery hurrah Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-18 01:11 +0000
    Re: jQuery hurrah Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-17 02:30 +0200

#23873 — jQuery hurrah

I was recently asked to debug a web site. The web site was built using a 
major online tool which claims that: "using our unified platform and 
*without* backend coding, you can build everything..."

By default the tool drops a reference to jq into the head of every page.

The tool also provides templates to other functionality such as a decent 
looking image gallery. Alas the image viewer uses a different version of 
jq from the "default" version so that any page that uses the (in my 
case) image gallery fails.

The fix was easy enough - remove one of the jq references - but surely 
the jq ninjas would've written jq in such a way that referencing 2 
different versions on the same page wouldn't cause a failure?

Andrew Poulos

[toc] | [next] | [standalone]

#23874

On Wed, 16 Apr 2014 16:37:11 +1000, Andrew Poulos wrote:

> ... but surely
> the jq ninjas would've written jq in such a way that referencing 2
> different versions on the same page wouldn't cause a failure?

You'd like to think so wouldn't you.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#23875

Am 16.04.2014 08:37, schrieb Andrew Poulos:
> The fix was easy enough - remove one of the jq references - but surely
> the jq ninjas would've written jq in such a way that referencing 2
> different versions on the same page wouldn't cause a failure?

Anyone who takes the little time to look that up in the
manual or can spare the twenty seconds it takes to google
for an answer to that question could tell you that yes,
they did.

-Chris

[toc] | [prev] | [next] | [standalone]

#23877

On 16/04/2014 7:34 PM, Chris Winter wrote:
> Am 16.04.2014 08:37, schrieb Andrew Poulos:
>> The fix was easy enough - remove one of the jq references - but surely
>> the jq ninjas would've written jq in such a way that referencing 2
>> different versions on the same page wouldn't cause a failure?
>
> Anyone who takes the little time to look that up in the
> manual or can spare the twenty seconds it takes to google
> for an answer to that question could tell you that yes,
> they did.

Sorry but why should I read the manual or lookup google to tell me that 
different versions of jq will work together when the site I was called 
in to fix was failing because of an incompatibility between different 
versions of jq?

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#23878

Andrew Poulos wrote:

> On 16/04/2014 7:34 PM, Chris Winter wrote:
>> Am 16.04.2014 08:37, schrieb Andrew Poulos:
>>> The fix was easy enough - remove one of the jq references - but surely
>>> the jq ninjas would've written jq in such a way that referencing 2
>>> different versions on the same page wouldn't cause a failure?
>>
>> Anyone who takes the little time to look that up in the
>> manual or can spare the twenty seconds it takes to google
>> for an answer to that question could tell you that yes,
>> they did.
> 
> Sorry but why should I read the manual or lookup google to tell me that
> different versions of jq will work together when the site I was called
> in to fix was failing because of an incompatibility between different
> versions of jq?

That depends on whether and if yes, where, you called the pertinent method.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#23879

On 17/04/2014 8:48 AM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> On 16/04/2014 7:34 PM, Chris Winter wrote:
>>> Am 16.04.2014 08:37, schrieb Andrew Poulos:
>>>> The fix was easy enough - remove one of the jq references - but surely
>>>> the jq ninjas would've written jq in such a way that referencing 2
>>>> different versions on the same page wouldn't cause a failure?
>>>
>>> Anyone who takes the little time to look that up in the
>>> manual or can spare the twenty seconds it takes to google
>>> for an answer to that question could tell you that yes,
>>> they did.
>>
>> Sorry but why should I read the manual or lookup google to tell me that
>> different versions of jq will work together when the site I was called
>> in to fix was failing because of an incompatibility between different
>> versions of jq?
>
> That depends on whether and if yes, where, you called the pertinent method.

Ok, then the fault is not with jq but the commercial online tool which 
auto-generated the site. The tool claims one doesn't need to write any 
"backend code" - I guess they failed in that aim.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#23881

Am 16.04.2014 23:52, schrieb Andrew Poulos:
> Sorry but why should I read the manual or lookup google to tell me that
> different versions of jq will work together when the site I was called
> in to fix was failing because of an incompatibility between different
> versions of jq?

Because it is easy to lay blame in front of the wrong door. jQuery, with
all its points one could nitpick about, has a method "noConflict()" on
the jquery object itself that encapsulates it and makes different
versions usable on the same page, with correct usage that even includes
most plugins.

-Chris

[toc] | [prev] | [next] | [standalone]

#23883

On 17/04/2014 10:25 PM, Chris Winter wrote:
> Am 16.04.2014 23:52, schrieb Andrew Poulos:
>> Sorry but why should I read the manual or lookup google to tell me that
>> different versions of jq will work together when the site I was called
>> in to fix was failing because of an incompatibility between different
>> versions of jq?
>
> Because it is easy to lay blame in front of the wrong door. jQuery, with
> all its points one could nitpick about, has a method "noConflict()" on
> the jquery object itself that encapsulates it and makes different
> versions usable on the same page, with correct usage that even includes
> most plugins.

The code for the site was produced entirely by a commercial online 
"unified platform" so I shouldn't have to edit anything. At any rate, 
the fix was easy enough but to me highlights a non-trivial issue with 
multiple versions of jq.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#23884

Andrew Poulos wrote:

> On 17/04/2014 10:25 PM, Chris Winter wrote:
>> Am 16.04.2014 23:52, schrieb Andrew Poulos:
>>> Sorry but why should I read the manual or lookup google to tell me that
>>> different versions of jq will work together when the site I was called
>>> in to fix was failing because of an incompatibility between different
>>> versions of jq?
>>
>> Because it is easy to lay blame in front of the wrong door. jQuery, with
>> all its points one could nitpick about, has a method "noConflict()" on
>> the jquery object itself that encapsulates it and makes different
>> versions usable on the same page, with correct usage that even includes
>> most plugins.
> 
> The code for the site was produced entirely by a commercial online
> "unified platform" so I shouldn't have to edit anything.

So far, so good.

> At any rate, the fix was easy enough

*Your* "fix" is unreliable at best; the old plugin may not work properly 
with the new jQuery version, neither may a new plugin with the old jQuery 
version.  You should use the form recommended in the manual (even though the 
implementation of it is as poor as the rest, but at least things cannot get 
worse this way).

> but to me highlights a non-trivial issue with multiple versions of jq.

I presume the issue would occur with any other versions of any other library 
as well.  There is only one global namespace per global execution context.

You owe me an (chocolate) Easter bunny for forcing me to defend jQuery, and 
for having to write it more than one time in a posting.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#23888

On 18/04/2014 8:41 AM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> On 17/04/2014 10:25 PM, Chris Winter wrote:
>>> Am 16.04.2014 23:52, schrieb Andrew Poulos:
>>>> Sorry but why should I read the manual or lookup google to tell me that
>>>> different versions of jq will work together when the site I was called
>>>> in to fix was failing because of an incompatibility between different
>>>> versions of jq?
>>>
>>> Because it is easy to lay blame in front of the wrong door. jQuery, with
>>> all its points one could nitpick about, has a method "noConflict()" on
>>> the jquery object itself that encapsulates it and makes different
>>> versions usable on the same page, with correct usage that even includes
>>> most plugins.
>>
>> The code for the site was produced entirely by a commercial online
>> "unified platform" so I shouldn't have to edit anything.
>
> So far, so good.
>
>> At any rate, the fix was easy enough
>
> *Your* "fix" is unreliable at best; the old plugin may not work properly
> with the new jQuery version, neither may a new plugin with the old jQuery
> version.  You should use the form recommended in the manual (even though the
> implementation of it is as poor as the rest, but at least things cannot get
> worse this way).

Ok, point taken.

>> but to me highlights a non-trivial issue with multiple versions of jq.
>
> I presume the issue would occur with any other versions of any other library
> as well.  There is only one global namespace per global execution context.

Thanks though I've never loaded multiple versions of the same library.

> You owe me an (chocolate) Easter bunny for forcing me to defend jQuery, and
> for having to write it more than one time in a posting.

:-)  If we ever meet I will surely get you one.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#23887

On Fri, 18 Apr 2014 08:20:23 +1000, Andrew Poulos wrote:

> The code for the site was produced entirely by a commercial online
> "unified platform" so I shouldn't have to edit anything. At any rate,
> the fix was easy enough but to me highlights a non-trivial issue with
> multiple versions of jq.

If your unified platform is, as was suffested, loading one version of 
jquery, then loading some jquery extensions, then reloading jquery, the 
second load of jquery, whether it is the same version or a different 
version, may over-write and load time intialisation that was done in the 
extensions.

This wouldn't be a fault of jquery, and wouldn't necessarily even be a 
different jquery versions issue, it could even happen with a double 
loading of the same jquery version.

The fault would be the web page that loaded js components in an order 
that broke those components, or the system that generated that web page, 
or the idiot that wrote that system, rather than with the people who 
wrote the js components concerned (unless they're all the same people of 
course).

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#23880

Andrew Poulos wrote:

> I was recently asked to debug a web site. The web site was built using a
> major online tool which claims that: "using our unified platform and
> *without* backend coding, you can build everything..."
> 
> By default the tool drops a reference to jq into the head of every page.
> 
> The tool also provides templates to other functionality such as a decent
> looking image gallery. Alas the image viewer uses a different version of
> jq from the "default" version so that any page that uses the (in my
> case) image gallery fails.

I have not experienced any issues regarding multiple versions of jQuery
on the same "page"--unless there are jQuery plugins involved.  Consider
e.g.:

  <script src="jquery-1.7.js"></script>
  <script src="plugin.jquery.js"></script>
  <script src="jquery-1.8.js"></script>

After the third script element is parsed, the functionality of the
jQuery plugin is not available anymore, because the plugin adds one (or
more) properties to jQuery.fn (IIRC), which is then reinitialized.

Maybe that is the actual problem on your site.

> The fix was easy enough - remove one of the jq references - but surely
> the jq ninjas would've written jq in such a way that referencing 2
> different versions on the same page wouldn't cause a failure?

How so?  The jQuery library defines the global variable jQuery (with $
referencing it).  Without manual intervention (e.g. var jQuery1 =
jQuery) a second version will replace the first.

-- 
Christoph M. Becker

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web