oqtane / oqtane.framework

CMS & Application Framework for Blazor & .NET MAUI
http://www.oqtane.org
MIT License
1.88k stars 548 forks source link

Dev - Modules need a CSS selector #2638

Closed thabaum closed 1 year ago

thabaum commented 1 year ago

It would be helpful if modules (components) had their own unique selector.

ModuleName-ModuleTitle may work or ModuleName-Id or mod-id to keep it generic.

Maybe a setting to choose your own naming convention like in a template within site settings?[ModuleName] [ModuleId] [ModuleTitle]along with any other or if you want you can just put "Module" or some identifying word that identifies all of them this way as well. A developer can have module or appcomponent or whatever they desire as one selector and turn on/off the creation of this selector within the site settings? Make it even more configurable it could be a page setting as well that can be set to create custom module css or not.

for example a module name of HtmlText with a Title of "Welcome" would get a css selector added to the first

in the place shown below for the module of htmltext-welcome if using module title or htmltext-2242 so if the title changes the ID should stay the same and the css will follow the ID instead of Title which is probably the best solution.

Last idea if masking the module name is desired we could make it more generic like mod-id

Regardless if you have different backgrounds from a vendor it would be nice to control those in one CSS file for the theme and site.

Bottom line I believe we need something to make it easy to identify and style each module instance if desired within the framework.

I can probably produce this PR if desired or maybe it is something already planned?

image

sbwalker commented 1 year ago

One of the high level goals of Oqtane is to avoid the injection of UI elements or wrappers to ensure that designers have full control over the rendered output (as a very common complaint of many frameworks/CMSs is that they pollute the UI with additional markup). So although the composite user interface in Oqtane is broken into various types of components (ie. Theme, Container, Module) developers/designers have full control over the HTML markup included in those components, and no additional markup is injected by the framework.

I believe what you are suggesting is that the framework should inject a wrapper around each module instance, and the wrapper should have a unique name so that it could be targeted with a CSS selector. I would like to hear feedback from more designers/developers if this is indeed a common requirement before taking any action on this item.

lanthonyneville commented 1 year ago

Isn't this something that can be easily accomplished in the module container razor file? Of course that depends on the container of choice being installed, but it sounds like the context for the question is theme design, so that is under your control. For example:

@namespace MyTheme
@inherits ContainerBase

<div class="@containerClass">
    <div class="row px-4">
        <div class="d-flex flex-nowrap">
            <ModuleActions /><h2><ModuleTitle /></h2>
        </div>
        <hr class="app-rule" />
    </div>
    <div class="row px-4">
        <div class="container">
            <ModuleInstance />
        </div>
    </div>
</div>

@code {
    public override string Name => "MainContainer";

    private string containerClass = "";

    protected override void OnParametersSet()
    {
        containerClass = $"mod-{ModuleState.ModuleId}";
    }
}
iJungleboy commented 1 year ago

@sbwalker I agree that the frameworks shouldn't polute the HTML. There are many cases which then force developers to work around it - eg. in some scenarios you want to keep modules "together" - like when you need <sections>, in other cases not - all such use cases get more difficult if the framework does things.

In addition, there are many, many kinds of needs and everybody has something else

  1. Some would like a module type - eg class="module-2sxc"
  2. Some would like the module id - eg class="moduleid=434"
  3. Some would like information about the language, user, page-id, parent-page-id and much more (eg. what we do in our 2shine theme - for example to control colors etc.
  4. Some would like information about the container used, about the theme
  5. Some would like information about the current user permissions, eg. class="user-can-edit"

I believe the needs are so diverse, and it's easy to implement your own, that I would hesitate to add it to the platform. IMHO it only makes sense as part of the standard if cross-module-concerns would require this. Other use cases should be done by each developer as he needs it eg.

  1. a specific module can always add it's own classes to distinguish itself
  2. A specific site can always have a container that does this
thabaum commented 1 year ago

Hey everyone,

I had a tough time with DNN's themes and vendors, and I don't want anyone else to go through that. I believe that !important should not be used to theme modules, apps, or components, as it causes constant fighting between them. I think that Oqtane has the potential to be great and we should focus on taking it to the next level.

I've been working with Blazor and Maui and think that .NET 8 might be the right time to make some changes. I know there are still concerns with breaking changes, so maybe we can introduce a switch in the framework that keeps things running on .NET 6 with instructions on what needs to be updated for .NET 7. Instead of two forks, we can have two supported versions - long-term and short-term - so we can choose which to use for our modules.

I also think it would be nice if we could dynamically introduce CSS selectors into certain parts of the application from a theme to style specific parts for certain user roles/groups, and maybe have two variables that can be configured. I know this can be done with other means, but we should evaluate all options to maintain uniformity in community development.

I recently encountered a need to add a variable to Oqtane to support my specific project requirements. This highlights the importance of careful planning and documentation when making changes to any software project to avoid the risk of overwritten changes in future updates. However, we also need a flexible and inclusive framework that allows us to add things inside an element beyond CSS.

Sorry for colliding a few conversation ideas into one, but I think these are all important things to consider as we move forward with Oqtane.

Thanks!

thabaum commented 1 year ago

I read this, I must of been up late the night I made this. I had something in mind but reading this now it really does not make sense so I am closing the issue until I get a more clear use case to present. The module development CSS you can create as you like, I believe I was more interested in the app having CSS selectors you can inject that would match up with a module name so it can style all modules synced with a users theme... not sure how I can explain so I will get a better idea of how it would be useful and explain in the future. I may be pushing the idea I was looking for in the experience I was looking to generate. KISS right?