JavaScript namespacing proposal

From MoodleDocs
Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.

The idea of JavaScript namespacing was raised during the developers meeting that occured on Tuesday 29th September 2009 and I think its a fantastic idea, so I wrote this wee proposal and plan to hopefully win people over and get this is in for Moodle 2.0.

Note: This proposal assumes that the patch proposed for MDL-16699 that splits javascript-static into two files and moves JavaScript that is only being used in a single place within Moodle to a file that can be included by the code that uses it.


The concept is to apply a namespacing scheme to the JavaScript that is used by Moodle core code. By namespacing the JavaScript we can better define the structure of the JavaScript code as well as hopefully make it both more easily accessible and with any luck make it easier to develop JavaScript that is potentially reusable.

The root namespace

After discussing this with the development team it was decided that the core namespace will be M. The original concept was to go with MOODLE however we decided that there was no need to go with the so many characters where one would do, and this fit in with the changes YUI was making in the release of version 3.0 changing their root namespace from YAHOO to Y.

Core namespaces

The following are namspaces that will be created in order to support the initial conversion to a namespaced JavaScript core.

JavaScript that creates controls, or structures used throughout Moodle.
JavaScript for interacting with the DOM.
JavaScript for interacting with forms.
Miscellaneous JavaScript functions.
JavaScript that is utilised in direct respect to the user.

Creating new namespaces

Ideally additional code (or as it is being converted) should be namespaced directly after M with a name fitting to the PHP code. For modules this would be the module name e.g. .

Time estimate

I think it would take a day to namespace the JavaScript files, and then a further day or two to convert the function calls and test. It is a reasonably simple procedure and with all of the JavaScript clean up that has gone into head already there should be realivily few edge cases left.


The implementation of the core namespace and supporting functions to further namespace is reasonably simple, however it would need to be the very first bit of Moodle JavaScript to be executed. This simply means it would be defined and set up within javascript-priority.js which is the first file to be included in the HTML head.

Conversion of JavaScript files


Declaration Namespaced declaration Declaration type
block_hider M.util.block_hider object
checkall M.form.check_all function
checknone M.form.check_none function
collapsible_region M.dom.collapsible_region object
deselect_all_in M.form.deselect_all_in function
findParentNode M.dom.find_parent function
fix_column_width M.util.fix_column_width function
fix_column_widths M.util.fix_column_widths function
focuscontrol M.form.set_focus function
frame_breakout M.frame.add_breakout_target function
init_help_icons M.util.init_help_icons function
openpopup M.util.window.popup function
select_all_in M.form.select_all_in function
submit_form_by_id M.form.submit_form_by_id function
emoticons_help M.util.emoticons_help object
old_onload_focus To be depreacted as part of MDL-19740


Declaration Namespaced declaration Declaration type
build_querystring M.util.build_query_string function
cancel_scroll_to_end M.util.scroll.cancel_autoscroll function
close_window M.util.window.close function
close_window_reload M.util.window.reload_close function
confirm_dialog M.control.confirmdialog object
create_UFO_object M.control.ufo.create function
destroy_item M.dom.element.remove function
getElementsByClassName Should really be deprecated in favour of YUI equivilant
hide_item M.dom.element.hide function
json_decode M.util.json.decode function
json_encode M.util.json.encode function
repeatedly_scroll_t M.util.scroll.autoscroll function
scroll_to_end M.util.scroll.bottom function function
set_user_preference M.user.set_preference function
show_item function
stripHTML M.util.strip_html function
unmaskPassword M.form.unmask_password function
update_progress_bar M.control.progressbar.update function


Declaration Namespaced declaration Declaration type
create_shadow M.control.shadow.create function
move_all_sidetabs_t... M.control.dock.undock_all function
navigation_tab_panel M.control.dock object
navigation_tree M.control.tree object
navigation_tree_branch M.control.tree.branch object
remove_shadow M.control.shadow.remove function
setup_new_navtree M.control.tree.init function


Declaration Namespaced declaration Declaration type
deprecate M.util.deprecate function
deprecated_addonload M.util.deprecated.addonload function
deprecated_confirm_if M.util.deprecated.confirm_if function
submitFormById M.util.deprecated.submitFormById function


Declaration Namespaced declaration Declaration type
date_selector_calendar M.form.mforms.date_selector.calendar object
elementShowAdvanced function
get_form_element_value M.form.mforms.get_element_value function
init_date_selectors M.form.mforms.date_selector.init function
lockoptionsall M.form.mforms.lockoptionsall function
lockoptionsallsetup M.form.mforms.lockoptionsallsetup function
set_form_element_disabled M.form.mforms.disable_element funciton
showAdvancedInit M.form.mforms.show_advanced.init function
showAdvancedOnClick M.form.mforms.show_advanced.handle_click function

Resulting namespaced structure

  • M
    • control
      • confirmdialog
      • dock
        • undock_all
      • tree
        • branch
      • progressbar
        • update
      • shadow
        • create
        • remove
      • ufo
        • create
    • dom
      • element
        • hide
        • remove
        • show
      • collapsible_region
      • find_parent
    • form
      • mforms
        • date_selector
          • calendar
          • init
        • show_advanced
          • init
          • handle_click
          • show
        • get_element_value
        • lockoptionsall
        • lockoptionsallsetup
        • disable_element
      • check_all
      • check_none
      • deselect_all_in
      • set_focus
      • select_all_in
      • submit_form_by_id
      • unmask_password
    • util
      • deprecated
        • addonload
        • confirm_if
        • submitFormById
      • json
        • decode
        • encode
      • scroll
        • autoscroll
        • bottom
        • top
      • window
        • close
        • popup
        • reload_close
      • block_hider
      • fix_column_width
      • fix_column_widths
      • init_help_icons
      • emoticons_help
      • build_query_string
      • strip_html
      • deprecate
    • user
      • set_preference

Why bother?

Because ....

  1. It greatly reduces the chances of developers accidentally creating clashing methods, or variables. Not just with core code but more importantly conflicts that may arise between 3rd party extensions.
  2. Hopefully make the JavaScript code more usable and obvious by providing better organisation and structure. This will in turn hopefully reduce the number of identical functions that arise.
  3. It's the sort of thing that can only be done when revision of code is necessary and there's no time like a major release for that.
  4. It looks better, more organised.


To answer a few quick questions about the process:

How long would it take to namespace the JavaScript
It wouldn't take very long at all to go through and apply a namespacing scheme to the JavaScript once the structure has been decided upon. Once the JavaScript has been namespaced it would be a simple case of iterating through the files that make up Moodle and converting references to the original JavaScript functions to their namespaced equivalents.
Does all JavaScript have to be namespaced
No not at all. Initially only the core JavaScript files would be converted. After this it would be up to developers to namespace their code should they choose to.... it would be the perfect opportunity to revise that legacy JavaScript ;)
What about code that uses the old function calls?
All of the core uses should be converted as part of the task of namespacing however we certainly need to support the old function calls. We will create mapping functions that simply take a call to a non-namespaced function and pass it to its namespaced equivalent.
Will any of the JavaScript change?
No. A couple of new internal functions will be introduced to support namespacing however the actual JavaScript functions being namespaced will not change. You will still be able to call them as you did before, you will just need to use the namespaced reference.