Fig 1: Flask Web Framework Logo
花了整整一个多月来学习Flask AppBuilder（以下简称FAB），当初就计划如果有困难，就退回Flask/Cyclone/Tornado来重新构建工程。现在看来，可以使用FAB与经典Flask混合编程的方式来实现。
FAB的好处
FAB有一大堆好处，其中包括自动化的CRUD和皮肤化UI设计。从ORM一次型导出：
- /modelview/list
- /modelview/show/<int:>
- /modelview/edit/<int:>
- /modelview/delete/<int:>
- /modelview/add/
对我个人来说，它帮助我解决了最基础的RBAC问题：即何种角色对应何种权限。这种设计是基于注册机制的，权限记录在数据库中，可以动态修改，而非硬性编码在源码中，比较灵活。
FAB的缺陷
FAB的缺陷与好处是一张纸的两面，自动化的CRUD意味着许多Controller部分代码，即逻辑和渲染代码是嵌入在FAB框架中的。在相当多的情形中，自动CRUD意味着修改困难。这一个月，我基本上就是受其折磨，反复揣摩如何定制。
混合编程
做了若干个试验项目之后，发现：FAB的自动化CRUD其实很适合作为后台管理员的界面，后台管理员可以完整地查看所有的数据以及相互关系。前台用户业务界面和流程适合经典Flask开发组合来完成。FAB的依赖项和经典Flask开发组合的依赖项存在高度重合，所以混合开发模式完全没有问题。他们共同依赖项包括：
- Flask，flask框架本身
- Jinja2，模板
- flask-sqlalchemy，flask扩展的ORM
- flask-login，flask的登录组件
- flask-openid，flask的openid组件
- flask-wtform，flask的表单组件
- flask-Babel，flask的多语种支持组件
- Werkzeng WSGI工具集
除了FAB自动创建的URL，混合编程之后的URL包括：
- /modelview/list
- /modelview/show/<int:>
- /modelview/edit/<int:>
- /modelview/delete/<int:>
- /modelview/add/
- /modelview/mylist
- /modelview/myshow
- /modelview/myedit
- /modelview/myadd
- /modelview/mydelete
- /modelview/methodx/<param>
其中my*等方法都是通过@expose装饰符在Flask中注册URL，如果进一步采用@has_access修饰符，FAB会自动创建权限，管理员可以通过FAB，将其定义为某种角色可使用的对象。
即将交付
厘清了FAB/Flask混合编程的分界线之后，即将交付的工程包括：
- 智能门锁
- LoRa智能网关，面向智能城市和农业
- NB-IoT/eMTC资产定位
