- Use the API to skip diagnosing apps that don't implement diagnostics.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- move header section to it's own file so that it can be imported across
the app (app.html, simple_app.html, setup.html)
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes#930
- Make targets to download wiki pages of each service
- Add post-processor script for DocBook file processing
Signed-off-by: Joseph Nuthalapati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- The last part of the module import path is the module name. This also
becomes the Django app name. Apps names have to be unique. Hence,
there is no scope for two different modules with same name but
different load path to exist in the project.
- Most uses of list of loaded modules are dealing with app names instead
of full module load path. This is due to the fact that Django deals
with app names and not module paths.
- It is also somewhat clumsy to access a loaded module as we are
re-importing every time to get access module.
- Simplify all of the above by using app names are module identifiers
and maintaing an ordered dictionary of app names to loadded modules.
- Remove unused imports.
- Minor styling fixes.
- Run diagnostics on each module separately.
- Run diagnostics in a separate thread.
- Show progressive update while running diagnostics.
- Store and show old diagnostics.
- Prevent CSRF on the expensive operation of running diagnostics.
