ToDo DNN - 1. Introduction
When I announced that I was no longer working at DNN Corp, I did make it clear that it was still my intention to remain active in the DNN Community. And so, for the last couple of weeks I have been trying to decide what I should do.
In my role as Senior Architect and Chief Architect at DNN Corp I often found myself adding or updating the framework for developers to write module extensions for DNN. And, of course, that meant that I needed to create a module in order to test out those features. Often I did this by creating a To-do or Task List module.
Inspired by the Todo MVC site, which provides examples of writing a simple ToDo application in the many MV* JavaScript frameworks, I have decided, therefore, to create a ToDo DNN Github repository where I will provide examples of the many ways to build a DNN Module.
Opinionated
These module examples will be opinionated. They represent, how I would build the module using a particular module development style. They will not necessarily be how others in the Community build modules in a particular development style and they will not necessarily agree with practices recommended by DNN Corp, and so I offer the opportunity for other community members to submit their favourite interpretation of the ToDo module.
Build and Deploy
Every module created as part of the ToDo DNN project should be able to be built and deployed using a simple build script, which I will provide as part of the Github project.
Requirements
Every module created must implement a minimum set of features, as follows.
- Each ToDo item or task must have a name, a description, date created and a flag to indicate if it is completed.
- The standard view of the module should display a list of all the ToDo items, as well as filtered lists of completed items and active (or incomplete) items.
- The module should provide a setting that determines if the module instance owns the ToDo items OR if each registered user has a separate list of ToDos.
- The module should provide a setting which determines if “deleted” ToDos are removed (hard-deleted) from the database or are soft-deleted.
- If the above module setting is set to “soft-delete” there should be an extra filter to view the “deleted” ToDos so they can be restored.
- The module should be localizable
This is the basic set of requirements – but module developers who wish to contribute an example module can add extra features in order to show a particular “Best Practice”.
Tests
While not always possible, modules should provide Unit Tests for the code. I say, while not always possible, because some development styles are not set up to easily support Unit Tests. But, if a module development style supports Unit Tests, they will be provided.
So that’s my plan. In the next blog I will discuss my first sample ToDo DNN module – Classic WebForms.