This is a tentative idea to replace one multi-purpose conditional-ridden theme with two simpler themes, one for open project and one for open project hub.
This should be a good idea as long as it’s possible to have:
Themes reuse shared logic through helpers gem
Project sites inherit shared aspects of hub styling from parent hub (e.g. by pulling SCSS variables file)
Reduce duplication of template code to let’s say fewer than 100 LoC, since this appears to be the part least obvious in terms of reuse across themes
Two distinct theme gems is the most obvious way, but this might add a bit of headache in terms of gem versioning. There may be an alternative way to have this sort of separation without creating a separate theme gem.
Thinking a bit ahead
As an open site suite maintainer (as opposed to theme developer), I’d want to just give AWS credentials, point to repositories containing project & hub data along with styling variables, and have the whole open site suite provisioned without worrying about gems & their versions. I might want to be able to pin theme version in case my project data is in old format, but that’s about it. I don’t want to be ensuring all sites use compatible theme & helper gem versions, etc.
With that in mind it seems like a natural way to handle the whole site provisioning in most developer-friendly way could eventually be through a topmost developer-friendly layer in the form of, e.g., a Terraform project or a Docker image/Dockerfile.
This would make data management more straightforward (repos would not contain Gemfiles, lockfiles, etc.) and it would enable the Open Project project developers to focus on optimal gem structure without worrying about complicating version management for Open Project project consumers. It would shift some of the responsibility of version management and deployment orchestration from Open Project consumers to its developers.
The challenge may be picking the best way to bundle the orchestration, since TF may not be everyone’s choice, although I don’t see why not.
This is a tentative idea to replace one multi-purpose conditional-ridden theme with two simpler themes, one for open project and one for open project hub.
This should be a good idea as long as it’s possible to have:
Two distinct theme gems is the most obvious way, but this might add a bit of headache in terms of gem versioning. There may be an alternative way to have this sort of separation without creating a separate theme gem.
Thinking a bit ahead
As an open site suite maintainer (as opposed to theme developer), I’d want to just give AWS credentials, point to repositories containing project & hub data along with styling variables, and have the whole open site suite provisioned without worrying about gems & their versions. I might want to be able to pin theme version in case my project data is in old format, but that’s about it. I don’t want to be ensuring all sites use compatible theme & helper gem versions, etc.
With that in mind it seems like a natural way to handle the whole site provisioning in most developer-friendly way could eventually be through a topmost developer-friendly layer in the form of, e.g., a Terraform project or a Docker image/Dockerfile.
This would make data management more straightforward (repos would not contain Gemfiles, lockfiles, etc.) and it would enable the Open Project project developers to focus on optimal gem structure without worrying about complicating version management for Open Project project consumers. It would shift some of the responsibility of version management and deployment orchestration from Open Project consumers to its developers.
The challenge may be picking the best way to bundle the orchestration, since TF may not be everyone’s choice, although I don’t see why not.
This section is somewhat related to #9.