General developer forum

It's all changing quite fast indeed. I have just gotten used to writing everything in YUI modules and I am real happy with the shift to AMD.

I would not mind rewriting YUI code to AMD for new versions, it needs to happen at some point anyway. For 3.0 it would be great to have a cleaner Moodle, AMD only, more renderers, new formslib, cleanups of old parts. For me that would make developing plugins so much nicer and I would prefer that over any new Moodle features. In fact I think cutting down the number of features would be very nice.

So what would the policy on Moodle core code be for this? Will some of Moodle core YUI code be rewritten, will we have a AMD Atto? That would be awesome!

Hi Dan,

Difficult question.

Ok, how about a compromise.  As its clear that writing new YUI code is not a good thing at that needs to be discouraged as soon as possible, but at the same time you want to facilitate what is almost complete being accepted into M3.0.  So, instead of waiting until M3.1, why not apply the same 'code freeze' methodology?  Such that a date is set early on for M3.0 that no more YUI code will be accepted after that date, that developers must register their intent by that date with justification of the code they have almost completed for it to be accepted.  Then it must be completed by the standard 'code freeze' date or they will have to re-write in the new AMD way.

It may also help if effort (if not already) is undertaken in M3.0 to refactor the existing YUI code to AMD such that examples are already in place to assist developers who may have written a little new YUI but could switch at an early stage.

Theme developers already have examples in core and I've been working with Bas and others on the BS3 AMD version, so lots of good stuff going on there.  Course formats are another matter and I could benefit from some examples there and with the 'popular' set user preference functionality.

Cheers,

Gareth

IMO new YUI code should be discouraged from 3.0 - but not prevented.

The main reason is that we have not yet converted our core Moodle Js to AMD/JQuery - and there are a bunch of support functions that we need to put in place to make it easier (possible) to create awesome new interfaces. We also have some YUI Apis for which there is no equivalent (E.g. Atto plugins).

Some critical things we need to have available as an AMD module:
* Dialogues (not simple - don't look at JQuery - UI etc - it must be ARIA)
* Drag and drop (actually not that hard to do in HTML5 - but making it accessible is - ie keyboard nav and UI for choosing a drop target)
* Menus

Also some new things have not yet had a long life - e.g. Atto, edit pdf.
* We need to give a clear roadmap of these things before we convert them - it would be painful to rewrite Atto now and make people redo their plugins again - IMO this should be started in about 12 months.

As for progress for 3.0 - we are working on learning plans - and to do this we are adding support for some of this core functionality as AMD modules (All of the learning plans JS is AMD). We will get learning plans finished first as a standalone plugin (which means all new modules will be contained within the plugin), and then convert it to a "core ready" branch for integration to 3.0 (which is when we will convert these generic AMD modules to sit in "core"). Because of this plan, the new AMD modules wont land in the master branch until later in the cycle, which will not give devs as much time to use them.

The generic AMD modules included in the learning plans branch so far are:
* dragdrop
* dialogues (this is a thin wrapper to the YUI implementation)
* menus
* an ariatree control

The tracker issue for learning plans is https://tracker.moodle.org/browse/MDL-49458.