JDocument/addJsScript - RequireJS (dependency management) in Joomla

[Anibal]

Hi,

I've been working based on RequireJS to introduce Javascript file and module loader. 

Why Web Modules? http://requirejs.org/docs/why.html 

Why AMD? http://requirejs.org/docs/whyamd.html

I've already implemented in my products with no issue, solving conflicts and J2.5/J3 compatibility.... the problem is a second RequiredJS instance, if a second developer tries to load also RequireJS!

I have the idea to add a new method to JDocument. In this way:

JDocument/addJsScript

void addJsScript( $url, $jsModuleId, $jsDependencies, $jsExport = null ) 

For example:

$lib = JUri::root() . 'media/lib_extly/js/utils/jquery.xtajaxbutton.js';

$dependencies =  array('jquery');

$document->addScript( $lib, '', 'xtajaxbutton', $dependencies, 'XtAjaxButton' );

It generates this code in the frontend:

<script src="..../media/lib_..../js/require/require.min.js" type="text/javascript"></script>

<script type="text/javascript">

var jooDependencies = [];
var jooPaths = [];

jQuery(document).ready(function () {
	"use strict";

	var dependencies, paths, allKeys, config = {
		baseUrl: 'http://l..../media',
		shim: {},
		paths: {}
	};

	// Additional dependencies
	jQuery.each(jooDependencies, function(index, dependency) {
  		config.shim[dependency.key] = dependency.value;
	});

	// Additional paths
	allKeys = [ ];
	jQuery.each(jooPaths, function(index, path) {
		allKeys.push(path.key);
  		config.paths[path.key] = path.value;
	});

	// Require.js allows us to configure shortcut alias
	require.config(config);
	require(allKeys, function(Core) {

	});

});
jooDependencies.push({key:'underscore', value:{exports: '_'}});
jooDependencies.push({key:'backbone', value:{deps: ['underscore'], exports: 'Backbone'}});

jooDependencies.push({key:'ajaxbutton', value:{exports: 'XtAjaxButton'}});
jooPaths.push({key:'ajaxbutton', value: 'http://l..../media/lib_..../js/utils/jquery.jooajaxbutton'});
jooPaths.push({key:'underscore', value: 'http://l..../media/lib_..../js/backbone/lodash.min'});
jooPaths.push({key:'backbone', value: 'http://l..../media/lib_..../js/backbone/backbone.min'});
  </script>

What do you think? Opinions?

Thanks,

Anibal

[Ofer Cohen]

Sound great idea to 4.x series.

Ofer Cohen

http://embad.com 
Facebook | Twitter | LinkedIn

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Fedir]

to be honest, it looks very bad...

1) if RequireJS be part of Joomla, and some developer tried load a second RequiredJS instance, then it this developer problem..

2) I did not see what inside of you version for addJsScript( $url, $jsModuleId, $jsDependencies, $jsExport = null ) ...but better way to render final script it in header renderer, until this all info about script should be as array/object

 

Субота, 25 травня 2013 р. 15:58:18 UTC+3 користувач Anibal написав:

[Fedir]

mean something like:

addScriptLibrary($library, $js_code, $dependacy = array(), some other args){
 $this->libraries[$library] = array(

   'library' => $library,

   'dependancy' => $dependacy

   .. so on

 )

}

then in JDocumentRendererHead fetchHead()

if(!empty($document->libraries)){

 //render the code for RequireJS 

}

Субота, 25 травня 2013 р. 15:58:18 UTC+3 користувач Anibal написав:

Hi,

[Anibal]

Hi Fedir,

1) The idea is to provide support for Javascript dependency management API at CMS level. In this way we can avoid two conflicting extensions loading the same RequireJS. The library is loaded by Joomla, not by each developer.

2) Yes, the JS initialization is done in the header.

Additionally, with RequireJS you can compile all modules in a single file (like the current Less support in the template area). Also, If modules and AMD become part of the next Javascript standard, the whole library can be dropped based in the future browser support.

Regards,

Anibal

[Fedir]

Javascript dependency management it songs good...

I meant another...

use RequireJS it is good for avoid conflicts between extensions(by better scripts control), but you suggest fix for avoid conflict between two RequireJS...

it songs like "fix for fix" .. is not it?

if the code for RequireJS renders at last step (in the head render) then what is cause of two RequireJS instances?

if it just because some developer want to add RequireJS in other way that it is in Joomla - then it this developer problem

Неділя, 26 травня 2013 р. 18:53:02 UTC+3 користувач Anibal написав:

[Anibal Sanchez]

The objective is to introduce dependency management, and coordinate Javascript modules in the CMS.

Please, let me know if you have a better solution for the problem.

A

2013/5/26 Fedir <fed...@gmail.com>

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/s2Wqo7eNKfo/unsubscribe?hl=en-GB.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Fedir]

but you still not explained the problem...

sorry, maybe I was not clear, so try again...

problem in you example that it make the additional dependency from jQuery, where  is unnecessary ... 

What the problem to render the final code in the header render() like:

 require.config(something)
 require.config(something2)
 require.config(something3)

 

 require(something, callback)
 require(something2, callback)
 require(something2, callback)

or even more simple, just:

 require.config(all data passed to addScript)
 
 require(something, callback)
 require(something2, callback)
 require(something2, callback)

Неділя, 26 травня 2013 р. 23:40:25 UTC+3 користувач Anibal написав:

[Amy Stephen]

Fedir -

There's no doubt that fixing this problem in the API by defining dependencies at the point in time each asset is added, and resolving these problems during the document build process, is a better approach. The problem is writing that code, ensuring no backward compatibility issues, and building test cases that ensure it all works fine. If you are interested in proposing code for that, it would definitely be worth looking at.

Meanwhile, what Anibal is doing is leveraging a solution that is widely accepted by the frontend developer community as a good "work around." In doing so, you are right, he's adding another dependency on Joomla, and runs the risk of then having an outdated version in the core that frontend devs will try to override, and so forth. Whether that's worthwhile or not is a matter of opinion. It's likely those who build a lot of websites with Joomla would see this as beneficial.

There are many different ways to solve any problem. Solving the problem in PHP would be ideal, but it's not going to be simple, it must not break existing sites, it must be backward compatible, and maybe most importantly, it has to be in code, not just an idea. If you have interest, I'd encourage you to give it a try, post the code on github as a PR, and see where it leads.

Meanwhile, this is a big problem for frontend devs. Might be worth having some of them look at what Anibal is doing to see if it might help "ease the pain" so to speak.

Hope that makes sense.

[Anibal Sanchez]

Hi,

I've added the 'jquery' dependency just for declarative purposes and J25 compatibility. In J3, it could be dropped, since the require initialization is done after the domready event.

CMS generates a single require.config, where all paths and dependencies are defined. The user defines each JS module with its own define(['jquery', 'chosen', 'backbone'.... etc], callback);


Thanks,
Anibal

2013/5/27 Fedir <fed...@gmail.com>

[Anibal Sanchez]

Hi Ami,

About BC, it's a new method in the Document, and it's loaded after domready. As RequiresJS is widely used, it should't have a conflict with current addScript or addScriptDeclaration generated Javascript.

The idea is to begin moving Javascript vanilla code as modules. For example, in the GSoC project to migrate from MooTools

I'm going to send a PR with the proposal.

Thanks,
Anibal

2013/5/27 Amy Stephen <amyst...@gmail.com>

[Amy Stephen]

Sorry for the confusion, to clarify, Anibal, I understand your solution is BC.

What I understand Fedir to be proposing is to change the existing API calls in the PHP and solve the problem in the HTML Document classes that render the JS statements. Perhaps I misunderstood him, but if that is his recommendation, then it will take some work writing and testing that code and it must be tested for BC issues.

Your approach avoids that problem.

[Amy Stephen]

On Monday, May 27, 2013 9:13:27 AM UTC-5, Anibal wrote:

The idea is to begin moving Javascript vanilla code as modules. For example, in the GSoC project to migrate from MooTools

+1 Javascript vanilla. Yea! Nice to have someone who understands JS contributing. Thanks!

[Fedir]

critic it is gooood! 

so I will continue :-p

First would be good to see explanation for what is AMD in Joomla! CMS context, not just two link to RequireJS documentation...

If it just additional API for allow to use RequireJS in the Joomla - it is one thing,

If it part of JavaScript refactoring, for use it by default in the core (after move Mootools->jQuery) - it is another thing.

this state is not clear for me...

Now some thoughts about how it can be in the core.

addScript - can stay

addScriptDeclaration - can stay

addJsScript - better should be as addLibrary() or addScriptLibrary()

All libraries (jquery, and so on) should be defined via addScriptLibrary() , something like Anibal already suggested  addScriptLibrary($url, $jsModuleId, $jsDependencies, $jsExport = null ).

Then Joomla render the config for RequireJS depends from added libraries ... and keep respect for the scripts that added by addScript() and addScriptDeclaration

change the existing API calls in the PHP and solve the problem in the HTML Document classes that render the JS statements

yes Amy, you understand me right ;)

so final JS output will looks like:

var config = {/*config object, rendered by Joomla*/};
require.config(config);
require(['scripts added via addScript() + other RequireJS things'], function (Core) {
  //here some core configuration if need
  //here inline scripts add via addScriptDeclaration()
});

In theory, in this case we should not get  the big problem with legacy, just need a lot work for move Joomla to AMD (I prefered "Intel" but who cares :) )...

Core - it is core.js (changed of course :) ) that should be at top of other scripts...

But! 

For continu better have a good plan...

Понеділок, 27 травня 2013 р. 17:29:35 UTC+3 користувач Amy Stephen написав:

[Anibal Sanchez]

Hi Fedir,

About AMD in Joomla! CMS context:

1. Until now Joomla 's been packaging Mootools code in several ways, and extension developers also distributed Mootools code. Version conflicts, and duplicated code are common. In this time, jQuery has become dominant.

2. Now, with Bootstrap and jQuery on board, we can also adopt new practices already adopted. Eg modularization

... In the other hand, we can follow the current practice, and renew the Javacript conflicts with new libraries! ;-)


PD: addScriptModule might better

Thanks,
Anibal

2013/5/28 Fedir <fed...@gmail.com>

--

[Nick Savov]

Hi Anibal,

This looks great to me! It's nice having a Javascript ninja like you
around :)

Could you send a PR for it and create a tracker item for it? If you need
help with either of these two steps, please let us and we'll be glad to
help!

Cheers,
Nick

> Hi,
>
> I've been working based on RequireJS to introduce Javascript file and
> module loader.
>
> Why Web Modules? http://requirejs.org/docs/why.html
> Why AMD? http://requirejs.org/docs/whyamd.html
>

> *I've already implemented in my products with no issue, solving conflicts

> and J2.5/J3 compatibility.... the problem is a second RequiredJS instance,

> if a second developer tries to load also RequireJS!*
>
> I have the idea to add a new method to *JDocument**. *In this way:

>
> JDocument/addJsScript
> void addJsScript( $url, $jsModuleId, $jsDependencies, $jsExport = null )
>
> For example:
>
> $lib = JUri::root() . 'media/lib_extly/js/utils/jquery.xtajaxbutton.js';
> $dependencies = array('jquery');
> $document->addScript( $lib, '', 'xtajaxbutton', $dependencies,
> 'XtAjaxButton' );
>
> It generates this code in the frontend:
>
> <script src="..../media/lib_..../js/require/require.min.js

> <view-source:http://local-server.extly.net/j3/media/lib_extly/js/require/require.min.js>"

> *jooDependencies.push({key:'ajaxbutton', value:{exports:
> 'XtAjaxButton'}});*
>
> *jooPaths.push({key:'ajaxbutton', value:
> 'http://l..../media/lib_..../js/utils/jquery.jooajaxbutton'});*jooPaths.push({key:'underscore',

> value:
> 'http://l..../media/lib_..../js/backbone/lodash.min'});
> jooPaths.push({key:'backbone', value:
> 'http://l..../media/lib_..../js/backbone/backbone.min'}); </script>
>
>
> What do you think? Opinions?
>
>
> Thanks,
>
> Anibal
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Anibal Sanchez]

Hi Nick,

Thanks, I have the code already written, but I've to prepare it for submission. I'm sending the PR this week.

Thanks,
Anibal

2013/5/30 Nick Savov <ni...@iowawebcompany.com>

You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/s2Wqo7eNKfo/unsubscribe?hl=en-GB.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Anibal Sanchez]

Hi,

This is the PR: https://github.com/joomla/joomla-cms/pull/1227

• With this new JDocument method, addJavascriptModule, a set of Javascript modules (with dependencies can be declared)
• The modules can have a common $moduleId "name", so it can be shared CMS-wide Ej jquery17, backbone, underscore, etc.
• If multiples modules with the same name are defined, it wins the last one.

/**
 * Adds a linked javascript module to the page.
 *
 * Example:
 *
 * $doc->addJavascriptModule('mediamanager', 'media/media/js/mediamanager.js');
 * $doc->addJavascriptModule('installation', 'installation/template/js/installation.js', array('mediamanager'));
 *
 * Reference: Why AMD? http://requirejs.org/docs/whyamd.html
 *
 * @param   string   $moduleId      Value of module identication in the module loader.
 * @param   string   $url           URL to the linked script
 * @param   array    $dependencies  Array of module dependencies
 *
 * @return  JDocument instance of $this to allow chaining
 *
 * @since   11.1
 */
public function addJavascriptModule($moduleId, $url, $dependencies = array())

....

I've minimally tested it. I'm going to give it more testing implementing the jQuery installer. Please, let me know if it's Ok.

Thanks,
Anibal

[piotr_cz]

Good job

- Is it required to introduce 2 new global variables (jDependencies and jPaths)?

Looking at the source code, I'd say you can wrap whole JS part in self-invoking anonymous function, or use already available Joomla namespace for exports.

- What do we need jQuery for in head.php?

[Anibal Sanchez]

Hi,

1. Yes, you are right :-) It's comming in the next commit.

2. About jQuery/.ready for in head.php:

Conservative option: It's safest (and slower). Modules are loaded after jQuery.ready, and everything else (latest actor to join the party). All modules have jQuery access (even mootools modules).

Open option: No jQuery.ready. Modules are loaded in parallel. As previous jQuery instance is not managed, each module must implement its own .ready to have jQuery as a dependency, or load its own jQuery instance (beyond previous Mootool and JQuery instances ;-) ).

Extreme option: Drop addScript and addScriptDeclaration, everything is loaded as module, and there's a directory of known modules. Dependencies are fine-grained. ;-)

Until now, I've implemented the Conservative option. It adds a delay, but it works. The open option can be more fine tuned, but the developer has to remember to add jQuery.ready.

Which is the best alternative at this moment?

Thanks,
Anibal

2013/6/3 piotr_cz <pkoni...@hotmail.com>

[piotr_cz]

Aha, thanks for explaination.

I'd opt for *Open option* because I like open options :)
- module doesn't have to use domready event, or don't have to be all
wrapped in it. Think of jQuery plugins which are initialized manually
- these can be loaded before domready fires.
- this option doesn't force using/loading jQuery.

*Conservative option* could have an advantage that's been discussed
here last week (defer)
It postpones loading of all the scripts after page is rendered to
user.

On Jun 3, 2:36 pm, Anibal Sanchez <anibal.sanc...@gmail.com> wrote:
> Hi,
>
> 1. Yes, you are right :-) It's comming in the next commit.
>
> 2. About jQuery/.ready for in head.php:
>

> *Conservative option*: It's safest (and slower). Modules are loaded after

> jQuery.ready, and everything else (latest actor to join the party). All
> modules have jQuery access (even mootools modules).
>

> *Open option*: No jQuery.ready. Modules are loaded in parallel. As previous

> jQuery instance is not managed, each module must implement its own .ready
> to have jQuery as a dependency, or load its own jQuery instance (beyond
> previous Mootool and JQuery instances ;-) ).
>

> *Extreme option*: Drop addScript and addScriptDeclaration, everything is

> loaded as module, and there's a directory of known modules. Dependencies
> are fine-grained. ;-)
>
> Until now, I've implemented the Conservative option. It adds a delay, but
> it works. The open option can be more fine tuned, but the developer has to
> remember to add jQuery.ready.
>
> Which is the best alternative at this moment?
>
> Thanks,
> Anibal
>

> 2013/6/3 piotr_cz <pkoniec...@hotmail.com>

>
>
>
>
>
>
>
> > Good job
>
> > - Is it required to introduce 2 new global variables (jDependencies and
> > jPaths)?
> > Looking at the source code, I'd say you can wrap whole JS part in
> > self-invoking anonymous function, or use already available Joomla namespace
> > for exports.
>
> > - What do we need jQuery for in head.php?
>
> > On Saturday, May 25, 2013 2:58:18 PM UTC+2, Anibal wrote:
>
> >> Hi,
>
> >> I've been working based on RequireJS to introduce Javascript file and
> >> module loader.
>

> >> Why Web Modules?http://requirejs.org/docs/why.**html<http://requirejs.org/docs/why.html>
>
> >> Why AMD?http://requirejs.org/**docs/whyamd.html<http://requirejs.org/docs/whyamd.html>
>
> >> *I've already implemented in my products with no issue, solving

> >> conflicts and J2.5/J3 compatibility.... the problem is a second RequiredJS

> >> instance, if a second developer tries to load also RequireJS!*
>
> >> I have the idea to add a new method to *JDocument**. *In this way:

>
> >> JDocument/addJsScript
> >> void addJsScript( $url, $jsModuleId, $jsDependencies, $jsExport = null )
>
> >> For example:
>

> >> $lib = JUri::root() . 'media/lib_extly/js/utils/**
> >> jquery.xtajaxbutton.js';

> >> $dependencies =  array('jquery');

> >> $document->addScript( $lib, '', 'xtajaxbutton', $**dependencies,

> >> 'XtAjaxButton' );
>
> >> It generates this code in the frontend:
>

> >> <script src="..../media/lib_..../js/**require/require.min.js" type="text/javascript"></scrip**t>

>
> >> <script type="text/javascript">
>
> >> var jooDependencies = [];
> >> var jooPaths = [];
>

> >> jQuery(document).ready(**function () {

> >>        "use strict";
>
> >>        var dependencies, paths, allKeys, config = {
> >>                baseUrl: 'http://l..../media',
> >>                shim: {},
> >>                paths: {}
> >>        };
>
> >>        // Additional dependencies
> >>        jQuery.each(jooDependencies, function(index, dependency) {
> >>                config.shim[dependency.key] = dependency.value;
> >>        });
>
> >>        // Additional paths
> >>        allKeys = [ ];
> >>        jQuery.each(jooPaths, function(index, path) {
> >>                allKeys.push(path.key);
> >>                config.paths[path.key] = path.value;
> >>        });
>
> >>        // Require.js allows us to configure shortcut alias
> >>        require.config(config);
> >>        require(allKeys, function(Core) {
>
> >>        });
>
> >> });

> >> jooDependencies.push({key:'**underscore', value:{exports: '_'}});
> >> jooDependencies.push({key:'**backbone', value:{deps: ['underscore'], exports: 'Backbone'}});
>
> >> *jooDependencies.push({key:'ajaxbutton', value:{exports: 'XtAjaxButton'}});*
>
> >> *jooPaths.push({key:'ajaxbutton', value: 'http://l..../media/lib_..../
> >> js/utils/jquery.jooajaxbutton'});*
> >> jooPaths.push({key:'**underscore', value: 'http://l..../media/lib_..../**js/backbone/lodash.min'});
> >> jooPaths.push({key:'backbone', value: 'http://l..../media/lib_..../**js/backbone/backbone.min'});

> >> </script>
>
> >> What do you think? Opinions?
>
> >> Thanks,
>
> >> Anibal
>
> >>  --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "Joomla! CMS Development" group.
> > To unsubscribe from this topic, visit

> >https://groups.google.com/d/topic/joomla-dev-cms/s2Wqo7eNKfo/unsubscr...
> > .

[Anibal Sanchez]

1. It's done.

2. Ok ok, I'll remove the .ready

Also, I've opened the associated tracker:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=31071


Tahnsk,

2013/6/3 piotr_cz <pkoni...@hotmail.com>

To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/s2Wqo7eNKfo/unsubscribe?hl=en-GB.

[Fedir]

oh man...

+1 for topic pick up

- 2 for realisation

I still prefer to use addScriptLibrary name.. but it no bigger problem 

for me still not clear why so tricky...

check quick alternative https://gist.github.com/Fedik/b122674346fefdffc375

no jquery, no big tricks...

but it still looks like just additional API for allow to use Require.js in Joomla and nothing more.

if there some plan to move whole joomla to use Require.js then need some more, similar to what I was trying to explain above https://groups.google.com/d/msg/joomla-dev-cms/s2Wqo7eNKfo/5x7oqXntSvEJ

JavaScript in joomla feels not so good ... so please do not do a lot more bad :)

Понеділок, 3 червня 2013 р. 17:45:03 UTC+3 користувач Anibal написав:

[Anibal Sanchez]

Hi Fedir,

Very clean alternative, and simpler configuration. :-) Tomorrow, I'm removing the .ready event, and improving the code with your alternative.

According the JAB13 presentation (one of them, I can't remeber which one), the GSoc project to move all Javascripts from MooTools to JQuery is very near. So, if we can have the API ready, the project can be based in this idea.


Thanks,
Anibal

2013/6/3 Fedir <fed...@gmail.com>

[piotr_cz]

nice, I was about to propose moving require.config configuration to
server-side, but lately I'm rather backend oriented (gosh, this sounds
strange)

On Jun 3, 9:45 pm, Fedir <fed...@gmail.com> wrote:
> oh man...
> +1 for topic pick up
> - 2 for realisation
>
> I still prefer to use addScriptLibrary name.. but it no bigger problem
>
> for me still not clear why so tricky...
>

> check quick alternativehttps://gist.github.com/Fedik/b122674346fefdffc375

> no jquery, no big tricks...
>
> but it still looks like just additional API for allow to use Require.js in
> Joomla and nothing more.
> if there some plan to move whole joomla to use Require.js then need some

> more, similar to what I was trying to explain abovehttps://groups.google.com/d/msg/joomla-dev-cms/s2Wqo7eNKfo/5x7oqXntSvEJ

>
> JavaScript in joomla feels not so good ... so please do not do a lot more
> bad :)
>
> Понеділок, 3 червня 2013 р. 17:45:03 UTC+3 користувач Anibal написав:
>
>
>
>
>
>
>
>
>
> > 1. It's done.
>
> > 2. Ok ok, I'll remove the .ready
>
> > Also, I've opened the associated tracker:
>

> >http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEd...
>
> > Tahnsk,
>
> > 2013/6/3 piotr_cz <pkoni...@hotmail.com <javascript:>>

> >> > > joomla-dev-cm...@googlegroups.com <javascript:>.
> >> > > To post to this group, send an email to joomla-...@googlegroups.com<javascript:>
> >> .
> >> > > Visit this group athttp://
> >> groups.google.com/group/joomla-dev-cms?hl=en-GB

> >> > > .
> >> > > For more options, visithttps://groups.google.com/groups/opt_out.
>
> >> --
> >> You received this message because you are subscribed to a topic in the
> >> Google Groups "Joomla! CMS Development" group.
> >> To unsubscribe from this topic, visit

> >>https://groups.google.com/d/topic/joomla-dev-cms/s2Wqo7eNKfo/unsubscr...
> >> .
> >> To unsubscribe from this group and all of its topics, send an email to

> >> joomla-dev-cm...@googlegroups.com <javascript:>.
> >> To post to this group, send an email to joomla-...@googlegroups.com<javascript:>
> >> .

[Anibal Sanchez]

Hi,

I've improved the code based on Fedir's feedback and source code.

public function addJavascriptModule($name, $url, $options = array())

• About the name, I prefer to call the files Javascript Modules. "Script Libraries" is more generic ... but RequireJS usage is intended for Javascript Modules (even if it can load anything), and the idea behing the API is to add support for the Javascript Module Pattern.
  
• About core.js, we are not changing how Joomla currently loads Javascript, just adding a new API to begin working with Javascript Modules in Joomla.
  

Usage:

     $doc->addJavascriptModule('mediamanager', 'media/media/js/mediamanager.js');

     $doc->addJavascriptModule(
              'installation',
              'installation/template/js/installation.js',
              array(

                      'dependencies' => array('mediamanager')
              )
     );

It generates:

  <script type="text/javascript">
    (function() {
      var config = {"baseUrl":"/joomla-cms","paths":{"mediamanager":"media/media/js/mediamanager","installation":"installation/template/js/installation"},"shim":{"installation":{"deps":["mediamanager"]}}};
      require.config(config)
      require(["mediamanager","installation"]);
    })();
  </script>

Thanks,
Anibal

2013/6/3 piotr_cz <pkoni...@hotmail.com>

nice, I was about to propose moving require.config configuration to

To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/s2Wqo7eNKfo/unsubscribe?hl=en-GB.

To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

[Anibal Sanchez]

I found it!

In this JAB presentation, The State of joomla, Andy Tar confirmed MooTools to jQuery as a GSoC project (around 16')

https://www.youtube.com/watch?v=o3i2o_vyyfE

Thanks,
Anibal

[Fedir]

looks good,

but you know what I was noticed? that this still not optimized...

if we call require() for all modules that added, then it break all profit that we can get, because it tell to require.js to load all scripts at once, same as we just use:

<scrip src="scrip1.js">

<scrip src="scrip2.js">

<scrip src="scrip3.js">

but the first require() should load only the initial scripts for get a real profit from require.js, other way it have no big sense .. no?

here still need to think...

Середа, 5 червня 2013 р. 16:38:52 UTC+3 користувач Anibal написав:

[Anibal Sanchez]

Hi,

The main require pulls for everything declared.... at the end. And, it solves the dependencies. so the order is followed.

If it wasn't declared as an explicit dependency in the PHP, it could also be declared in the module.

... It's better if you declare named dependencies in the module only, to avoid duplication, and only define paths in the config.

The only issue is if you declare an optional dependency (just in case it's used), because it's forced to be loaded in the main require. In this case, it's clearly better to declare only the path, and leave the dependency declaration for the module.


Thanks,
Anibal

[Fedir]

yes, this is right,

I mean other. Require.js allow to keep bandwidth, by loading the script only when it really need ... first you load only the initial modules and then this scripts load all what they need...

Середа, 5 червня 2013 р. 17:48:06 UTC+3 користувач Anibal написав:

[Anibal Sanchez]

Yes, I think the general recomendation is to declare only the main modules and paths; leaving the manager to pull what it's needed.

Thanks,
Anibal

2013/6/5 Fedir <fed...@gmail.com>

--

[Fedir]

this can be achieved by adding one more option, like "main" => true, and then for require() we add only the scripts that have this option.

So it will keeps the general recommendation :)

But one more thoughts..

this still is not a real dependency manager ... 

RequireJS do this job good only in the self made application, when all script in the one folder, but in CMS it is different... 

User should do addJavascriptModule() for each dependency, after applying the current pull/patch.

Example I want add myscript that have dependencies jquery, some-other, some-other1

then I should call addJavascriptModule() for dependencies too:

addJavascriptModule('jquery');
addJavascriptModule('some-other', dependencies=> jquery);
addJavascriptModule('some-other1', dependencies=> jquery);
addJavascriptModule('myscript', dependencies=> jquery, some-other, some-other1);

Looks very bad, especially if there a lot dependencies, right?

So only RequireJS not enough ... need some more gears in backend.

Need a some mechanism for take and count dependencies automatically.

For this would be good to have a some mechanism for a libraries/modules registration.

It can be done via plugins system, and then all dependencies will be counted in time when added new library.

So it can work like next:

In time before component execution, joomla call "script-libraries" plugins, and they do self registration.

Then when someone add a new library, we count dependencies automatically.

Also Joomla can call "script-libraries" only in time first call of the addScriptLibrary function.

Small image for a better imagination :)

Середа, 5 червня 2013 р. 20:01:13 UTC+3 користувач Anibal написав:

[Anibal Sanchez]

Hi,

Sure, it can be more sophisticated, and add more server-side pre-processing/caching (It's a LESS-like situation/compilation/pre-processing).

I've opted to keep it simple and already implemented it in products in this way. At the end, you have just a few of dependencies in each module. Eg:

jquery -> underscore -> backbone -> yourmodule (this one has define['backbone'])

You can just specify the path, and leave the dependency declaration in the module (better approach).

Only, you need to specify dependencies for JS plugins/libraries (which are not AMD modules with "define[bla bla]").


Thanks,
Anibal

2013/6/13 Fedir <fed...@gmail.com>

[Fedir]

it was just for extend a you idea, as possible next step for a javascript dependencies manager

You can just specify the path, and leave the dependency declaration in the module (better approach). 

right, but still need to specify the path ;)

jquery -> underscore -> backbone -> yourmodule (this one has define['backbone'])

yes, but small problem, joomla know nothing about this, so will not add the paths for "jquery" and "underscore" to the require.config, as result dependencies will be broken

Четвер, 13 червня 2013 р. 19:09:48 UTC+3 користувач Anibal написав: