$this->content->text = <<< EoS <script type="text/javascript" src="$CFG->wwwroot/lib/yui/yahoo/yahoo.js"> </script> <script type="text/javascript" src="$CFG->wwwroot/lib/yui/connection/connection.js"> </script> <script type="text/javascript" src="$CFG->wwwroot/lib/yui/event/event.js"> </script> <script type="text/javascript"> // code here </script> EoS;Thanks
Hi,
I've been trying to create a simple block that needs access to some parts of the YUI library. Is there anyway I can detect if the components I need might have already been loaded?
Also is there a better way of loading them than using something like this inside the block?
The YUI loading looks like:
<?php require_once($CFG->libdir.'/ajax/ajaxlib.php');
echo require_js(array('yui_yahoo','yui_dom','yui_event','yui_animation')); ?>
with the libraries you need listed.
Detecting is not jet done - will be neccessary when more developers use YUI. Library detection or central library loading should be in 1.8 I suppose.
You may look at MDL-7682. Andy do you have an idea how to solve central YUI loading?
require_js could easily detect whether something's been loaded already using a simple static variable (even if it doesn't right now). So definitely using the function is the way to go for all code, that way when it is fixed it will work everywhere.
My problem with it is the same one mentioned in MDL-7682 I needed something to work using YUI (it's an optional feature - we don't provide a non-Javascript alternative at present) but we don't want to turn on the drag-and-drop course format features. In our code I hacked it, not great though!
--sam
My problem with it is the same one mentioned in MDL-7682 I needed something to work using YUI (it's an optional feature - we don't provide a non-Javascript alternative at present) but we don't want to turn on the drag-and-drop course format features. In our code I hacked it, not great though!
--sam
Thanks
Yep, it looks like require_js is the future Although, I'm in the same situation - I'd like to use it to get at the YUI files without necessarily wanting to the drag and drop course format enabled.
Yep, it looks like require_js is the future
I added a new Subtask MDL-8374 in the Moodle tracker. You may add your patches or suggestions there to help Vy solve the issue.
You may also vote for the issue.
I've checked in changes to require_js(), into HEAD. It basically behaves like the require_once() PHP function. You can give the (www) path of the JavaScript library you want loaded, or you can pass an array of paths. You an also give it the short names of some of the common library files (mostly YUI stuff). If a file is not found, we error() out.
Used without arguments, require_js() will return the html needed to load the JS files. print_header() in weblib now calls require_js().
Used without arguments, require_js() will return the html needed to load the JS files. print_header() in weblib now calls require_js().
Regarding the check for ajaxenabled() in require_js().
If we don't respect the $CFG->enableajax and $USER->ajax settings, we'll end up with two issues:
1) Inconsistency. For example, an admin turns off AJAX - some parts of Moodle respects this, while other parts don't.
2) Moodle should ideally work even with JavaScript turned off. We should promote the use of AJAX in a transparent way. If JavaScript is on, then the UI is changed by JS to enable the AJAX magic to happen. Otherwise, the UI should still work untouched.
If we don't respect the $CFG->enableajax and $USER->ajax settings, we'll end up with two issues:
1) Inconsistency. For example, an admin turns off AJAX - some parts of Moodle respects this, while other parts don't.
2) Moodle should ideally work even with JavaScript turned off. We should promote the use of AJAX in a transparent way. If JavaScript is on, then the UI is changed by JS to enable the AJAX magic to happen. Otherwise, the UI should still work untouched.