Theme and container settings included in default template

[thabaum]

Default template should include settings for turning features in the theme on and off such as the login component. ? I can try to PR this if this is correct which I believe it is.

We can also create a "Blank" template possibly to select at time of theme creation, however the default theme template should be as feature packed as Oqtane default theme.

[thabaum]

I see the localization and things could be included, I do have a working prototype to offer that would align with the current Oqtane theme (same code migrated to the default theme template files)... I am still combing through it for anything I can cleanup to get it easier to start a project on the fly here.

I will see how the last PR works out with the necessary basic changes. Then I can add the rest what is needed to get all the stock template features offered in the default theme template.

[sbwalker]

I am not opposed to including theme and container settings in the default template if it makes it easier for developers/designers to use the framework

[thabaum]

I will doctor up a PR if it hasn't been done yet next time I can fire things up for it. I believe it would help ease a start up project for a designer/developer.

[thabaum]

I will get this done just prior to .NET 8 LTS release to incorporate any updates when that gets more towards release time so only minor adjustments may be needed if necessary.

[vnetonline]

Pull Request #2940 submitted to address this issue

[vnetonline]

@sbwalker or @leigh-pointer

Can there be a Theme or Container setting for each Theme or Container?

From what I can see there can only be one ThemeSettings and ContacinSetting defined in the ThemeInfo?

[leigh-pointer]

@vnetonline you would need to extend the namespace.. ie StudioElf.RocketFuel.Theme1 ThemeInfo StudioElf.RocketFuel.Theme2 ThemeInfo StudioElf.RocketFuel.Theme3 ThemeInfo

@sbwalker correct me if i am wrong?

[vnetonline]

I don’t think that’s right if you extend namespace and want to use base method like @ThemePath() to reference assets it wouldn't work

Because the assets are stored in [Owner].Theme.[Theme] under wwwroot and creating a folder for each namespace is not going to be good because it will cause duplication of assets

[sbwalker]

@vnetonline you are correct that you can only define 1 theme setting or container setting component for a theme *regardless of how many different theme or container components exist). It would be possible for you to enhance your theme setting component to allow a user to select from a list of possible of theme components that exist in your theme (ie. theme1, theme2, etc... ) and then display UI options that are specific to the one chosen (and load/save those options with the unique theme name in the setting name to differentiate them).

@leigh-pointer is correct that you can also use unique namespaces to separate themes - but each unique namespace is treated as an independent theme - not as different variations of the same theme.

You do not need to use ThemePath to access your static assets - it is simply a helper method to provide a path to a folder which has the same naming convention as the theme itself (ie. using the same namespace). You could use a custom theme path instead if you want to organize your assets differently and share them across themes. It is up to you. The Bootswatch example theme (https://github.com/oqtane/oqtane.theme.bootswatch) takes this approach to customize the theme path.

[vnetonline]

Okay makes sense after looking at the Bootswatch approach