No, that's the beauty of jQuery, you can run as many as you want if
That's what my contribution proposal implements.
Check this page http://api.jquery.com/jQuery.noConflict/ for details.
Look at "deep non-conflict" at end for the basics how to remove all
global space variables use. My code does then set the global variables
just during the use of the file or head script code. ;-)
My code is extensively commented, so it should be quite understandable
Obviously you can't use jQuery or $ within an html attribute
'onclick=""' , but nowadays, that's very OK ;-)
On Jan 12, 12:31 pm, Hannes Papenberg <hackwa...@googlemail.com>
> Hi Beat,
> I think you misunderstand me here. I'm aware of possible backwards
> compatibility issues, but I think simply technically its not possible to
> load 1.6.x and 1.5.x on the same page, since one will overwrite the
> other, except for plugins/classes that are not part of the older
> version. At least that is what I'm reading from the jquery docs. Even
> with noConflict mode, you can only load 2 versions at maximum. So
> looking at all of this, providing more than one version on one page is
> Am 12.01.2012 12:13, schrieb Beat:
> > Hi Hannes, :)
> > Running a single version removes 90% of the interest of a joomla-core
> > library-sharing solution:
> > As detailed in the discussion on the pull request here:
> > jQuery is highly backwards compatible usually, and I would have agreed
> > with your suggestion if there wouldn't have been jQuery 1.6 release
> > which broke backwards compatibility for the very much used .attr()
> > method:
> >http://blog.jquery.com/2011/05/03/jquery-16-released/ > > As well as plans for jQuery 1.9 and 2.0, which will probably again
> > break something.
> > Of course, new main release 1.x introduce new features not available
> > before, and that some extensions need.
> > The issue here is timing of major releases of jQuery and of
> > extensions, which gives an additional headache to site admins if not
> > handled.
> > Changing jQuery version is easy and smooth most of the time, but not
> > with what happened in jQuery 1.6 (and thus might happen again).
> > One of the big issues in moving a large extension with many third-
> > party plugins relying on a given jquery version for the .attr() method
> > is that if you use a single version and do update to a major
> > incompatible version (to be able to have the same for all), you break
> > your API between your own major releases and generate a headache for
> > third parties and for site admins in the end.
> > For detailed explanations, please read my comments on the pull
> > request:https://github.com/joomla/joomla-platform/pull/736.
> > Best Regards,
> > Beat
> >http://www.joomlapolis.com/ >
> > On Jan 12, 11:45 am, Hannes Papenberg <hackwa...@googlemail.com>
> > wrote:
> >> I actually don't know if we even need to cater for different jquery
> >> versions. As far as I can see, an additional jquery version simply
> >> (partially) overwrites the currently loaded one, which means that we always
> >> just have the latest one and that's it. So we might as well simply use the
> >> latest jquery and be done with it.
> >> Hannes
> >> Am 12.01.2012 00:08 schrieb "Beat" <beat...@gmail.com>:
> >>> Spent last 2 days designing, implementing and testing a
> >>> behavior.jquery like was discussed here:
> >>> Idea is to solve the conflicts between different jquery and mootools
> >>> versions, and to avoid loading twice same main version of jQuery while
> >>> allowing different jQuery versions to run concurently.
> >>> Result is this pull request as proposal to this group:
> >>>https://github.com/joomla/joomla-platform/pull/736 > >>> For your review and comments.
> >>> Things I kept in mind:
> >>> are handled by this
> >>> - multiple versions can cohabit, but only latest maintenance release
> >>> of a main release is loaded for a given main release.
> >>> To do:
> >>> - install PHP code sniffer used by Joomla Platform Development and
> >>> check
> >>> - any changes required
> >>> Don't know if it's in time for Joomla 2.5, but I kept the changes to
> >>> any existing code minimal and very-low-risk.
> >>> What do you think of the proposal ?
> >>> Best Regards,
> >>> Beat