Define static content for pages

[pjmonks]

The MDE application is able to render some pages using predefined static HTML content. This is done by:

1. Storing plain HTML files in an assets/content folder in the application
2. Using a StaticContentService to fetch URLs (GET) and returning plain text responses - the content from the resource
3. Rendering that content to a content area on a page e.g. a <div> using [innerHtml]

This then handles pages some as the homepage, help pages etc, without requiring a TypeScript component.

This idea could be translated to MDM as well to handle similar pages. Specifically, it could be helpful as part of custom theming the application to allow other instance users to define their own homepage or similar content, so long as there was a public, accessible resource to fetch HTML from.

[jamesrwelch]

I guess the issue with this is that the content still needs to be compiled into the angular app, meaning that users need to compile their own (hard when using the Docker setup to install / manage), or we need to (as we're currently doing) precompile and distribute all themes and control using environment variables.
Could we instead create a very basic back-end plugin that could store, and overwrite the content? Then either the back-end could control the 'default' content, or perhaps the UI could have some default content if the back-end doesn't have any content to provide?

[jamesrwelch]

Maybe the solution is to build this in a branch, and then for us to try replacing the URL with something controlled by the back-end.

[pjmonks]

I don't think static assets have to be compiled into the Angular application, because assets like images are not compiled, they are packaged alongside the JavaScript code. In the example I gave about the MDE, the static HTML is stored alongside other assets like images but only because it made sense for that limited scenario. I think it would be possible to refer to any public URL for the content e.g. https://my-custom-domain/assets/content/homepage.html, so long as CORS was handled correctly.

The alternative of having a plugin that stores this content directly within Mauro could work as well though. If the plugin provided an endpoint that could return plain HTML snippets, that would be the equivalent of what I'm suggesting, plus all content would be stored in Mauro and not distributed around the wider internet. Referring to other content might need some consideration - such as writing HTML content that displays images, that reference would ideally be relative somehow.