behavior.jquery implementation proposal
145 views
Skip to first unread message
Beat
Jan 11, 2012, 6:06:26 PM1/11/12
to Joomla! Platform Development, na...@joomlapolis.com, kri...@joomlapolis.com
Spent last 2 days designing, implementing and testing a
behavior.jquery like was discussed here:
https://groups.google.com/forum/#!msg/joomla-dev-cms/HfgjK07fYN8/E-0aPCzP5BUJ
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:
- extensions provide the javascript code and files.
- jQuery itself and plugins and other javascript files using jQuery
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
http://www.joomlapolis.com/
behavior.jquery like was discussed here:
https://groups.google.com/forum/#!msg/joomla-dev-cms/HfgjK07fYN8/E-0aPCzP5BUJ
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:
- extensions provide the javascript code and files.
- jQuery itself and plugins and other javascript files using jQuery
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
http://www.joomlapolis.com/
Beat
Jan 11, 2012, 6:20:42 PM1/11/12
to Joomla! Platform Development
Adding:
Keep in mind that this is a proposal made in view of Platform 11.x /
Joomla 2.5 to solve the urgent and big issue of multiple jquery
libraries conflicting or being loaded multiple times, and almost no
extension developer knowing how to implement correctly deep non-
conflict mode.
This implementation makes it that a jQuery library loaded another way
won't conflict with a library loaded this way.
Thus most of code is tailored at "voting" for latest maintenance
release, and deep-non-conflict feature unique to jQuery.
For Platform 12.x / Joomla 3.x we can extend the concept maybe to
other javascript libraries, but keeping in mind that each is unique.
Thus I would really like to keep focussed on the current problem to
solve. ;-)
Beat
http://www.joomlapolis.com/
On Jan 12, 12:06 am, Beat <beat...@gmail.com> wrote:
> Spent last 2 days designing, implementing and testing a
> behavior.jquery like was discussed here:https://groups.google.com/forum/#!msg/joomla-dev-cms/HfgjK07fYN8/E-0a...
Keep in mind that this is a proposal made in view of Platform 11.x /
Joomla 2.5 to solve the urgent and big issue of multiple jquery
libraries conflicting or being loaded multiple times, and almost no
extension developer knowing how to implement correctly deep non-
conflict mode.
This implementation makes it that a jQuery library loaded another way
won't conflict with a library loaded this way.
Thus most of code is tailored at "voting" for latest maintenance
release, and deep-non-conflict feature unique to jQuery.
For Platform 12.x / Joomla 3.x we can extend the concept maybe to
other javascript libraries, but keeping in mind that each is unique.
Thus I would really like to keep focussed on the current problem to
solve. ;-)
Beat
http://www.joomlapolis.com/
On Jan 12, 12:06 am, Beat <beat...@gmail.com> wrote:
> Spent last 2 days designing, implementing and testing a
Andreas Tasch
Jan 12, 2012, 2:47:17 AM1/12/12
to Joomla! Platform Development
Hi Beat,
thanks a lot for this one. I've been waiting for such a feature.
Joomla! Platform should really provide a consistent way to determine
if a js lib is already loaded and handle the right sequence to include
it. So I really look forward to get this feature.
ndee
On Jan 12, 12:20 am, Beat <beat...@gmail.com> wrote:
> Adding:
>
> Keep in mind that this is a proposal made in view of Platform 11.x /
> Joomla 2.5 to solve the urgent and big issue of multiple jquery
> libraries conflicting or being loaded multiple times, and almost no
> extension developer knowing how to implement correctly deep non-
> conflict mode.
>
> This implementation makes it that a jQuery library loaded another way
> won't conflict with a library loaded this way.
>
> Thus most of code is tailored at "voting" for latest maintenance
> release, and deep-non-conflict feature unique to jQuery.
>
> For Platform 12.x / Joomla 3.x we can extend the concept maybe to
> other javascript libraries, but keeping in mind that each is unique.
>
> Thus I would really like to keep focussed on the current problem to
> solve. ;-)
>
> Beathttp://www.joomlapolis.com/
thanks a lot for this one. I've been waiting for such a feature.
Joomla! Platform should really provide a consistent way to determine
if a js lib is already loaded and handle the right sequence to include
it. So I really look forward to get this feature.
ndee
On Jan 12, 12:20 am, Beat <beat...@gmail.com> wrote:
> Adding:
>
> Keep in mind that this is a proposal made in view of Platform 11.x /
> Joomla 2.5 to solve the urgent and big issue of multiple jquery
> libraries conflicting or being loaded multiple times, and almost no
> extension developer knowing how to implement correctly deep non-
> conflict mode.
>
> This implementation makes it that a jQuery library loaded another way
> won't conflict with a library loaded this way.
>
> Thus most of code is tailored at "voting" for latest maintenance
> release, and deep-non-conflict feature unique to jQuery.
>
> For Platform 12.x / Joomla 3.x we can extend the concept maybe to
> other javascript libraries, but keeping in mind that each is unique.
>
> Thus I would really like to keep focussed on the current problem to
> solve. ;-)
>
Hannes Papenberg
Jan 12, 2012, 5:45:58 AM1/12/12
to joomla-de...@googlegroups.com
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
Beat
Jan 12, 2012, 6:13:08 AM1/12/12
to Joomla! Platform Development
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:
https://github.com/joomla/joomla-platform/pull/736 :
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 .
On Jan 12, 11:45 am, Hannes Papenberg <hackwa...@googlemail.com>
wrote:
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:
https://github.com/joomla/joomla-platform/pull/736 :
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 .
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
> 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:
>
> >https://groups.google.com/forum/#!msg/joomla-dev-cms/HfgjK07fYN8/E-0a...
>
>
>
>
>
>
>
> > Spent last 2 days designing, implementing and testing a
> > behavior.jquery like was discussed here:
>
Hannes Papenberg
Jan 12, 2012, 6:31:53 AM1/12/12
to joomla-de...@googlegroups.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
futile.
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
futile.
Hannes
Beat
Jan 12, 2012, 6:39:28 AM1/12/12
to Joomla! Platform Development
Hi Hannes,
No, that's the beauty of jQuery, you can run as many as you want if
done properly.
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
hopefully.
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>
wrote:
No, that's the beauty of jQuery, you can run as many as you want if
done properly.
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
hopefully.
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>
wrote:
Reply all
Reply to author
Forward
0 new messages