I have moved the Views, Models and Templates into a blueprint. Actually I have created two blueprints, one named antminer and one _antminerjson.
The thing with the blueprints is that you can organise a set of routes into a blueprint.
I was thinking to create separate blueprints for different miner brands, like Antminer, Avalon, GpuMiners.
So we will have different endpoints for our miners which is not practical the way the software currently retrieves the data to render.
It would be practical if e.g. we would render each brand in its own table. We would have to retrieve the data using AJAX and populate the tables. This would solve the problem of the delay if someone owns a lot of antminers and avalons, since there would be two calls to retrieve the data instead of one.
Adding more asic brands and gpu rig support would make the one view grow huge which will be very difficult to maintain.
So the idea behind all that is maintainability and keeping functions small.
@sergioclemente I am currently finishing refactoring the app into blueprints. Blueprints are Flask's way of creating components (http://flask.pocoo.org/docs/latest/blueprints/).
I have moved the Views, Models and Templates into a blueprint. Actually I have created two blueprints, one named antminer and one _antminerjson. The thing with the blueprints is that you can organise a set of routes into a blueprint. I was thinking to create separate blueprints for different miner brands, like Antminer, Avalon, GpuMiners. So we will have different endpoints for our miners which is not practical the way the software currently retrieves the data to render. It would be practical if e.g. we would render each brand in its own table. We would have to retrieve the data using AJAX and populate the tables. This would solve the problem of the delay if someone owns a lot of antminers and avalons, since there would be two calls to retrieve the data instead of one. Adding more asic brands and gpu rig support would make the one view grow huge which will be very difficult to maintain. So the idea behind all that is maintainability and keeping functions small.
Blueprints to be implemented
- [X] Users - [X] Login - [X] Profile - [X] Changing password - [ ] Admin - [ ] User management - [ ] Adding Users - [ ] Removing Users - [ ] Adding Roles (User, Power User, Admin, etc.) - [ ] Removing Roles