separate theme and content

[andrewufrank]

I think it would advanced understanding and prevent errors when the data describing the theme (i.e. the appearances) and the content data (the files with input in markdown or other) to deliver.

The change is simply to create a folder theme to include a folder static (with the same content as before, except that a second folder staticData is to be included in data to hold content) and a folder templates (content as before), the files menu.yml, settings.yml and - if needed - stuff.sqlite. The project.yml folder should go into theme, but I have not yet tried this.

The changes in the code are two small ones (as far as I can see): there are two places where templates is mentioned and it is to be changed to theme/templates. The other changes are in menu.yml and project.yml specif per project.

Do you think this helps clarity? Are there other drawback, i did not see? I can send you a pull request for the change and the changes in the documentation - if you like it.

My ultimate motive is to be able to use Pelican themes with sprinkle, which I will study later. There are a number of nice looking themes there and it would give usability a great boost if these could be used with limited adaption.

[tdammers]

OK, so sprinkles will not have a built-in theming mechanism; the philosophy is that if you want such things, you will have to build them yourself, on top of what sprinkles has to offer.

That said, the fact that templates/ is hard-coded is something I want to change at some point.

The long-term vision is to change the architecture such that instead of having exactly one renderer ("target") per rule, we allow authors to define arbitrary pipelines, and offer more choices wrt transformations. In such a scenario, the template path would simply be a configuration option for the template renderer.

Short term, the template path should become configurable in the project file, plain and simple.

As far as the data goes, you already have complete freedom there, just put the theme data in ./theme/data/, and the non-theme data in ./data/, or wherever else you like. With a configurable template path, you can then easily have themed templates as well.

Changing the hard-coded path to another hard-coded path is unacceptable, because it would break backwards compatibility; but if you feel like trying your luck at making the template path configurable, then patches are very welcome. And if you feel you can't do it yourself, you might want to try your luck at talking me into implementing it myself ;)