Adding 'behavior.jquery' to Joomla Framework with deep non-conflict mode and support for concurrent jQuery versions running

[beat]

Hi Joomla Framework team,

I have spent last 2 days designing and implementing a method to load jQuery frameworks, plugins and files, and non-conflicting javascript code into the document head.

The files are provided by extensions, and multiple versions are supported concurrently.

There are only 2 new public methods, one to use it and one to check that it is available (or any other JHtml::_() helper.

I have tested it with multiple jQuery frameworks and with a modified Community Builder version too.

I feel that the changes to existing code and functionality (including minor bug fixes and php-lint fixes) are safe enough for Joomla 2.5.

Please review and comment, main description is below:

Best Regards,
Beat

/**
 * Method to load jQuery frameworks and non-conflicting javascript code into the document head
 * Loading and use is done in "deep non-conflict mode", which allows several concurent versions of jQuery to be loaded and run simultaneously with any other javascript framework, including another conflicting jQuery instance.
 * It means that the window's Javascript global namespace is not used in a fixed way: neither $ nor jQuery global variables are used. Reference: http://api.jquery.com/jQuery.noConflict/
 * 
 * Calling and params:
 * JHTml::_('behavior.jquery', $fullVersion, $relativePathToRoot, $listofPlugins, $javascriptCodeToRunInNonConflictMode);
 * 
 * Use: Example:
 * JHTml::_('behavior.jquery', '1.6.1', 'media/jquery/', null, '$("p").css("color","red")');
 * JHTml::_('behavior.jquery', '1.7.0', 'media/othercompon/js/', array('jquery.flot','jquery.form'));;
 * JHTml::_('behavior.jquery', '1.7.1', 'media/mycomponent/jquery/', array('jquery.ui-all','jquery.form'),'$("h1,h2,h3").css("color","green")');
 * Will load jQuery 1.6.1 with ui and form from the 1.7.1 folder media/mycomponent/jquery, and and jQuery 1.7.1 with flot and form from the 1.7.0 folder media/othercompon/jquery
 *
 * If debugging mode is on an uncompressed version of jQuery is included for easier debugging.
 * Files: 2 files are mandatory for jquery and jQuery plugins, and do follow the jQuery naming:
 * jQuery: jquery-1.7.1.js for uncompressed and jquery-1.7.1.min.js
 * jQuery plugins: "$path/$pluginname[.min].js"
 *
 * @param   string         $version        x.y.z jQuery-Version (not jQuery plugins versions, but always jQuery one) corresponding to the file to load (highest sub-version Z of same x.y release will be loaded in the end) [MANDATORY]
 * @param   string         $path           Path to file from root of website (no / at start but / at end) so that it can be appended to absolute files path or live site [MANDATORY ONCE AT LEAST]
 * @param   array|null     $jQueryPlugins  Array of filenames (without .js or .min.js extension) of jQuery plugins or other Javascript files with jQuery code (which need the jQuery and $ to be defined correctly) [optional]
 * @param   string|null    $jqCode         jQuery Javascript code outputed in context with jQuery and $ defined and on dom ready [optional]
 *
 * @return  void
 *
 * @since   11.5
 */


/**
 * Checks if a JHtml::_($key) call can be made.
 * If the function is not registered, tries to load the corresponding class without registering the function.
 * 
 * @param   string  $key  The name of helper method to load, (prefix).(class).function
 *                        prefix and class are optional and can be used to load custom
 *                        html helpers.
 *
 * @return  boolean      True: $key function is implemented, False: is not.
 */
JHtml::isCallable_($key)

[realityking]

This post is delicate to write since I'm not very fond of jQuery (nor including it into the platform) and I'd like to lay out my concerns with this code. It my tone gets a bit harsh please excuse, I don't mean to insult you solution (which obviously went a lot of work into).

1. It only solves the problem of including multiple jQuery versions, not the problem of including both jQuery and MooTools. I still maintain that the best solution would be a system plug-in that the major jQuery consumers agree on. This plug-in should override JHtmlBehavior with a version that also includes behavior.jquery but more importantly could replace other behaviors with jQuery equivalents (keepalive, noframes, captions, multiselect are the low hanging fruits, especially captions would be loved by many since it's often the reason why mootools is still loaded)
2. This is a lot of code. We don't do any sort of version tracking for other javascript and I don't think we should start - it just adds quite a bit of complexity I don't see this warranted.
3. I'm not sure I wanna add prescript/postscript. The platform and CMS all but stopped using the $() function (only mootree and the uploader remain) - I may get to them before 2.5 too. So the problem will be reduced to 3rd party code very soon and eventually solve itself.
4. What's the use case of JHtml::isCallable_()? I don't see it used in your code.

I'm probably gonna bite my tongue on this but if we do wanna provide a solution to the jQuery problem (I still maintain it could be solved by a plug-in, see above) I wonder it wouldn't be better to just include behavior.jquery (and the necessary jQuery files) into the platform. Seems like less hassle than to add (and maintain) 350 lines of code just to load a javascript framework.

[beat]

Hi Rouven,

To reply on your feedbacks:

1. Yes, it does also solve the problem of running smoothly side-by-side mootools and jQuery. The goal is not to replace Mootools, nor to use jQuery for Joomla core behaviors here.
2. This proposal is exactly meant for Joomla to not need to do any jQuery version tracking, as that code does it between the extensions' proposals automatically. That's why there is a bit of code (not that much actually).
3. Prescript and Postscript are needed to put jQuery in non-conflict mode (that's why most extensions do conflict).
4. JHtml::isCallable_() allows to check if any JHtml::($key) can be called without errors, typically, before calling the 'behavior.jquery' with JHtml::('behavior.jquery, ....) from an extension, you can test it like this, e.g.:

if ( JHtml::isCallable_('behavior.jquery' ) ) {
    JHtml::_('behavior.jquery', _MY_JQUERY_VERSION, _MY_PATH_TO_MY_JQUERY_VERSION, $jQueryPlugins);
}
else
{
    old way...
}

So it's not used in the Framework itself, but useful to know if a behavior is supported. Added note: isRegistered method is not usable, as it's auto-registering on call only.

A jQuery plugin that replaces Mootools for core behaviors can make sense, but won't solve the same problem that is the most urgent ones:

1. Running smoothly Mootools and jQuery side-by-side
2. Running smoothly multiple incompatible jQuery versions concurrently: Extension A requires jQuery 1.5.x, while module B requires jQuery 1.7.x
3. Avoiding multiple times same jQuery version loaded: e.g. no need to load 1.7.0 2 times and 1.7.1 3 times on a page, loading once latest maintenance release 1.7.1 of jQuery will make all extensions happy.
4. Making it easy to load and use your jQuery version without any conflicts. Loading jQuery in a non-conflict mode is hard (Joomla framework does not allow Pre/Post-scripts, and it's not well documented), and loading deep-non-conflict is very hard. That leads to bad imlementations leading to conflicts with Joomla's Mootools and between extensions too.
5. Having an official standard way to solve the above.

Only way to achieve that is in Joomla core, and it does require a few lines of code. Hope that my comments on the code are clear. Let me know if something is unclear :)

[joomla-jenkins]

Unit testing complete. There were 0 failures and 0 errors from 1971 tests and 11146 assertions.
Checkstyle analysis reported 209 warnings and 31 errors.

[realityking]

Wow that was quick.

1. I worded my comment badly. From the Joomla forum it seemed to me many people's issues with jQuery and MooTools is that they don't wanna load MooTools at all. That's why I think that such a plug-in would be good.
2. Apparently we mean something different by version tracking. I think it's bad to start keeping track of the version of an external script we load. I think you mean by not tracking that we don't have to put jQuery into the repro, correct?
3. For this "deep no conflict" you're doing, yes it's necessary. The question is if this is really desirable. This could still mean loading 3-4 JS framework. (which could be less than before admittedly). For normal noconflict a much simpler solution would suffice. While I can see the beauty of this code I really think it encourages bad behavior.
4. Ah this makes sense. Might indeed by a good idea until we switch JHtml::_() to throw exceptions. I do kinda suspect this fixes mostly a community builder problem - no other extension I know supports so many Mambo/Joomla version with just one package. Everyone else could probably rely on things being present since they only support two versions. (Not a reason not to include it!)

Second list
2. I have to admit to not know much about jQuery (I only used it when absolutely necessary) but isn't one of the major advantages over MooTools that's it has better backwards compatibility? So shouldn't it be sufficient to just include the latest version that is loaded.

1. I suspect here lies the true problem we have. For a variety of reasons (preference, existing script, MooTools incompatibilities) we have lots of people wanting to use jQuery. Since the CMS never made that a real option we now have the situation where extensions are all over the place and careless site builders may end up with MooTools and several jQuery versions loaded. I appreciate that you're trying to fight the worst symptoms of the situation with this but I really think a more radical solution would be better in the long run (if we really need one in the core, I have to admit I'm not totally sold on it but I try to separate this from my other concerns.)

[realityking]

Got another question on the "deep noconflict" (the concept is new to me).

How do you handle it when you have some piece of javascript code in your layout and you need access to jQuery? How do I get the right one? Or does this only work for JS added to the head?

[beat]

You're quick too, so it's nice to discuss this while it's hot ;) :

First list:

1. Understand your concern, and it is a separate one, out of scope for the Joomla Platform for use in Joomla 2.5 LTS, and not needing to be in platform (agreeing on this point :) ). However, that separate jquery-based behavior will still need such methods to share its own jQuery with other extensions. E.g. being stuck with jQuery 1.7 for whole LTS will give headaches, that's solved here. And it still will need to solve same problem: many extensions do conflict and load multiple times same jquery as there is no standard way to share as Joomla Platform doesn't support it. Thus this proposal can be used there too.
2. Yes, but the code I propose is not tracking nor specialized at one particular jQuery version. It supports any jQuery version. Read the code and comments, it might help understanding the goals and solutions to these problems. I wrote 4 versions, mostly longer, before comming to this minimal implementation, but I'm open for further simplifications. However removing the multiple-versions support removes 90% of its interest and use.
3. My code puts priority to avoiding conflicts and comes from the practice of a large extension with many plugins form 3rd parties. As you seen with Mootools 1.1 and 1.2, upgrading is not done overnight, and running both versions in parallel until all codes are upgraded avoids the headaches of an admin upgrading one component, and then stuck with a non-working site because another extension can't upgrade for good reasons before a few months. Allowing a smooth transition and breaking millions of sites is certainly not "bad behavior". ;)

Second list:

1. yes, jQuery is much better backwards comptible, however, version 1.6 broke backwards compatibility and e.g. CB 1.x's 3rd parties which use jQuery 1.5's API, so until we release CB 2.0, we are stuck with jQuery 1.5.2 and can't upgrade to 1.7.x, not because of CB, but to keep our 1.x API compatible with 1.x extensions. However other modules requier 1.7.x, so you see the problem and the use of this solution with a practical example. Not bad behavior, just release cycles.

3rd list:

1. In the long term, the platform should support very popular javascript libraries and not rely on them (?). However that won't change the current problem with extensions and templates: half use Mootools of Joomla, and the other half use jQuery. Mootools don't conflict because the Joomla Platform has set a standard way, while jQuery do conflict by lack of any standards and developers education.

I think the longer-term problem is very different, and I'll not try to guess what it will be (maybe to have to move from PHP to NodeJS ;) ?)

That's why this proposal is focussed on solving short-term real problems, and doesn't want to fix the global (imho unsolvable because not definable today) problem, which is completely different imho (and not 300 or 3000 lines of code, but much more).

[beat]

Relpying to 2nd reply that came above mine re: deep non-conflict:

You simply include the jquery-using file using the behavior.jquery in the $plugins : Inside that file (because of the Pre/Post-scripts that save $ and jQuery and assign your own version before including the file(s) and restore them after) you will have your version in "$" variable and in jQuery variable. So no guessing.

Same for script code in header, if included with behavior.jquery, you will have $ and jQuery variables for your use, it's done with a function parameter and local variable, but effect is same :) .

Now I don't think that you will find a piece of code that uses both mootools AND jQuery simultaneously, but that is possible too...

That's why this solution is imho quite interesting and elegant in terms of integration.

[joomla-jenkins]

Build triggered by changes to the head.

Unit testing complete. There were 0 failures and 0 errors from 1971 tests and 11146 assertions.
Checkstyle analysis reported 199 warnings and 0 errors.

[realityking]

So this doesn't work at all when I'm mixing JS into my HTML correct (in layouts in particular)?

We tell people who use MooTools to suck it up and to use whatever version comes with CMS (basically). I don't see why jQuery would be any different.

Taking the CMS hat off your point regarding limiting the platform to one JS library is true. Maybe we should discuss if all that JavaScript stuff (and with it most of JHtml) actually belongs into the platform. While it is nice to offer an "integrated" solution we do kinda limit platform users in this regard.

[beat]

So this doesn't work at all when I'm mixing JS into my HTML correct (in layouts in particular)?

As is in the proposal now (where the goal is to avoid conflict with any jQuery version loaded without the knowledge of the Joomla Platform like done now), jQuery global function is not usable directly.

However you can still use it anywhere, provided you use "Joomla_jQuery_1_7" (where 1_7 corresponds to version 1.7, that string is defined in function jqueryGlobalVarName() in my implementation as a suggestion) instead of "jQuery" to define your $ and/or jQuery variable different from e.g. Mootools's $ inside a closure or function, if you use $.

Thought 1:

• An alternative could be to define the highest version proposed by extensions as THE jQuery global (if not already defined by another way). That's not a huge task and would add around 10 lines of code to my proposal.

We tell people who use MooTools to suck it up and to use whatever version comes with CMS (basically). I don't see why jQuery would be any different.

CMS hat on: No issues with STS releases, but with LTS releases we have seen the pain with Mootools 1.1. I also gave some good reasons to support multiple versions (that said, it's a good idea to recommend a given jQuery version for a given Joomla version). CMS hat off.

My proposal solves the issue not only for the jQuery core javascript library, but also for official and third-party jQuery plugins, where the core Joomla Platform or CMS can't provide versions for the thousands of jQuery plugins available and potentially useful while non-conflicting between most of them. That's also a difference with Mootools, and why concurrent versions-management is imho a good idea.

In the google groups, it has been said that Joomla will not include nor maintain the jQuery code, and that the extensions will have to provide it, in which case the version matters and needs to be treated accordingly. I also replied to the call to action to propose something based on these directions. Also the consensus was to have a "behavior.jquery" API like the "behavior.framework" or "behavior.mootools". My implementation proposal is following those requirements given.

The idea here was to work based on all previous talks, and propose a real deeply-non-conflicting solution to all the present conflicts that can be looked at, and changed/moved as needed for inclusion, instead of continuing talking without any proposal.

Taking the CMS hat off your point regarding limiting the platform to one JS library is true. Maybe we should discuss if all that JavaScript stuff (and with it most of JHtml) actually belongs into the platform. While it is nice to offer an "integrated" solution we do kinda limit platform users in this regard.

Thought 2:

• If instead of "behavior.jquery" we have "jquery.load" for instance, we could have a separate file for a class JJquery and not add those functions to JBehavior object. Or... move those functions out of JBehavior, except for the main public function that would just load the JJquery class file and limit the addition to JBehavior class and file to a few lines of code.

I have on purpose limited the API to a single public function so that the block providing that functionality can be easily moved to another place where it's not loaded when "behavior.framework" only is needed. But I didn't want to add a file until we knew what the proposal is and get feedbacks.

I'm open to any improvements or simplifications that keep it a solution to today's problem which is the conflicts and multiple inclusions by third party developers and template designers because of no support by Joomla.

Thought 3:

• Maybe my solution with deep non-conflict and seemless support of multiple versions (in the interest of keeping sites and apps running when one extension is upgraded) is too luxurious for JBehavior but would fit well together with a CMS-provided "official/recommended" jQuery+jQuery-ui version in a new class+file JJquery ?

[andreatarr]

Joomla is aimed to include people who are not technical and who just include extensions and expect them to magically work together. The Joomla universe is also filled with people who tinker just enough to include some jquery eye candy and are very happy to see it work. Add in the issue of different release times of extensions and I think a practical approach that acknowledges this chaotic state of affairs and deals with it is good.

[ianmacl]

I don't think that it is unreasonable to expect that extension developers that choose not to use Mootools at least pick a single, common version of jQuery to develop to. I would hope that if the major extensions developers who insist on jQuery settle on a single version of jQuery for a given release that other smaller extension developers would follow suit and use that version. It seems ridiculous in my mind to encourage/support developers in choosing whichever version of jQuery they want. It is already suboptimal to have a site with two different libraries. I can only imagine what will happen when you have sites with Mootools and three to four versions of jQuery. That spells bloat to me and certainly not something that IMO we want to encourage.

[AmyStephen]

It's good to see the project recognizes many site builders want to use jQuery with Joomla.

Having said that, I do not believe it's wise for the project to include jQuery with core unless the templates or widgets shipped with core require it, and that is not the case. I also wonder about the wisdom of adding core code to mitigate the conflicts that might result from installing different versions of the same non-core library. It seems to me that might be asking for a whole lot of drama.

I wonder if it might make more sense to treat this as a JED issue? (Grandfathered in - so folks have time to adapt.) If the following rules were used on JED, it might help bring some sanity to this area:

1. A copy of the JS framework (of ANY flavor) cannot be packaged with the extension.
2. The extension must work with a simple CDN inclusion of the JS framework to be listed and to continue to be listed.
3. The extension should be tested with MT loaded in the normal way - and then classified as MT friendly or not MT friendly.

Combined, those policies should help encourage version standardization and staying up-to-date. It should also help to inform users as to possible conflicts they might find with MT. That information and open choices are the very best the project can do. From that point forward, it really is the responsibility of users to live with the consequences and benefits of their decisions (and the decisions of those they hired to make these calls on their behalf.)

[betweenbrain]

Thank you Beat for the hard work that you have put into this! I am very grateful to see this moving forward.

This is certainly a tough situation to resolve, and one that we can see there are many approaches to. I do need to point out that the original post proposing behavior.jquery (https://groups.google.com/forum/#!msg/joomla-dev-cms/HfgjK07fYN8/E-0aPCzP5BUJ) was aimed at preventing multiple versions of jQuery being loaded.

I agree with Ian in that I don't think that it is unreasonable to standardize on a common version of jQuery that developers need to develop to. My hope for behavior.jquery is that it would load a specific version of jQuery to encourage standardizing on that version, such as what happens with MooTools.

As someone who uses jQuery, and has experienced the b/c issue in 1.6 firsthand, I wouldn't mind having to develop to a specific version of jQuery if the core was loading it.

[sourcecoast]

I posted on the Joomla CMS development thread as well, but it seems like discussion is moving here.

This patch is nice work, and I don't mean to criticize the time put into it. It does seem to fix the multiple inclusions of the jQuery libraries multiple times, but it still relies on the developer to package their own files, which is odd. That file can be modified, compressed, debug version, loaded from cloud or local, etc. If that extension is the first to call dibs, it can cause problems for any other extension that needs jQuery.

Additionally, I know the 1.6.0 b/c issue has been raised, but this really doesn't fix it. If that attr() bug had been in 1.6.5 (let's say), and extension com_jq_good was loading 1.6.4 on a site, if the user installs com_jq_bad which loads up 1.6.5 (with the bug), then com_jq_good would all of a sudden stop working. It's not something that can really be fixed as it's a bug in jQuery, and that's not something Joomla should be responsible for fixing.

So, the main issue this patch solves is the multiple inclusions. For that, I think it's either something 'done right' in the CMS by including and standardizing on one version (reliably and consistly), or left up to developers to standardize on a proper method.

In my post on the CMS blog, I brought up Facebook Javascript library multiple inclusions which are a pain for us. If the CMS is going down a route of working around all multiple inclusion issues, that's fine, but I think it's going to get cumbersome to pick and choose which libraries are right to finesse and which ones are up to developers to figure out a solution for.

Again, not criticizing the work, just the purpose and can of worms I think it may open up.

[Joe-Palmer]

Beat, this is fantastic, thanks for you hard work! Everything looks good from here!

I understand the argument that this should be in a plugin but as we can see here, there are already loads of plugins that will include jQuery for you:

http://extensions.joomla.org/extensions/core-enhancements/scripts

Unfortunately, the reality is that no-one is going to agree on one particular plugin and no-one want to say "please download and install this 3rd party plugin before my extension will work".

I have built many Joomla sites and multiple jQuerys is the single biggest problem I come across time and time again. Having a solution to this in a LTR would be amazing and I will do anything I can to see it happen.

I think the best solution is to include the latest version in the core which is only loaded when someone calls behavior.jquery. This will allow developers time to migrate to using the core version that everyone else is also migrating to. However, if there is a bug in that version, they can use Beat's solution to load their own version.

This would encourage developers to all use the same and latest version whilst giving them the option to load their own version safely without affecting anyone else's extensions. I can't see fairer then that!

+1 for Beat's solution with Joomla shipping with just the latest jQuery which is the default behavior.jquery.

This time last year I was really against jQuery and I still prefer MooTools but I am now a realist and it is not worth fighting any more. Lets make life easier for our developers!

Thanks again Beat!

[laoneo]

behavior.jquery is really needed at joomla. All other big players like wordpress or drupal are shipped with jQuery as well. I'm personally preferring to have one jQuery version shipped with joomla and all extension developers have to use the same version. The users of GCalendar would be really thankful if jQuery would arrive at joomla!!

[ianmacl]

The future of Javascript in the platform is uncertain (we will likely decide on this post 12.1). Either way, this solution seems overly complex and jQuery centric, which is not a direction we are planning on going. Appreciate the ideas and work that went into this. Perhaps we can revisit another approach post 12.1 depending on what is decided regarding Javascript.

[laoneo]

What means "post 12.1" ?

[AmyStephen]

12.1 is the next Joomla Platform release - expected in the next few weeks.

[Joe-Palmer]

We need to do something to address the multiple jQuery issue, it is the biggest problem I have working with Joomla!

[AmyStephen]

@softforge Recently, an announcement was made that both jQuery and MT's would be included in 3.0 http://ux.joomla.org/forum/Visual-Design/481-UI-Options-and-Bootstrap?limit=8&start=136#636

[beat]

Crosslinking this pull request with this one as both are relevant to jQuery inclusion in Joomla:

joomla/joomla-cms#218 (comment)

[beat]

BTW could someone with divine rights re-open this pull request as the decision has been changed regarding jquery inclusion ?

[azrul]

Ping. Request for reopen.

[ianmacl]

We haven't discussed this and made a decision about how jQuery should be handled in general (i.e. whether we should add it to the platform or let the application add in support of they want it using JHtml::register). In either case, this implementation is far too heavy. If we were to add jQuery support I would think it would only be support for one version. I don't think it is necessary to add over 400 lines of code to add a script tag to the document. If the CMS wants to support jQuery I would advise them to select a release for a particular version and require third party developers to use that release.

[beat]

Thanks for your answer, Ian.

Just to clarify: It is NOT 400 lines of code:

Only 125 lines of code are for jQuery + jQuery plugins management. Complete jQuery plugins management is a big benefit of this pull request. For jQuery without plugins, it would be probably less than 50 lines of code with deep-non-conflict.

Rest is cleanups in existing code, actually reducing existing line-counts, and adding functionality to existing javascript code, that is needed in many library, and NOT specific to jQuery. And lots of comments (that we can of course remove to bring line-counts down ;-) ).

jQuery plugin management with only one version and without deep-non-conflict would probably be less than 10 lines of code, and with jQuery plugins management would be 80.

So issue is obviously NOT line-counts of code, but lack of decision from whoever decides within 7 months if not years.

Rest has all already been said in above discussion.

But the lesson has been learned: Next time, I will sit still and wait for a final decision from PLT instead of a consensus in the google-groups discussions before spending a week writing and contributing code. ;-)

Fortunately, I could reuse my deep-non-conflict code and it works perfectly, bringing down Javascript-conflicts to really Zero in CB installs since 6 months!. So actually, just as an example of the benefit of deep non-conflict, CB Javascript runs fine with whatever other Javascript is present or not.

So, in conclusion: Please let us know when PLT or whoever has final saying has found the time to reach a decision on this topic that needs to be covered for Joomla 3.0 (and preferably its corresponding platform, as this kind of low-level stuff clearly belongs to the Platform and not to the CMS or Application).

[ianmacl]

My understanding from rereading the threads is that the intended direction was to be away from loading multiple versions of jQuery. You seem to be encouraging the opposite.

[beat]

It would be good that the Platform be able to handle multiple versions of jQuery plugins, as most of those would be "proposed" by the Joomla extensions (or the Joomla CMS) and not included with Joomla Platform. There is no way Joomla Platform can or should include all jQuery plugins. Maybe just the "official" jQuery UI ones and possibily the bootstrap one at most.

From there, allowing same for jQuery core itself is only a few lines of code, as I'm using same code to manage both. So managing jQuery plugins with a fixed jQuery base library would be maybe 10 lines of code saved here, and then 10 lines of specific code added elsewhere.

If jQuery is included in Joomla Platform, then it's not needed to be able to manage multiple versions of jQuery plugins. But as it comes for free with being able to manage multiple versions of jQuery plugins, it's a nice to have.

Actually, thinking loud from a Platform perspective, it could be interesting that the Platform gives the library to manage the loading, but does not provide the jQuery code itself. That code could be provided by the Application (e.g. CMS), which optionally could use a CDN instead of its own, if configured so.

Thus I still think it's not completely "stupid" ;-)

jQuery allows for thousands of existing jQuery plugins, and that's it's real strength. That's why it also makes sense to supporting their loading by the Platform while provided by an App of the Platform, if the Platform wishes to support jQuery, a standard way to load jQuery plugins makes full sense. And thus loaded version management as proposed.

[eddieajau]

Personally, I'd like to see all the javascript removed from the platform because it belongs in the implementation of the application. In other words, it's not the Joomla Platform's job to support jQuery, but if the Joomla CMS wants to support it, that's awesome, and they should provide that support in their application. Likewise, if I'm building an application that needs Dojo or YUI, it's my responsibility to implement that, not the platforms.

So, I'm not a fan of this proposal but only because I think we should remove all client-side media from the platform and I think the CMS should own the discussion.

[beat]

Hi Andrew,
Thanks for clarifying. Just to understand correctly:
So Joomla Platform is a PHP-only library, not a web-applications platform (i am not aware of any modern web-application which doesn't use heavily Javascript and Javascript libraries) ?

And a question:
Who/which body is making such decisions which span platform and CMS ?

As a matter of fact, as contributors, we don't care who implements or makes the decision, but it would save all of us all lots of time that a final decision is being finally made in time for Joomla 3.0 CMS and corresponding Platform.

The Javascript workgroup gathered together at JAB12, and made number of decisions, but i'm not yet seeing support for their decisions. So it's a very confusing contributor's situation. Happy to see this decision or discussion elsewhere as it is broader as just this pull request. ;-)

[AmyStephen]

+1 @eddieajau - in fact, one could make the argument it doesn't belong at the platform layer or the application layer but rather the presentation layer bundled with a theme.

[beat]

Oh, Hi Amy, we were missing you here lately :-)
To follow your thinking: Long ago someone said that javascript is not a programing language, but just a template beautifying data :-D
It's not 2005 anymore. Welcome to 2012 where most web-apps have more and more Javascript, which is proabably a more solid language than PHP btw.

Thanks for the feedbacks and for helping me making the decision to leave this discussion, as long as there is no more understanding of jQuery and that it has become more fundamental as PHP for modern web-apps, or a corresponding wish to understand it. And a corresponding decision

Adding to the list of rejected Joomla contributions without any directions or decisions for design and/or improvements.

[AmyStephen]

@beat -

Here's three good articles regarding the importance of separation of concern and how to best architect placement of logic within the most appropriate layer.

1. IBM - SOA: Insights and Best Practices - https://www.ibm.com/developerworks/mydeveloperworks/blogs/AliArsanjani/entry/ajax_sits_in_the_soa?lang=en Good diagram that talks about best placement of certain types of logic.
2. Presentation Layer Best Practices http://www.welterlin.com/whitepapers/presentationLayerBestPractices.php - Discusses the separation of semantic, hierarchical HTML mark-up from CSS style sheets and JavaScript behavior and what benefits adopting that methodology offers
3. Presentation Layer Accessibility http://www.razorfish.com/.../PresentationLayerAccessibility.pdf Offers good argument as to why properly separating your presentation layer makes it easier to support interfaces approaches used by those who require assistive support.

I agree wholeheartedly with @eddieajau that the JS implementation should not be implemented at the framework level. This is consistent with comments I've made for a number of years. It is how I am using JS in Molajo. It is my belief that the best flexibility can be achieved in our applications by deploying JS in the thinnest most shell of the application layer. In terms of a Web application, that layer is more frequently implemented in a theme/template.

[eddieajau]

On 21 August 2012 09:11, beat notifications@github.com wrote:

Hi Andrew,
Thanks for clarifying. Just to understand correctly:
So Joomla Platform is a PHP-only library, not a web-applications platform (i am not aware of any modern web-application which doesn't use heavily Javascript and Javascript libraries) ?

I am (aware). They are called web services. A few little sites run
them (Facebook, Twitter, Github … ).

And a question:
Who/which body is making such decisions which span platform and CMS ?

It's my opinion. You don't have to like it.

As a matter of fact, as contributors, we don't care who implements or makes the decision, but it would save all of us all lots of time that a final decision is being finally made in time for Joomla 3.0 CMS and corresponding Platform.

Irrelevant. You can go ahead with this plan within the CMS independent
of what the Platform does in my opinion.

The Javascript workgroup gathered together at JAB12, and made number of decisions, but i'm not yet seeing support for their decisions. So it's a very confusing contributor's situation. Happy to see this decision or discussion elsewhere as it is broader as just this pull request. ;-)

I'm only guessing, but I would say the workgroup was making decisions
in the context of how to make things happen in the CMS. Anyone using
the Platform to build a ground-up application probably won't be
touching any of the current JavaScript with a barge pole. I also
believe your only concern is for the CMS so, with due respect, what's
the problem with petitioning the CMS to add this?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[eddieajau]

On 21 August 2012 09:27, beat notifications@github.com wrote:

Thanks for the feedbacks. Adding to the list of rejected Joomla contributions without any directions or decisions for design and/or improvements.

Not a terribly accurate spin on the outcome. I believe the direction
is bump it up to the CMS (because, and let's be completely honest and
transparent, this is the application where it's going to be used). As
I've already said, anyone building standalone applications won't be
using this feature (they will select a single UX platform and just
load that in their template, or put it in their JavaScript stack to be
packaged and compressed).

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[eddieajau]

On 21 August 2012 09:15, AmyStephen notifications@github.com wrote:

+1 @eddieajau - in fact, one could make the argument it doesn't belong at the platform layer or the application layer but rather the presentation layer bundled with a theme.

Sure. My point was that it's the responsibility of the application
(pick whichever layer suits the design requirements) to provide those
sorts of features, and this can be done with a heck of a lot less code
than this patch.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[nickanti]

@AmyStephen

First link is dated 2006, second one also 2006 and third one is broken (?).

Beat's comment about it's not 2005 anymore seems in order.

However all of this is more or less irrelevant.

What can be learned - if people honestly want to - is that contributing code to Joomla is frustrating, difficult and virtually impossible mainly because there is no open (? or even closed) decision making process.

As I recall, Andrew "asked/challenged" Beat to contribute code to address this issue.

Beat discussed this with me before he committed his time to this task. We argued at the time that this would be just one more case for rejection and frustration, but he went ahead anyway with the thought that this contribution can also be used in CB..

This entire thread and the corresponding discussions on Google and elsewhere is a great use case for the - much abused term Joomla community - to see how unguided, unmanaged (or mis-managed) volunteer (and some externally funded) resources transform themselves into a brick wall against contributions.

I will not be replying at all from here on to this thread. Just felt that for completeness and honesty these not so uncommon in the Joomla world situations should be clearly tagged for historic reasons.

I for one THANK Beat for taking the time to respond to a call for action - or whatever one chooses to call it.

Regards,
Nick from CB Team @ Joomlapolis

[AmyStephen]

@nickanti Sorry about that! http://www.razorfish.com/img/assetsTemp/PresentationLayerAccessibility.pdf

To me, a good recent example of separation of concern can be found in products like Twitter Bootstrap and Foundation. Those "template frameworks" emerging today can be applied to any environment, be it a CMS, or PHP, or Ruby, etc., because the code has been abstracted out to the presentation layer. Imagine if it were instead coded in the lower layers of a specific CMS -- then, it would only be helpful to those using that CMS. Further imagine if someone wanted to use a different, yet to be released solution for that CMS and a conflicting option was already hardwired to the codebase.

Anyway, I definitely agree it can be frustrating to contribute to Joomla or any open source project. I don't believe anyone is immune to the frustrations that come from participation. How anyone stays encouraged is sometimes a mystery to me.

But, we are all talking in the open, we just aren't all agreeing. I see clearly mentioned that this PR could be more properly directed to the CMS and many of us seem to agree with that notion, although it's unfortunate that is seen as discouragement. Door isn't closed on this, near as I can see. Maybe take it to the Joomla CMS list?

Thanks @beat.

[mbabker]

FWIW, since we've merged Bootstrap (and inherently, jQuery) into the CMS, I have a patch that cleans up the implementation quite a bit, including adding a 'jquery.framework' behavior, seen here: https://github.com/mbabker/joomla-cms/compare/JScleanup#L13R27. Since we are distributing a version with the CMS, there's no need for the numerous version checks, and it is possible to override the method call using JLoader::register() if you want to load from another location or use a different version on your site.

[eddieajau]

On 21 August 2012 17:15, Nick A. notifications@github.com wrote:

As I recall, Andrew "asked/challenged" Beat to contribute code to address
this issue.

That I did, but since then I have changed my mind about what the
Platform should support and think we should throw ALL client-side
resources out - they belong to Joomla CMS, Molajo, Project-X or
whatever application you are building on top of the Platform. We've
also gone through a lot of review about what is Platform and what is
CMS code in that time as well. ON top of that, we've seen UI
frameworks like Bootstrap come of age and they are changing the way we
think about application design. It's one of those unfortunate
characteristics of time moving forward that perspectives and
technology change.

This entire thread and the corresponding discussions on Google and elsewhere
is a great use case for the - much abused term Joomla community - to see how
unguided, unmanaged (or mis-managed) volunteer (and some externally funded)
resources transform themselves into a brick wall against contributions.

The following point seems to be missed or misunderstood. There is
nothing lost in terms of what Beat can add to the CMS, where I think
this belongs anyway. I honestly doubt that the "idea" will be a hard
sell to get into the CMS. I have some concerns, like others, that
Beat's implementation is over-engineered and overly complex but that's
neither here nor there.

The bottom line is that new platform applications are not going to
need to support both Mootools and jQuery. Let's not mention the fact
that we have new initiatives like AngularJS. The CMS, however, does
have a need (whether I agree it's a good idea or not), to support
blending of Mootools and jQuery (and I'm already on record as saying
you should pick one or the other, not try and be all things to all
people because that just leads to inefficiently designed websites).
That's where the code should live, in my opinion.

This is not rejection. This is not a brick wall. I accept that for
people just developing CMS extensions it would seem to be a
frustration, and it may feel like you are being bounced from pillar to
post (I get it), but it's about putting the right code in the right
place. Please try and take a step back and see the big picture - and
it's possible that that is a scary thought for some people.

Regards,
Andrew Eddie

[beat]

Thanks for your answer, Andrew.
I understand and respect your point of view, and i think it deserves also a friendly answer. I agree to disagree and to think that ignoring the Javascript browser-side parts and their tight integration with the server-side in a Joomla Platform is a huge shortfall for "selling" the Joomla Platform for web-applications. Thank you for respecting my point of view too. Agreeing to disagree on this :-)

To reply to your statement:

Beat's implementation is over-engineered and overly complex but that's
neither here nor there.

I need to reply that it's neither over-engineered nor over-complex to solve the problem that has been clearly defined in the Google-group discussion (where extensions provide various proposals for JS code and not the Joomla Platform, and Platform needs to bring consistency in).

However as the problem to solve seems to have changed, it is of course easy to criticize it as now "over engineered", specially in the light of many parts of Joomla CMS and Platform which are heavily over-engineered.

As the CMS has taken a different route, there is no need to lobby CMS for this code. The proposed CMS pull-request by mbabker is certainly not more efficient nor using Joomla's API for JS files inclusions, and doing a whole 1-line js file include with its http request just for adding a single line of js code, that with proper API of Platform could have been outputed just after the file inclusion as required (that small API change has been proposed here in a part that actually reduced at same time existing line count and added consistency, and separately by Joseph in another pull request with minimal lines changes, both refused to my knowledge even though independant of JS library). But as Joomla Platform's API doesn't want this change he had no other choice than doing it that innefficient way. Additionally, jQuery plugins are not handled properly yet there.

Following changes that are fully independent of jQuery in the first 3 files of this pull-request still make full sense for the Platform and not for the CMS in the commit proposal beat@73eeffd

1. adding defer javascript statement and pre- and post-scripts in file libraries/joomla/document/document.php
2. bug-fix in file libraries/joomla/document/html/html.php
3. consistency improvements and pre- and post-scripts in file libraries/joomla/document/html/renderer/head.php

But I guess that as the individual change proposals in this pull request have not been looked at, "those 3 kids are being thrown out with the bath water" too.

So, as this discussion here won't lead to an improvement to the javascript support in the Platform, i'm stopping my own timewaste here on this as long as someone has not actually read through the code and understood at least the first 3 files of the commit of this pull-request.

Sincerely, Respectfully and constructively,
Beat

[eddieajau]

Hi Beat

On 22 August 2012 10:09, beat notifications@github.com wrote:

Thanks for your answer, Andrew.
I understand and respect your point of view, and i think it deserves also a friendly answer. I agree to disagree and to think that ignoring the Javascript browser-side parts and their tight integration with the server-side in a Joomla Platform is a huge shortfall for "selling" the Joomla Platform for web-applications.

If the sole purpose of the Platform is to serve the CMS, I'd agree,
and I'd also make the point that it was a complete waste of time to
separate it from the CMS in that case. However, the "web" and "web
applications" are changing (have been for a while). If there is a
marketing problem, and I don't agree there is (I find, generally, that
the direction the Platform is taking is in general accord with the
guru's of the industry - I recommend you peruse the many videos
produced by Apigee), the solution to making the Platform attractive
for web application is not just adding jQuery support. The solution
is building a JavaScript application from the ground up. Now, as it
happens, many people are already doing that already outside this
project so it makes sense not to favour any one of those for the core
"Platform".

Better yet, have Joomla start a third new initiative for client-side
UI resources (JS, CSS, media, and so on) that does indeed dovetail
with the Platform as it's server-side companion.

Thank you for respecting my point of view too. Agreeing to disagree on this :-)

To reply to your statement:

Beat's implementation is over-engineered and overly complex but that's
neither here nor there.

I need to reply that it's neither over-engineered nor over-complex to solve
the problem that has been clearly defined in the Google-group discussion
(where extensions provide various proposals for JS code and not the Joomla
Platform, and Platform needs to bring consistency in).

It would be helpful to reference discussions when you want to quote
them as a primary source. Though I've been out of the loop per se for
a few months, I've not seen any discussion from people building
standalone applications on the Platform that not having jQuery support
is a problem.

However as the problem to solve seems to have changed, it is of course easy
to criticize it as now "over engineered", specially in the light of many parts of
Joomla CMS and Platform which are heavily over-engineered.

That's exactly why we presented an alternative, lightweight MVC, among
other things to streamline and improve the code base. It is the
nature of this project to improve things, knowing full well the code
we commit today, we'll look back on and think "what were we thinking".

As the CMS has taken a different route, there is no need to lobby CMS for this code.

That would only reinforce my case.

The proposed CMS pull-request by mbabker is certainly not more efficient nor using
Joomla's API for JS files inclusions, and doing a whole 1-line js file include with its
http request just for adding a single line of js code, that with proper API of Platform
could have been outputed just after the file inclusion as required (that small API change
has been proposed here in a part that actually reduced at same time existing line count
and added consistency, and separately by Joseph in another pull request with minimal
lines changes, both refused to my knowledge even though independant of JS library).
But as Joomla Platform's API doesn't want this change he had no other choice than
doing it that innefficient way. Additionally, jQuery plugins are not handled properly yet there.

That's really something to take up with the CMS.

Following changes that are fully independent of jQuery in the first 3 files of this
pull-request still make full sense for the Platform and not for the CMS in the
commit proposal beat@73eeffd

Then you should possibly consider splitting up your pull request.

adding defer javascript statement and pre- and post-scripts in file libraries/joomla/document/document.php
bug-fix in file libraries/joomla/document/html/html.php
consistency improvements and pre- and post-scripts in file libraries/joomla/document/html/renderer/head.php

That's a completely different topic.

But I guess that as the individual change proposals in this pull request have not been
looked at, "those 3 kids are being thrown out with the bath water" too.

That's the risk everyone takes when they submit a pull request. Many
a pull request has been refused (where "refused" carries no malicious
intent) even though "parts" of it are good. May I remind you that the
title of the pull request is "Adding 'behavior.jquery' …". Your
supporting discussion also only references the positive outcomes for
the CMS in terms of adding jQuery support.

There is no problem in making code changes that help you with custom
implementations. "Those 3 kids" are probably reasonably general to
consider separately - that doesn't mean I agree with how you've coded
it, but I'm prepared to discuss the direction you want to head.
Though, I'd like to see more use case information about the pre and
post script functionality.

So, as this discussion here won't lead to an improvement to the javascript support in
the Platform, i'm stopping my own timewaste here on this as long as someone has
not actually read through the code and understood at least the first 3 files of the commit of this pull-request.

Like I said, take those out and put them in there own request and roll
the dice. I also think you should provide Unit Tests for those
changes, though it may be worth getting agreement on the architecture
first. And running your files though phpcs would also help.

I hope that clears up some confusion for you.

Regards,
Andrew Eddie

[azrul]

The engineer in me agree with Andrew, a clear saperation between php code and the UI layer is a much cleaner approach.

However, the more practical side of me agree with Beat. The craziness of multiple JQuery include in Joomla! CMS over the years (REALLY) need to stop. At the moment, I don't see mootools/javascript ever going to be removed from Joomla!-platform, hence whatever logic used to justify its inclusion in the first place (however faulty it may be), can/should be applied to JQuery as well.

[AmyStephen]

@azrul

With respect, I disagree with the notion that we should continue doing things that we now understand are not best practices simply on the basis that we have always done it that way before and I rather doubt you believe that either, or Jomsocial wouldn't be as successful as it is. Right?

This problem can be fixed - it has only been said that the PR should be made of the CMS.

[mbabker]

@beat The route I chose to follow in my methods is based on the JHtmlBehavior::framework() method and the fact that we are shipping jQuery with CMS 3.0. I'm not closed to alternatives, but given that we shouldn't need to support loading multiple versions of a JS framework in the code if we are shipping it (where do we support loading other versions of MooTools?), I chose this simple approach.

Also curious how my implementation does not use the API to load the JS.

[eddieajau]

On 22 August 2012 21:13, Azrul Rahim notifications@github.com wrote:

The engineer in me agree with Andrew, a clear saperation between php code and the UI layer is a much cleaner approach.

However, the more practical side of me agree with Beat. The craziness of multiple JQuery include in Joomla! CMS over the years (REALLY) need to stop. At the moment, I don't see mootools/javascript ever going to be removed from Joomla!-platform,

People also said the Platform would never happen :P There's no hurry
but it makes a lot of sense.

hence whatever logic used to justify its inclusion in the first place (however faulty it may be), can/should be applied to JQuery as well.

Allowing the Platform to perpetuate, in fact encouraging the craziness
is an equally bad idea.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[beat]

@mbabker Compare the clean use of existing API in https://github.com/joomla/joomla-platform/pull/1359/files to your implementation. And the well thought inclusion of generic Javascript supportive functions into the Platform.

My vote goes to include pull request #1359 into the Platform: it contains all our latest discussions on the minimum set that should go into the platform.

[mbabker]

Joe's pull has plenty of merits (and with a few tweaks, I'd be all for it). However, comma, to say that it is a clean use of existing API isn't exactly true as he has modified the API a bit to work with his implementation. He also avoids use of some of the API. To fully implement Joe's idea, here's what I would do at a minimum:

• Open some of the newly introduced API to be set with existing API methods (JFactory::getDocument()->addScript() and JHtml::script() for example)
• Modify JHtmlBehavior::framework() to work with the new code (MooTools IS a JavaScript library after all)
• If practical, try to allow registering libraries with JHtml::script()

I agree there should be a helper method to load jQuery, especially with it included in CMS 3.0. That said, the flaw that I see in these two pull requests is that they are directed very specifically at jQuery and to me look like the code being provided is a copy from another extension, meaning it doesn't really embrace the API. Additionally, the changes don't take into account the already existing JavaScript library in the Platform, and I don't agree with one library appearing to have preferential treatment over the other. It wouldn't be difficult to have our MooTools loading method use this new code as well, would it?

[beat]

I don't see why Mootools couldn't use same.

Also Pre and Post scripts are useful. You got yourself an example why Post-script is useful to add a single line of code without making an extra-http request or modifying a standard library.

Best would be for you to post those comments to pull request 1359, or better to fork it and make the changes you wish as you wish and then make a pull request to that fork, so Joe can review and merge (as Joe took the leadership of the Javascript workgroup as I understand) ?

[AmyStephen]

Both PR's under discussion are closed.

[eddieajau]

On 24 August 2012 11:06, beat notifications@github.com wrote:

Best would be for you to post those comments to pull request 1359

I suggest you also follow your own advice Beat - but you did challenge
Michael in this thread so I think he has the right of reply. And
for what it's worth, Michael's comments are right on the money so I
suggest you take heed.

[beat]

Andrew and Michael: I'm retracting my remark to Michael: Indeed I misread the changes proposed in https://github.com/mbabker/joomla-cms/compare/JScleanup#L13R27 the wrong way around, where Michael was indeed replacing the direct output of jquery in html by using the proper APIs.

Michael: Sorry about that. I was just getting too tired and misread the diff.

I think and hope this closes all polemics in here.

[parthlawate]

So whats the take on this ?

[ianmacl]

This was closed almost a year ago parthlawate.

[parthlawate]

Oops !