Open hishamco opened 2 years ago
@Piedone I may need your suggestion here
Orchard Core already follow the following pattern:
OrchardCore.XXX.Abstractions
OrchardCore.XXX.Core
OrchardCore.XXX
-> Module
The issue I'm facing here there's no default implementation for some module, for instance localization it has two implementations: JSON & XLIFF. So, creating a module for each one make sense but I can't use the same pattern that OC follows. I'm not sure if you faced similar issue in Lombiq modules
We're going the simpler route, it's always just Lombiq.ProjectName
. This is what I'd suggest. Then, for example for two localization implementations, you can have sub-features (in case of modules) or sub-projects in the same repo, like OrchardCoreContrib.Localization.Json
. I wouldn't add Modules
here.
for example for two localization implementations, you can have sub-features (in case of modules)
Sound good but I'd like to make the implementation in different modules something similar to Azure & Amazon media in OC
Again in OCC.Email I have both OCC.Email.Abstractions
and OCC.Email
for that reason I can create a module with the name OCC.Email
instead I wrote module for each implementation. Having them as feature might the way I can go for. But how can I avoid naming collision especially if I have implemenation types like what I have in email and localization
Thanks
Just revising this one, while OC is a Web Application Framework (WAF) that means it's component could be used without UI parts or notion of module, something similar to OrchardCore.Localization.Core
which you can use PortableObjectStringLocalizer
in any ASP.NET Core app. That's why we have many OC.XXX.Core
to have a default implementation for certain abstractions APIs.
Also having OCC.Modules.XXX
will make it easier to look for modules in NuGet similar to OCC.Themes.XXX
Recently I saw there .Core
version for each OC.Search
implementation, the reason, we can't use OC.Search.Lucene
for instance because the collision that will happen with the module name
From my perspective, the framework APIs could be used in any ASP.NET app, while the modules is something related to the OC CMS
Consider rename the assembly to
OrchardCoreContrib.Modules.XXX
to avoid the conflict that may occurs between OCC & OCC.Modules repo assemblies.For example
OrchardCoreContrib.Localization
already provide set of localization APIs implementations, so when we want to create a localization module we will stuck on the naming.The consequences are: