I have just started with YUI and it is a nice feature to see a Log Console but I want to feel a little more control. How can I turn it on/off?
Thank you.
At the beginning of init method in javascript code is the piece that displays console. Remove that part.
Hi Kevin,
Could you possibly provide a little more detail? Which log messages do you mean, and what version of Moodle are you developing for?
If you're referring to the log output from your own code, you have a couple of options.
Rather than using console.log, you can use Y.log. If you're writing YUI modules (and I'd really advise that you do), and you then run those through Shifter, then three versions of the file are built:
- -min.js - minified version of the code with all logging removed. These are served in most cases;
- .js - raw version of the code with all logging removed. We don't actually use these most of the time; and
- -debug.js - a full copy of the your code with logging present. We only serve these when the debug level is set to DEBUG_DEVELOPER in Moodle.
Simply changing your debug level will cause different versions of the files to be used. We never actually use the -debug.js versions of the YUI code (we keep them in place for those times when we do need to try and track down an upstream issue, at which point we can fettle them in to being used).
If you mean the debug messages for other Moodle-specific YUI modules, from Moodle 2.6, it's possible to filter those out. See the documentation for yuiloginclude and yuilogexclude in config-dist.php. You can also filter on log level.
When writing your own YUI modules, I'd advise leaving an appropriate level of logging in place, and using all three fields of Y.log - see http://yuilibrary.com/yui/docs/api/classes/YUI.html#method_log for the full documentation.
For the src field, we recommend using the module name - for example, moodle-core-tooltip.
You can, of course, also filter in your browser in a number of ways.
Best wishes,
Andrew
Hi Andrew,
I do understand the benefit of using the shifter but this is just crazy. Instead of writing one js file now you have to write 3 in specific dir structure and make sure to build them... Nobody thinks about developers here? Process should be simplified but all we see is that complexity is steadily growing... Are we approaching the degree of MFC where one could not fart without running some super-duper wizard to generate stuff?
Nobody thinks about developers here?
They do. See the original discussion introducing it on this forum and the issue integrating it MDL-37127.
(FWIW I share your concerns, the barrier keeps getting higher and I am not sure our developer documentation is keeping pace either).
Hi Darko,
I'm sorry you feel that way, but as Dan points out I did raise this in both the forums, and a tracker issue before submitting it for integration. At the time, I was a volunteer from the community and not working for Moodle HQ. I also raised it at both the 2013 UK Moot developer day, the developer Hackfest last year, and when I spoke at two online developer meetings.
Increased complexity was a major factor when working on migration to Shifter. Although it does raise the bar for developers slightly, it's fairly common practice in many projects to have to pass code through various tools to ensure that it is well formatted, minified, etc. In the case of JavaScript, I feel that this is especially important as failing to lint code (which we do as part of the Shifter run) can lead to breakages on the entire page which could easily have been avoided.
The minification is also a massive performance win for our users, particularly those on slower connections or using mobile devices. Yes, it is possible to minify on the fly, but this is often unreliable and does not lead to the same integrity.
If anything, I would argue that using Shifter actually helps developers a majority of the time. Its use means that you are able to leave various bits of debugging information in place when you are developing, it picks up many of those stupid mistakes and typos we all make from time-to-time, it paves the way for better documentation (try running yuidoc from the root directory - this is a work-in-progress), and it also paves the way for unit testing (again, this is a work-in-progress). Using Shifter also remove the requirement to wrap YUI modules in the YUI.add wrapper which many found confusing.
Ultimately these changes affects many, many more end users than developers. Not only do we gain from reduced over-the-wire transfer sizes, but we also gain by having our metadata in a single and cheaply-parsed location for each module. This means that all of your dependencies are loaded in fewer requests for each page because dependency calculation happens before the module is loaded.
Prior to Moodle 2.5, to load a YUI module required fetching that module, parsing it and reading its dependencies, and then loading those dependencies. If that list included further moodle modules, that may have to be repeated again. In the case of the moodle-course-modchooser, this depends on moodle-corechooserdialogue, which in turn depends on moodle-core-notification, which ultimately depends on Y.Panel and friends. Before we introduced this metadata, we had to make four round-trips to get the activity chooser. We did reduce this by declaring many of the dependencies, and their dependencies up front, but this is not a good route to follow. Now we define these dependencies in one separate file (meta/modname.json), which is parsed once (and then cached when not in developer mode). It's then served as part of the page request and the YUI loader resolves all of the dependencies once.
All of these feature obviously come at a small cost, but I would argue that it is minor:
- a slightly different directory structure;
- moving metadata and build data into separate files;
- running Shifter after making changes.
The benefits, in my opinion, significantly outweigh the costs:
- reduced OTW size through minification;
- reduced number of requests from browsers;
- linting as standard;
- documentation is a realistic possibility;
- testing is a realistic possibility;
- the ability to support submodules (see moodle-core-dock-loader for an excellent example of why this is fantastic); and
- automatic removal of developer comments.
I hope that this helps explain some of the rationale further for the move to Shifter. These may not seem important at first glance, but they can drastically improve performance for many, many users.
Best wishes,
Andrew
When does the core plan to obsolete other means of writing js code in moodle?
Hi Darko,
There is no specific timetable, and since most of these changes will not be adding new functionality or fixing major bugs they tend to get pushed towards the back of the pile.
My intention to-date has been:
- to convert all non-shifted modules in core to be shifted (relatively easy);
- upgrade all YUI2 code to YUI3 shifted modules (harder, but increasingly urgent as YUI2 has been deprecated for several years now);
- assess all remaining JS and work out moving that to Shifted JS.
In amongst there is a plan to deprecate javascript-static.js and move it's relevant content to shifted JS.
I don't know how long this will take, and I've only recently started working at Moodle HQ. Until then, I was doing this work as I had time available. Any assistance with this is much appreciated.
Cheers,
Andrew