Re-organize the templates and static directories to support easy theming about bartholomew HOT 4 CLOSED

Hello, I'd like to work on this. I was thinking about two possible approaches.

Approach 1 - Create a templates/themes/ allowing you to access components from possibly multiple themes by including partials like {{> themes/<name of theme>/<theme component> }}. Alternatively themes/ can be a separate directory from where all the templates are registered and can be included using `{{> / }}

Approach 2 - Creating separate themes/ and using the configuration in site.toml to pick the themes in theme/<name of theme>/ as described originally with the user templates having higher precedence than the theme-defined templates allowing for the user to override the theme where required.

Approach 1 would allow for more flexibility as it can allow for multiple themes to be used at the same time while approach 2 might lead to a smaller solution.

from bartholomew.

Hi, @karthik2804!
Working on this would be great!

I'm familiar with Hugo as a static site generator, and approach 2 is what I would expect.
That being said, exploring the first approach and seeing whether it leads to a simpler solution is something I'd like to explore as well.
Thanks!

from bartholomew.

Hello @radu-matei!
I have implemented both approaches as described in the earlier comment on separate branches.

Approach 1 which is component-based can be found at Component-based approach while approach 2 which is an individual Theme-based approach can be found at Theme-based approach .

The pros of approach 1 are

• It allows for more flexibility.
• Allows borrowing components from more than one theme
• No namespace clashes of the components as the partials are included as {{> / }} while templates are chosen as {{> }}

The possible cons of approach 1 are

• It may slow down the response as it needs to index more templates as it reads all the themes available.

an example of usage of approach 1: The navbar is provided by the template of theme-2 ( {{> theme-2/navbar }} ) while the sidebar is provided by the template in theme-1 ( {{> theme-1/sidebar }} ).

The pros of approach 2 are

• It is simpler in that a single theme is chosen.

The cons of approach 2 are

• It does not have the flexibility available in approach 1 to use components from multiple themes.

an example of usage of approach 2 is that the selected theme is defined using the site.toml configuration. If there is no theme defined only the user-defined tempaltes are loaded. When a theme is mentioned on site.toml, the templates of the theme are loaded along with the user-defined templates.

A thing to note is that there will be a namespace collision of the templates in approach 2, where the user-defined templates take higher precedence than the templates provided in the themes, This allows the user to override the theme wherever required.

from bartholomew.

closed by #87

from bartholomew.