This is interesting. Did you think about delegated events?

yes, there already was suggestion about using the delegation....
delegation is good if you make whole app from zero and know "what where" ... and it not so flexible for interaction between different extensions from different developers

I like the setScriptOptions idea, especially where options are passed in as php objects and later its json encoded out, which is safer than script declarations. A lot of developers pass in js options via addScriptDeclaration and whenever there's an error in their script it just wrecks subsequent script declarations that comes after it.

And the addEvent/fireEvent too, this really tidy things up because 3rd party extensions expects you to listen to their events on their html elements (or they probably provide their own custom event api) which gets really messy because everyone's doing their own thing.

But I also think it would be interesting to see a Deferred variation of the addEvent/fireEvent. This is because the event might get fired first before the person that listens to the event attaches to the event. This is especially true for sites with js compressor plugins installed which they tend to mess up the ordering of script execution.

the one container for store the script options moved to the separated pull #11319

Hi Fedik,

For the GSoC 2013, I'm doing the project converting MooTools to jQuery and most of the parts are already done. I'm not sure what are the changes I need to do based on your PR and the conflicts that needs to be resolved to merge both to the CMS. Any suggestions?

You can find details of my work from the following Feature tracker items.
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31575&start=500
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31576&start=500
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31577&start=500
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31578&start=500
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31579&start=500
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31580&start=500
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31581&start=500
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31582&start=500
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31583&start=500
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31591&start=500

Modifications still not in Feature Tracker
https://github.com/AshanFernando/joomla-cms/tree/gsoc-mootools-jquery-administratorcomponents
https://github.com/AshanFernando/joomla-cms/tree/gsoc-mootools-jquery-administratortemplates

good question ;)

current realization work without any JS library, so should be no any conflict with jQuery or something ...
I had a hope make the Joomla front-end independent from any JS library :)

I thought about next additional changes in CMS (if we use such idea):

• load the core.js on top of the all scripts, means when someone call "addScript" or any other method that add the scripts, we first add core.js then requested script - this allow to be sure that core.js always available, and allow to avoid the code duplication like in JText::script case ... but now when we will use jQuery as required I not sure ....
• change all Joomla behaviors and other script initialization in CMS to use Joomla.addEvent('domready.extension', callback) and use setScriptOptions() from #1319

but:
I got not enough feedbacks about current realization, so I am not sure how good is it.
Also in the other discussion I found other idea: make it using the event bubbling, something similar to the delegation but not really ... this should be a better solution than I made in the current patch.
there https://github.com/Fedik/joomla-cms/compare/jsinit-jq I tried some in this way. There I use jQuery, but it should be possible without (if need) :)
there all very simple, it works like next:

//event subscription
jQuery(document).on('jload.extension', callback);

//when something changed, we fire event on changed element:
jQuery('unloaded-element').trigger('junload');

//in the callback we take changed element
function callback(event){
 var changed = event.target;
}

other possible solution it is use "Signals"...

this topic required more feedback as we have now,
so unfortunately I cannot tell you clear answer what to do next...

First of all, please fix spelling mistakes in your code. In the PHP code, you have otions instead of options. Second of all, if you still want this to be merged in, please update your branch to the latest of the staging branch.

Besides those 2 points, I don't think this is a good idea. As I already wrote on the mailinglist, I don't think it is a good idea to introduce yet-another-abstraction for the javascript just in case someone wants to use obscure-JS-framework XY instead of jQuery. We should also not branch into the area of writing our own JS framework with event handling etc. That is not our area of expertise and we would only re-invent the wheel here. That said, I would reject this PR.

As I already wrote on the mailinglist

in which?

we would only re-invent the wheel here

without re-invent the wheel Humans would live in caves and use the wagons instead of the cars

... in case someone wants to use obscure-JS-framework XY instead of jQuery

I think you did not understand the purpose of my suggestion.
It more about interaction between the extensions, when one extension will get possibility to watch on what was modified by other extension(s).

Maybe the realisation is not perfect, but currently I did not found a better solution, if someone has a better idea please share.

Hello @Fedik, I wrote that one the joomla-dev-cms mailinglist. I looked through your description and the method names again and I still can't see the difference between the event system of jQuery and this. You can create your own events in jQuery, too, and you can attach your own code to it, too. Considering that we had discussions in the past that proposed to introduce a compatibility layer between Joomla and the Javascript library of choice, I wrote that we should concentrate on what is pur area of expertise and not venture into writing our own JS library. Joomla uses jQuery as a standard and is moving away from mootools. There is no reason for us to integrate another JS library or write our own.

@Hackwar sorry I wrong understand you,
you just ask why not jQuery?

Well, when I started it, we use Mootools, and migration to jQuery only started.
Also I not very liked idea of the deep integration with any JS library, because after some time we will get same problem as with Mootools.
Another thing, that suggested API require that it must be available always on the page (and on top of all other scripts) when someone (extension/template etc.) use JavaScript. So in case standalone realisation we will have only core.js required, and in case jQuery we will need jQuery + core.js.
And in theory such approach, where core.js is the base, can allow more simple use of something like Requirejs, or make very light design since CSS3 allow to replace a lot things where people use jQuery.

Of course such API possible with jQuery, I already tried something jsinit-jq ...

Again: We standardized everything on jQuery now. We will stick with jQuery for the forseeable future and jQuery and its syntax is EXTREMELY widely adopted, thus people know it deeply. You are asking us to introduce yet another JS library, that is not widely tested, not known at all and which would mean that extension developers again have to change their code. Besides that, the code currently does not even remotely cover the functionality of jQuery and thus people will include jQuery, too. That again means that not only do we have the larger core.js file, but also jQuery on every page.

You are asking us to introduce yet another JS library

It not really library, it just an base events handling ... look on this as on "joomla plugin API" but for the frontend.
And I never told that my solution is perfect
But I did not got any suggestion how to make it better/different.

Besides that, the code currently does not even remotely cover the functionality of jQuery and thus people will include jQuery

I did not tried "write own jQuery".

which would mean that extension developers again have to change their code

yes of course

jQuery and its syntax is EXTREMELY widely adopted

I agree, but ... wait I will write you some example....

@Hackwar let`s imagine, you write a very cool Gallery plugin. In your code for initialise the gallery script you use:

jQuery(document).ready(function($){
 $('.cool-gallery').myCoolGallery(/*dynamic options*/);
})

Well, all works perfect, I installed it on my site and I am happy.

But now I found the template for my site, where the content loaded using AJAX request.
Since we can use tmpl=ajax, it very simple.

jQuery(document).ready(function($){
 $('#menu ul.menu a').on('click', function(){
   $('#content-container').load($(this).attr('href'),  {tmpl: 'ajax'});
 });
})

All works perfect, until I tried open page where the Gallery, and nothing works there, what the...? (I think)
So now I am not happy from you Gallery plugin

Now the question what I should do?

P.S.: same problem with the repeatable field, when the field use some javascript gets broken when used in repeatable field.

I don't believe this should be merged as we are standardizing on jQuery as mentioned by Hannes. Let's see what @wilsonge and @Bakual think of this. Guys, please check and let me know if you agree on closing this PR.

I'm unsure tbh. On one hand we are standardising on jQuery - but on the other jQuery is already quickly becoming old hat now better javascript support is coming in through the browsers. Many libraries no longer require jQuery anymore. So many places we're just using jQuery for checking domReady and then native javascript might be nice to have 'our own' way of doing it.

@Fedik After discussing this in the PLT, we have decided that this should not be added to the core. Thank you for your contribution and ideas.