Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

override List<Resource> Resources not getting called when creating ContainerSettings #4257

Open
leigh-pointer opened this issue May 13, 2024 · 2 comments

Comments

@leigh-pointer
Copy link
Contributor

Oqtane Info

Version - 5.1.1
Render Mode - Interactive
Interactivity - Server
Database - SQL Server

Describe the bug

When loading the Theme ContainerSettings the public override List Resources => new List() is not called.

Expected Behavior

The method is called

Steps To Reproduce

add to a containerSettings component

        public override List<Resource> Resources => new List<Resource>()
        {
              new Resource { ResourceType = ResourceType.Stylesheet, Url = "~/css/Theme.css" },
        };

Anything else?

@leigh-pointer leigh-pointer changed the title override List<Resource> Resources not getting when creating ContainerSettings override List<Resource> Resources not getting called when creating ContainerSettings May 13, 2024
@sbwalker
Copy link
Member

sbwalker commented May 14, 2024

This is complicated. The framework Settings component dynamically loads 3 other components at run-time:

  1. A component within a module which implements Oqtane.Interfaces.ISettingsControl
  2. A component within a theme which has a ThemeSettingsType defined in its ThemeInfo
  3. A component within a theme which has a ContainerSettingsType defined in its ThemeInfo

Dynamically loading components within a module does not conform to the standard component loading patterns which means that the Resources are not discovered or loaded by the framework. Resources can currently be defined in 4 standard ways:

  1. In a module component
  2. In a module's ModuleInfo (IModule) class
  3. In a theme component
  4. In a theme's ThemeInfo (ITheme) class

Supporting these exception cases will require some investigation, as we do not want to add custom logic to handle them at the expense of degrading framework performance for the other scenarios (ie. reflection is expensive and would be required to get access to the Resources).

@leigh-pointer
Copy link
Contributor Author

@sbwalker should we not introduce something like this ?

    public class ContainerSettingsBase: ModuleBase
    {
        private new List<Resource> Resources;
    }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants