Tapestry

Possibly: https://github.com/lucasefe/themes_for_rails

Since this code is not on a separate branch, I reviewed:

c0a650c06acc7e3734603b9d25a89d0feddedc3a

Comments:

• This should be documented in a new 'Customization' section on the wiki, cf. my comments in #2501

• I would prefer to have the site_specific directory to be outside of Rails.root, in a directory that is configurable via the config.yml file. It should mimic the entire Rails.root structure, though it's totally fine to only support overloading of files under app/views like you are doing in this patch. This is the way RT does it, and it makes it super easy to upgrade the codebase - there are no site specific modifications in the tree that comes from upstream.

Otherwise, good to merge!

I've added a new Customization section to the wiki. I agree that it would be a good idea to reorganize a bit and I'll do that as we go.

As for the directory outside of Rails.root, in principal we could do it (I tried locally and it certainly works without complaint), but the trouble is with configuring this via the config.yml files. In order to do this, we have to change when and the way the config.yml files are read. This should be done in another feature as this is certain a mini-project unto itself: I would also make the yml files interpreted for erb and rename them accordingly. And then with that we would be able to keep string literals completely DRY. We would consider switching to using ENV as well. Therefore pretty much everything using APP_CONFIG would be influenced. At the same time, I could eliminate the old Tapestry system of evaluating these config keys as CAPITALIZED CONSTANTS.

Until then I've compromised and pointed this configuration at "#{Rails.root}/site_specific/app/views". The "#{Rails.root}/site_specific" part can be overridden with an environment variable called TAPESTRY_OVERRIDE_PATH. With this latter addition we can effectively accomplish exactly what you're requesting, even without refactoring how and when the configs are read.

(I've created what I hope is a proper branch for this according to my new understanding of the development process at Curoverse. It is called "2518-can-override-views".)