The text widget properties could be improved to be more consistent with other widgets:
The type should be a single value corresponding to the widget type and underlying code. In this case it should be text. In general, widgets should have a single type that identifies the type of widget and simplifies code.
The content type (Markdown, HTML, text), etc. could be specified in one of the following ways and should be compared with other code for consistency:
Add a contentType=Markdown or similar property to indicate the content type. The path could then generically be textPath=.... This has the advantage of being more explicit and is similar to mime type.
Indicate the content type in the file extension and use a generic property name, for example textPath=/something.md. The disadvantage is that the file extensions would need to be interpreted and supplying text in a property would still require something like contentType (see below).
Indicate the content type in the property name, and allow any filename, for example markdownPath=/something.md. The disadvantage is that different JSON properties would need to be handled for each content type (this complicates the code if we build a dashboard configuration UI tool.
Could allow the text to be specified as a property, for example using text=.... If the contentType property is used, the text would be handled accordingly. This would allow specifying inlined text in the configuration without having to read a file, which would simplify the configuration for simple text.
Should more complex CSS be allowed? For example, what if a large file is used? The documentation could explain how the showdown or application CSS is used by default. I don't know if it makes sense to supply a CSS file specific to a document.
The text widget properties could be improved to be more consistent with other widgets:
typeshould be a single value corresponding to the widget type and underlying code. In this case it should betext. In general, widgets should have a single type that identifies the type of widget and simplifies code.contentType=Markdownor similar property to indicate the content type. The path could then generically betextPath=.... This has the advantage of being more explicit and is similar to mime type.textPath=/something.md. The disadvantage is that the file extensions would need to be interpreted and supplying text in a property would still require something likecontentType(see below).markdownPath=/something.md. The disadvantage is that different JSON properties would need to be handled for each content type (this complicates the code if we build a dashboard configuration UI tool.text=.... If thecontentTypeproperty is used, the text would be handled accordingly. This would allow specifying inlined text in the configuration without having to read a file, which would simplify the configuration for simple text.