breaking up the core with chris steele

[oliverfoster]

Chris Steele:

Here are my thoughts after looking at the prototype4 branch of adapt_framework with regard to how we can refactor and rationalise adapt-contrib-core:

ComponentView should be a plugin and a dependency of the other component plugins. QuestionView should be a plugin and a dependency of the other question component plugins. This plugin would include ButtonsView. This would mean AdaptView/AdaptModel would need to be a plugin and a dependency of the above.

For convenience the above three could be grouped into a simple aggregating plugin called adapt-contrib-foundationMVC or something.

Menus are plugins and so pages should be too. This would decouple views from the router completely. The standard page plugin could include article and block views and their associated models. N.B. I would say that the abstract MenuView should be ditched and its small amount of relevant functionality added directly to the implementations. Its use by both the main menu view and menu item views is a bit flaky in the way they handle the ready status.

Accessibility should probably become a plugin (and include its jQuery lib rather than in adapt-contrib-boot). This would include PopupManager.

Router should probably be a plugin. StartController could easily become a plugin. The router and start controller plugins could be grouped into a simple aggregating plugin called adapt-contrib-foundationRouting or something.

The above changes would strip down core into just the basic elements that handle setting up the standard Adapt data structures, support for responsiveness, logging, the data persistence stub, and the templating helpers.

We could take it one step further and say that the mpabc data structure is something that is quite rigid and should be factored out into a plugin. What's left in core is then stuff that pretty much anything we or anyone else would want as boilerplate.

This could become adapt-contrib-foundation and you could then use it in scenarios that don't use the normal mpabc approach such as interactive video/gamified pieces etc.

So adapt-contrib-core would just become an aggregating plugin that includes these three foundation plugins.

The more we break things up the easier it is to write tests for.

This is just a first pass with a brief look at feasibility so I’m keen to get your thoughts on the above.

Cheers,

Chris

[oliverfoster]

Hi Chris,

Looks good so far. Need some thoughts on why these things should be delineated as such what benefits deciding it up into so many pieces would have etc.

I'm struggling to map your ideas into a hierarchy. Is the below about right?

Core (group)
  < FoundationMVC (group)
    < AdaptModelView
      < ComponentModelView
      < QuestionModelView
  < FoundationAccessibility (popupManager, a11y etc)
  < FoundationRouting (group)
    < Router
    < StartController
  < Foundation (offlineStorage, helpers, etc)

Leaving aside the separeted mpabc data structure idea for the minute, where would the Page Article and Block model and views live?

Kind Regards,

Ollie.