Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Dublin hackfest May 2015

From MoodleDocs
hackfestieuk15.jpg

Developer meetings > Dublin hackfest May 2015

When Thursday 14 May 2015
Where Dublin City University as a part of the MoodleMootIEUK2015
Hashtag #mootieuk15
Discussions Moodle Hackfest Dublin 2015 course at dev.moodle.org

Schedule

Time slot Room HG19 Room HG18
09:30 - 10:00 Welcome, introductions, hackfest agenda -
10:00 - 11:00 Bootstrap 3 Introduction to Behat tests in Moodle
11:30 - 13:00 Bootstrap 3
Forms simplification
User interfaces
Introduction to the Moodle development
Contributing to Moodle
14:00 - 15:30 Student dashboard
Gradebook computation issue(s)
Improving the Moodle dev docs
LTI integration improvements
16:00 - 17:30 DB performance for fetching data across courses
New core API to store aggregated course level performance
HTTP2 and impacts on Moodle development
-

Bootstrap 3

Topic suggested at http://dev.moodle.org/mod/forum/discuss.php?d=2334 as a renewal of MDL-40177 to integrate Bootstrap 3.x (BS3) with Moodle.

Outputs

  • New epic issue created on tracker to take the tasks discussed - MDL-50241

Action plan

  1. Rename bootstrap -> bootstrap3base (Bas)
  2. Cleanup and strip bootstrap3base code (David / Gareth / Guy / Bas)
  3. Comparison with current bootstrapbase (David / Bas)
  4. Do Behat testing (David)
  5. Create Bootstrap3base child themes (Richard / Mary / Gareth / Bas)
  6. RTL checks for bootstrap3base (Nadav)
  7. Find a HQ person to help coordinate it and back it up (?)
  8. Announce on Forums / Tracker and ask for feedback / testers (everybody)
  9. Create a Moodle docs page on Bootstrap3 usage and migration docs (Stuart / David)

Notes

  • jQuery is now the Moodle JS framework and BS3 is using it - no more need to deal with the YUI + Bootstrap compatibility.
  • Renderers should be responsible for integrating any framework.
  • Backward compatibility is important to keep existing themes running. Good experience with BC between the BS3 and BS2 reported by David Scotson (grid layout to be fixed, the rest mostly works). You can use mixins to give you 100% compatibility between BS2 markup + classes and BS3. So even if you have BS2 html content it would be super easy to make it work with BS3
  • Nadav Kavalerchik reports good experiences with RTL + BS3
  • Q: What are HQ plans with YUI? A: It will stay there for a long time yet, new development should all be AMD + jQuery
  • All the technology used in the bootstrap3 development (e.g. grunt, AMD etc) are in line with those recommended / required for Moodle development.
  • There is already an existing bootstrap3 Moodle theme that is ready to be integrated.
  • BS3 - mobile first philosophy. Starting with a collapsed grid and expanding it out to bigger sizes.
  • Moodle core jquery has to match the bootstrap 3 min jquery version
  • Legacy moodle html causes problems for developing Bootstrap themes. So you basically have to use less to get round these problems but it is NOT a good solution. The real solution would be to make sure that all HTML generated in Moodle uses renderers + an element library ensuring consistent elements would help.
  • With all HTML handled by renderers it is possible to make your theme output bootstrap compliant elements instead of hacking around with less.
  • You should be able to just take bootstrap CSS (not less) and dump it into Moodle and then have everything in Moodle use the correct html element structures and classes.
  • Standardising on Bootstrap 3 - should Moodle do that? Argument for: If people slap html into Moodle using the bootstrap classes then it just works.
  • If we take a draconian approach with BS3 and force it as the standard for Moodle then it has some other advantages - for example, content creators (teachers, students, etc) could uses BS elements in their content. I.e. not using tables for columns and instead using grids. This is important because it means that not only is Moodle responsive but the content is too!
  • Usage of YUI elements will need attention - e.g. there are YUI tab elements and standard moodle tab elements. Easy to convert the moodle elements to BS but not so straightforward with YUI.
  • There is a real issue with multiple flavours of dialogs in Moodle a the moment. Standardising on BS markup makes sense.
  • Forms needs updating. Unfortunately the heavy customisation of the pear library will make it difficult to upgrade.
  • The importance of an element library was stressed - helps developers know how to design and implement their UI.
  • Consistency is king - better user experience
  • The element library should NOT be encouraging developers to use markup - it should be encouraging them to use the renderers.
  • It needs to also be abstracted for content creators - e.g. ATTO needs to make it easy for content creators to dump in BS elements without having to worry about markup.
  • An element library does NOT need to be complicated.
  • Behat tests will need to be adapted when markup in core moodle is changed to support BS3
  • Bootswatches demonstrated - using variables.less in swatches is a great way to extend from base bootstrap. Just need to change a few variables to quickly make a big visual change.
  • For theme designers, using a grunt task to decache moodle when less files change

Credits

Bas Brands, David Scotson, Richard Oelmann, Guy Thomas, Stuart Lamour and all others actively participating the session.

Introduction to Behat tests in Moodle

  • Demo / training / tutorial on using Behat with Moodle
  • Discussion

Gradebook computation issue(s)

Improving the Moodle dev docs

LTI

  • Implementation of custom activity modules using the LTI by Tim Williams
  • Suggestion to convert common functionality currently provided by mod_lti to a standalone library / class usable by all plugins (without the need to duplicate the code)
  • Discussion

DB performance for fetching data across courses

  • Demonstrated on an example of a block by Martin Christensen
  • Discussion

New core API to store aggregated course level performance

  • Idea presented by Martin Dougiamas
  • Centralized API to store and quickly get aggregated info about student's performance in the course
  • Simple numeric value to be stored and interpreted by plugins

HTTP 2 and Moodle

Form Simplification working group

  • The suggestions of the working group were captured into a doc and most have been turned into issues under the epic MDL-50230.
  • At the Hackfest, there was not much to discuss but developers were invited to work on issues raised at the working group, with the mandate that this promises. The following developers were enticed and more a welcome.