dnncommunity/dnn.structuredcontent

This is a proof of concept for a structured content solution for DNN Platform (formerly known as DotNetNuke). This should not be used in a production environment. Anything can change at this stage of development.

DNN Structured Content

This is a proof of concept for a structured content solution for DNN Platform.

This should not be used in a production environment. Anything can change at this stage of development.

Building

• Install a local DNN Website of the current latest version (we are not planning to support old DNN versions)
• Clone this repository into the DesktopModules\Admin\Dnn.PersonaBar\Modules\ folder of that website
• Open Visual Studio as an administrator, then open the Dnn.StructuredContent.sln solution.
• Hit the Package button in Visual Studio to start a build.
• Once the build is done, go to that DNN instance to Extensions and then Available extensions and you should be able to install the module on the instance.
• To debug after that initial installation, use the Deploy ... Options in that same dropdown you used Package and then attach the debugger to the website.

Releasing

The project includes some nice build/release automations. In order to create a new release:

• Never commit directly to the main branch, this is reserved for official published releases
• Plan your versions ahead using milestones, only merge into the develop branch the things you plan on publishing on the next version and assign that mileston to each PR.
• When ready to release, create a release/x.x.x where x.x.x is the version you want to release (must match some milestones of merged PRs)
• Withing a few minutes, you will see an unpublished release with that version that will be named x.x.x-beta1, it will have the build artifact as well as release notes based on PRs that got merged for that milestone, you can publish this for testing.
• When testing is done and you are ready for an official release, merge that release/x.x.x branch into the main branch, within a few minutes a new "non-beta" unpublished release will be ready for you to adjust/publish.

dnn.structuredcontent's Issues

Fix missing Name ContentField on ContentType designer

'Name' is a required ContentField for every ContentType and is created automatically when creating a new ContentType. But I broke it when I consolidated the Text type fields.

Convert all field names and variable names to use CamelCase instead of _

Implement build deployment task

A build packaging task was created that handles packaging the module to install it anywhere. For development purposes we need a deploy task to deploy to the local instance.

We need to not throw back details of general exceptions to the frontend.

Describe the bug

Currently most Web APIs catch Exception and throws the details back in the frontend.

It is best practice to give a more generic message on general exceptions because we don't know what failed and it could expose sensitive information.

Create logic to delete dynamically created tables upon module uninstall

This can only be done after this is done dnnsoftware/Dnn.Platform#2160

But the idea is that if someone would uninstall the module, it should not leave data behind and most of the data tables where dynamically created so would need to be done from code.

Error when editing a new content type

After creating a new content type (in this case "Author"), I get an error when attempting to access the content type.

Investigation if the ContentFieldTypeController should allow creating/updating

I believe that we cannot allow dynamically creating new content types as it involves some custom backend behaviour and we probably can kill all the methods that allow creating/editing in this controller.

Need more filtering/sorting options for the datasource of a Visualizer

After selecting a datasource for a visualizer, the only current options are to return everything for a list type visualizer, or manually select a single record for a single type visualizer.

Should probably also add sorting and paging options (skip/take) as well.

Looking for examples of existing systems that do it well and we can mimic that.

Support an Alternate Database Connection

Like the old Reports Dnn module and others over the years, one addition I would like to suggest early in development and planning, is whether to use the default Dnn connection or instead, a different named connection (defined in web.config). I think the option to house all this data in a separate db will appeal to a lot of people for some use-cases.

I think it would be worth discussing or fleshing out the defaults, assumptions, and fallbacks. Its likely all that is needed is a global/default to fallback to always when a Named Connection is not specified. But I can also imagine use cases where the connection to use might be at the Dnn/Instance, Site/Portal, Module, or Tab/Module level. Use cases? Or maybe there is already a well defined pattern that covers this?

What about the granularity of each Entity/Table being able to have its own Connection? A bridge too far?

All that having been said, my suggestion is keep it simple to being with. One global setting for a Connection Name, otherwise use Dnn. All data created and Managed by StructuredContent goes in that one place. Then the only advanced thing to deal with is: how do they move their stuff from the Dnn db to the named connection later, after they've got stuff already in place and working?

Just an opinion... note that since Connection Strings are inherently an advanced option - due to the number of disciplines involved in getting them working, setup correctly, and securely - so I do not think StructuredContent should attempt to store or handle any of the setup logic beyond simply knowing the Connection Name. I don't think its a good idea for learn-as-you-go folks to attempt database creation/permissions, web.config editing, etc. "If you cannot plug a Connection Name in to StructuredContent that already works, don't try." :)

So, all that having been said. This should either get done soon or immediately get put on the Roadmap for v2 or v3. Or declined completely. Cheers!!

Add Image / Document / Video as ContentTypeFields

Similar to the other field types, it would be nice to have the ability to drag an control on the form designer to represent an image/document/video picker control.

I think the best way to do this is to have a system generated ContentType for Images, Documents, Video and each of these are really just a piece of content that is managed by the system and thus should be contained in (or at least accessible to) the StructuredContent module. Then, we can build a UX for picking an item from the collection. Should also have some capability to upload a new file to the collection.

Create an uninstall SQL script

We need to create an uninstall sql script if anyone want's to be able to remove the module without leaving data behind.

This involves 2 parts

1. The tables that were created by the module installer
2. The tables that were created dynamically by the system

For 1, we just have to create an Uninstal.SqlDataProvider (the goal of this issue

For 2, it would be very difficult right now but it should be easier once I have to time to work on this: dnnsoftware/Dnn.Platform#2160

Database Schema Discussion for `ID`

I've noticed that the ID columns are literally named 'ID`. This issue is here to discuss if we want to change that before this module has an official release to prevent potential issues in the future since this is a reserved word.

Swap Linq to SQL for Entity Framework 6/core OR PetaPoco?

The current implementation uses .dbml, which is also known as Linq to SQL, which is an optional installation feature and requires developer opt-in at Visual Studio Installation.

I believe it would be better to either use PetaPoco (DNN Standard) or EntityFramework to keep the number/types of platforms used down and limit developer install needs.

Fix .csproj file to not be tied to specific version of VS

This is specific to VS2019.

Replace 'v16.0' with 'v$(VisualStudioVersion)'

Persona Bar module needs a localization key

It currently shows the resource key instead of the localization value due to lack of localization

Remove some unused files

content-field-type-options/radio-button-list

Simply the designer UX by combining like type

Checkbox and Switch can be combined into Boolean with an option to display either a checkbox or a switch
Dropdown List, Radio Button List, Checkbox List can be combined into "Choice"
Textbox, Textarea, and Rich Text Editor can be combined into "Text"

Enhance Boolean ContentTypeField

The boolean ContentTypeField could be enhanced.

1. Besides just the checkbox and switch control_types, it could also have a radiobutton list of two items.

2. The user should be able to have values beyond just true/false. "Yes/No", "Open/Closed", "Active/Inactive", and perhaps even allow the user to provide their own "other" boolean values. The value stored in the database can still be a bit, this would just be changing the labels on the chosen control.

Localization of data

I don't remember from the presentation if this was already somehow supported but it would be nice to have localized data.

I did not have time yet to dig in into how it's done now for field names, but I guess there is some "meta-data" about the created tables stored somewhere, so if we can have a local field in that meta-data, that would allow us to have localized field names for the form/display UI.

For the data, at a bare minimum, we need to be able to duplicate each row and have a locale field on it. If that is blank (it probably needs to be nullable to cover the scenario of a non-localized site becoming localized in the future), then I think if it's null it represents the site default language, then for other locales, it duplicates the row with the locale string (like fr-CA) and carries a parentId or some such to link that row back to the one in the default locale. The default site locale in DNN cannot be changed after the fact, by the way, so not too much to worry about there.

But not all fields make sense to localize, so it might make sense to know which fields are localizable and which are not, maybe that information can be in that supposed meta-data about those tables. For instance, for a Product, you want to localize the name and description but probably not the price and which categories it is part of. Preventing localization on the price would make it easier to change the price on all locales without worrying about the price becomes different per locale.

Input Mask Ability?

Discussed in #75

^{Originally posted by mathisjay September 22, 2021}
How useful would it be to be able to set an input mask on textbox type inputs? In the setup options we could provide a list of common mask (phone number, zip code, SSN, etc.) and also have the ability for the user to provide a custom mask and a custom validation message.

Useful?

Implement style cop analyzer

For improved code quality and style, StyleCop.Analyzers is used in Dnn.Platform. Therefore, it should be used here. This is the initial implementation and includes fixes for most of the global changes. Everything remaining will be a bit more opinionated on how we go about resolving.

Swap out ACE editor for Monaco

Currently the project is using the ACE editor for visualizer template code editing. It would be super nice to swap this out for the Monaco editor (already available in DNN). I'll be happy to take this one on as soon as I am able to complete setup of my local development environment.

The "Choice" ContentTypeField needs the ability to have an "other" option so the user can provide their own value

Force NewtonSoft Serializer to send camelCase JSON.

JSON objects need to be camelCase for the .js to work correctly.

Create initial DB scripts from prototype

Need a script to create the DB objects and default data

Permissions

I am just creating this issue to not forget about it but it's not a very fleshed out issue ready to tackle. I just want to try and collect everything we need to make this project in a state to allow it to be (v1 worthy) 😄

We need to handle permissions for:

• Content Editing
• Web API Access
• UI views (visualizer?)

We can break this down in smaller more manageable items, but just wanted to dump the idea here for now.

Use ToLowerInvariant() for Better Language Support

String comparisons of names should use ToLowerInvariant() to ensure that characters are consistently converted to lowercase without any current culture behaviors. I can submit a PR for this

Change custom database table name prefix

Currently, the custom table name prefix is zz_. It has been agreed this should be sc_ instead.

Creating ContentTypes doesn't work if the name is in singular

'Authors' as a name works
'Author' doesnt.

Build instructions

@mathisjay I cloned the repository and tried to run a build, I noticed the references to DNN libraries are relative instead of using nuget packages and did not find a manifest or any special build scripts. I can help with that but would need to make a build succeed first. So 2 questions:

• Currently into which folder of a DNN site do you put this in order to be able to build it ?
• Are you OK targeting DNN 9.10.x instead of 9.2.x ? This would allow much better usage of Dependency Injection and I don't think we want to support older versions of DNN right ?

Correct UX/messaging on delete content type modal

Currently the UI prompts the user to "...enter the name of the table...".

The actual name of the table for the above example is zz_books but the UI seems to be expecting the name of the Content Type instead. Entering the actual table name results in a disabled Delete button.

Data/Schema scoping

Currently, all schemas and the data they contain are global for the whole instance.

I believe the solution only makes sense if we can at least be able to scope it by portal. A PortalId field here would do it for the data but not for the schema. One site may want a Contact table that has 3 fields and no relations but the other site also want's a Contact table but with 10 fields and 3 relations. Those schemas would be incompatible.

For other uses cases, the instance owner may want to have a schema/data that is global for all portals and would hate this feature.

One solution to implement this without breaking the global option would be to add an optional _portalId to the table names.

So Contacts would be global for the instance, but Contacts_1 and Contacts_2 would be scoped per portal.

This leaves us with just the naming conflict between the global and portal specific ones... I am not sure what is the best way to solve this one but I think that since it's all WebAPI driven, the APIS could have a portalId in their request, if not provided they would serve the global one but if provided would serve the portal specific one.