Adapt Learning Community: Bespoke folder & overrides

I had an interesting chat with the guys from Sponge today over whether the bespoke folder was working and you could use it. The answer was 'no' and that was simply because we haven't adjusted the Gruntfile to respond to it as we haven't needed any bespoke work done to the core.

This was then followed by a conversation as to whether we actually need a bespoke folder?

At Kineo we use the bespoke folder for customisations - changes to a theme, small bespoke components or plugins and even core overrides.

With the open source version of Adapt we decided upon going with a plugin architecture that enables plugins to tap into events fired off by the core, components or extensions.

One place I can see the bespoke folder being used is when a core event is not available in that current version of Adapt. So a file could overwrite a core model or view giving that event as an available hook.

However this could be built as a plugin. Talking to Sponge and going over a few other situations with them, we questioned whether a bespoke folder is the right thing to do.

The bespoke folder offers a way to overwrite files. Is this something we want or should we be giving these code changes their own issues list and commit history by having them act as extensions.

Maybe we want to change a little template in the graphic component (move the graphic above the text). This could be achieved by either creating a new component. This means it gets it's own git repo and people can track issues, helps the open source project by pushing these out as plugins so other people can use them or if you're not technically minded you could make an issue on the existing plugin (would be a json setting attribute).

Could the bespoke folder become a dumping ground? Could we lose valuable core changes by putting it in a bespoke folder and not raising this as an issue?

Does the bespoke folder become a place where we put our quick fixes? Working on projects can have a situation where you pressure code and quick fixes are the only way. I remember taking something away from the initial meeting in Derry where Ryan mentioned something along the lines of - "I don't see us using the bespoke folder as we would develop them in a sufficiently generic way that we could configure them in content or adjust them using themes. If a component requires so significant a modification that we'd use the bespoke folder then we'd create a custom component to perform that function."

The bespoke folder can also have an affect on the page load and how much we download. If we have core files and then some other files overwriting these do we download all of these? Or do we check over the bespoke folder and swap out the files?

A little note about themes too. If you change a theme, does that become a new theme?

Would be great to here what people think. Especially on how they would see the bespoke folder being used.

Thanks,

Daryl

Some of the real power and potential of Adapt comes from the plugin system and allowing the community to share and contribute.
I personally feel that providing a built-in mechanism to hack a course into doing something undermines this and makes it less clear about the correct way produce content with Adapt.
If I can use the bespoke folder to extend functionality and styling, when is it ok to do this and when should I create a plugin?

Daryl mentioned about time pressure to deliver quick fixes, and while I totally understand that this is a factor, I think that the correct solution is to provide a quick and painless way to create themes, extensions and components. People will naturally incline toward the solution that presents the least resistance, so we should focus our time in making the best solution also the easiest solution.

Show parent | Reply

To add my thoughts to this:

The purpose of the bespoke folder is to offer developers flexibility to override core files without actually having to customise and fork them. This is akin to Moodle's local overrides architecture.

I agree that it should be used in exceptional circumstances only and that we should focus on making working with the framework properly (e.g. via plugins) so straight forward that the use of the bespoke folder should be minimal. However, not offering this flexibility feels incorrect to me, especially as we have used it very regularly at Kineo in order to push the boundaries and make something better, more engaging etc. I'd say that plenty of new ideas have arisen out of our use of bespoke elements.

Underneath all of this is the principle that we cannot predict 100% of how the framework will be used and that there may well be circumstances where it is not viable for commercial content producers (e.g. for commercial reasons) to develop certain functionality in the proper Adapt way. My (strong) view is that we should accommodate this, be open to it but also commit to do things properly, at least amongst the core group.

So with that in mind, I think we should we keep the bespoke folder and make it work as intended. Further to this, we should provide as much help as possible (resources, webinars, best practice examples) to developers using the framework. We should also also look out for useful functionality publicly developed as bespoke and encourage the developer in question to rewrite this for inclusion into core / contrib.

Sven

Show parent | Reply

+1 for Sven's comment, very well put.

Show parent | Reply

Hey Sven,

Some good points here. I'd just like to offer my experience of dealing with the bespoke folder and I'd like to offer an alternative to it.

Firstly the bespoke folder can become this 'dumping' ground where anything goes. To track down the code that does something to core code is a nightmare. Not only that but being able to reuse this code is harder, as it's usually dispersed throughout the bespoke folder.

Let's say that I had an override of core code and it's placed in a folder called 'js' in the bespoke folder yet it relied on a template in a folder called 'templates' also in the bespoke folder and this then relied on another file somewhere. Being able to track all these files becomes difficult and can lead to bugs/issues and it's why our current Adapt has a long list of script tags in the HTML page. This slows down the initial load and there's a lot of duplicate code meaning the download size is larger.

In terms of Moodle, the people I have spoken to about Moodle and the way that the overrides folder works - they've all mentioned how unpredictable it can be.

Using the bespoke folder to push new boundaries has always been a massive clean up job afterwards because we don't know what to do with the code. Instead we have this great plugin architecture now that allows plugins to tap into Adapt and enhance it.

However I do feel there is a need to create something for developers that allows us to do bespoke overrides. One solution is to make a bespoke plugin - this generic plugin allows you to add js, less and templates. The benefits of something like this means you get all the functionality of the bespoke folder yet it is kept inline with the plugin system, which means it's easier to transfer this over to a plugin but also it's better for us to track what types of overrides people are wanting and implement them back into core.

When I started working on Adapt Open Source and moving the code over to this plugin architecture, one thing I realised that was not going to happen first time and that was to get all the event hooks we need as the possibilities are endless. By seeing what people are doing with this bespoke plugin we're able to track these and implement the most used ones.

Also another bonus to having it this way is Adapt doesn't need anymore work to find the files - plugins already load in order. This plugin could also have a toggle feature where you can toggle a list of overrides that are commonly used in your projects. This means you have one place to look for your overrides and it also benefits the community by having this open.

I know I've probably rambled a bit here now but I want to make sure that the bespoke folder is something we need/want and if there are any other suggestions out there.

Just a small note on theming customisations - this should always be done in the theme folder as they can become reusable and the theme folder was built in a way that it has the power of manipulating the layout templates.

Thanks,

Daryl

Show parent | Reply

The way I see it every non-Core Bundle plugin *is* a bespoke plugin.

There is no need to have a special case.

Remember plugins don't have to be registered!

I can just drop a folder full of less into the src/extensions folder and to start hacking the theme.

What is not cool is overwriting Core functions, this is always going to be a problem because it is an inherently bad thing to do.

Show parent | Reply