Module packaging constraints (relationship between module definitions, assemblies, namespaces, index.razor etc)

[lanthonyneville]

I am trying to get my head around what the constraints are around packaging modules (e.g. "can I include more than one module definition in a single assembly"), and it reveals I don't really understand the Oqtane page lifecycle and how Oqtane knows which razor components should be rendered on a given page.

(coming from many years developing for DNN, I am used to a loose complex model where multiple module types could be packaged together, and the relationship between all the parts specified in a manifest file, but Oqtane has a much simpler model, no manifest, and more reliance on conventions it seems ... quite a relief in many ways!)

My conclusion so far is:

• each assembly can contain multiple module controls (razor components implementing IModuleControl), but only 1 module definition (specified in a single class implementing IModule ... if there is more than one, the others are ignored)
• there is no direct reference (in code) from a module control to its module definition - from the above, a module control's definition is the (first) IModule class found in the same assembly
• when a module definition is discovered, it is registered in the ModuleDefinition table with a key (ModuleDefinitionName value) = the namespace comma assembly name
• in the database, a page can contain multiple module instances (recorded in the PageModule table), and each PageModule record points to a Module record which points to a ModuleDefinition record
• therefore when rendering a given page, Oqtane knows it has to render one or more module controls (razor components) but only has the namespace + assembly of each. I guess it therefore always renders the one called "index.razor"?

Is that about right?

I guess then that the way to package a "family" of related modules would be to generate a single NuGet package containing all the assemblies of those modules? In the Nuget package meta-data (e.g. .nuspec file) there is a version number and unique ID, but hopefully can be set however I want and don't have to related to the module definition version etc?

PS: if my understanding above is correct, why is there no unique constraint on ModuleDefinitionName in the ModuleDefinition table?

[leigh-pointer]

@lanthonyneville short answer, yes you can. One module set IModule should reside in it own namespace.
Multiple Modules->
namespace Mycompany.Module.ModuleSuite IModule -> ModuleInfo - Index; Edit; Settings
namespace Mycompany.Module.ModuleSuite.ModuleB IModule -> ModuleInfoB - Index; Edit; Settings
namespace Mycompany.Module.ModuleSuite.ModuleC IModule -> ModuleInfoC - Index; Edit; Settings

IModule is read at startup and the ModDefs created/updated

HTH

[lanthonyneville]

Ah, yes - separate them by namespace within the same assembly. Great idea!

[sbwalker]

@lanthonyneville the Oqtane.Client project is essentially a suite of modules... each module with its own namespace, components, etc... all compiled into a single assembly.

[sbwalker]

@lanthonyneville there is no unique constraint on ModuleDefinitionName in the ModuleDefinition table because it is auto populated based on assemblies in the /bin - which means there is technically no way a fully qualified type name could be duplicated.

[lanthonyneville]

@sbwalker , @leigh-pointer thanks, much clearer now.

So last questions are

• if in a given namespace (i.e. for a given module definition) there are multiple module controls (i.e..razor files, implementing IModuleControl directly or via ModuleBase), does Oqtane always look for one called index.razor to render on the page?
• is there a requirement/benefit to inherit ModuleBase for other controls, e.g. add.razor etc (e.g. it makes it easy to navigate between controls) other than getting access to the IModuleControl properties that give useful context?