Refactor part code for better code maintenance and higher coding efficiency

[DaveZLB]

1> using front-end architecture instead of jquery, such as AngularJS

if Using front-end architecture for data template and data binding, every page need be changed，it includes gateway , deviceService, Scheduler,Notification and AppService pages.

[badboy-huaqiao]

@DaveZLB firstly , jquery is not a front-end architecture, secondly , angularjs is not supported officially any more, but angular2+ would be considered, but after research, there're some stuff cannot be overcome, such as data communication bidirectional must rely on backend server which angular2 cannot reach, others like layout, one page may consist of multiple components, but in angular2+ model, one component is consists of three subcomponent at least, it' looks not so convenient for developer, and the most point is that angualr2+ is just a web-end architecture, it doesn't officially provide a complete component library of its own ,which means that yourself only can rely on third part library, and you or me or the community developers don't have ability to develop one. so it should be as second option.

[badboy-huaqiao]

关于edgexfoundry UI重构问题声明！ 该问题本人曾多次阐述，这里是最后一次申述。 介于开发人员水准层次不齐，这里只做简单描述。

首先，回顾EdgeXFoundry UI的发展史！ UI的诞生最早可追溯到java版本的edgexfoundry，那时候edgex还没有api gateway，但是最为一个微服务架构，API gateway是必须的具备的基础设施服务，没有API gateway，UI端如何去获取数据呢，不可能在页面中写一个每一个服务的全路径（包括主机名端口号），因此UI的sever端就承担了API gateway的功能，我本人设计整个UI服务的时候也考虑到了这个一层，由此衍生出一个完整的api gateway，但是由于种种原因最后搁浅了。

在后端服务技术选型的时候，有的开发人员第一时间想到了nginx，首先，nginx可以作为一个简单门户网站的服务端，但是nginx不是用于复杂web端业务开发的，复杂的web应用是需要后端服务支撑的，尤其是涉及到双向通信问题，凡是用nginx作为一个（尤其是一个web single page）web应用服务端，基本都属于入门使用。

然后说一下UIweb端的设计选型，刚开始设计的时候，是考虑到很多因素，最后选择从零构建，主要原因是版权问题，angular2+，vue都有考虑，我初始内部版本使用的就是angular2+, 最后选择原始的js html css书写方式（并不是很原始，借助了jquery操作DOM，bootsrtap基础样式），主要刚开始UI的定位问题（仅仅是用于新手测试edgex功能），其次是为了edgex衍生出自己的组件库，现在看来为了妥协某些原因，包括妥协开发人员等原因，最后也搁浅了。

这里要提到，技术选型一定要考虑到开发人员水准，首先，这是一个开源项目，不是公司内部项目，考虑到社区贡献，而且项目开始之前，几乎是本人一个人开发，要说考虑到开发人员水准，只能是考虑到个人，人员越多，水准层次不齐，个别人不会，不代表社区中其他人不会，只写过业务逻辑的就不要表态了，不能因为迁就几个开发人员的水准能力问题，就去改变一个整体项目架构走向。

本人采用的技术选型，完全符合javascipt权威指南一书，书都没看过，只会调调别人的组件库，以个人视角就赖上技术选型，这个不够客观，还是要从自身找原因，再说了，第三方库太多了，他们也是用js书写的，只要有手册，会识字，都能调用。

其次，在二次重构技术选型中，不能因为百度看了一两遍angular2+的双向绑定模式，就要全盘否定了现有的模式，首先，我在重申一遍，内部版本的时候本人使用的就是angular2+书写，刚开始的edgex返回的数据结构多达九层，双向绑定一说不是那么简单使用的，最后舍弃原因上面有提到。angular2+是一个新诞生的web端开发模式，但是官方本身没有自己的组件库，首先考虑的是自己有能力开发完整的组件库吗？没有就要借助第三方，在没有angular2+开始之前，很多优秀的第三方库一样完成了web开发。

这里表态一下，我个人不反对angular2+的运用，我个人也是最早的使用angular2+的开发人员，angular2+是一个很好的web开发框架，但是绝对不是万能的，不调研清楚，看一两遍百度测试demo就决定一个项目技术选型，同样也没有考虑到开发人员水准，我举个列子，一个web页面，尤其是复杂的页面，有多个组件，一个组件就需要三个文件组成，多个组件之间通信，还要借助父组件通信，这种方式真的就让开发人员轻松了吗？而且最关键的时候，不借助第三方组件库，自己手动写一个组件，难度不比直接用js书写简单。

最后，本人多年项目管理经验和一线开发经验，对于技术选型绝对负责，但是这里要声明的是，没有哪一个第三方框架能解决所有问题，我也考虑用angular2+，没使用的原因前面基本上都有提到，但是一个项目，考虑的是开发，运维，稳定，可维护性等诸多原因，并不是一个开发人员随便写个小demo就决定整体项目走向，更不是随便百度资料看到某个功能能解决某一个小块问题就替换掉项目整体技术选型！

[badboy-huaqiao]

这里补充一下，根据edgex官方要求，UI会一点点接近产品版本，技术选型进行重构，个人从社区贡献code以及团队开发人员等方面考虑，进行投票技术选型，以方便社区中的开发人员都以一种熟悉的工具参与开发，可用方案如下： 1：go template 2：angular2+ 3：vue 4：react

投票希望客观公正，技术选型遵守以下准则： 1，具备基础web安全防护 2，强大的国际化功能 3，具备双向通信功能（注意不是双向绑定） 4，能够耦合edgex安全和非安全模式（即，通过kong和不通过kong两种方式都要支持） 5，丰富的第三方组件库，稳定，长期支持 6，第三方库license，遵循apache最佳 7，部署的便利性 8，要从零创建工程，第三方构建好的工程结构，涉及到版权问题，不方便使用

避免以下行为： 1，强烈的主管因素 2，推广个人公司产品 3，为了方便某小部分功能，丧失全局便捷性 4，个人推崇，比如我是angular帮派，我是vue帮派，我是java帮派，go帮派 5，个人因素，JavaScript个人学不会，个人电脑不支持等荒诞因素 6，第三方构建好的工程结构，涉及到版权问题，不方便使用