月份：2015年11月

分类
SAPUI5

SAPUI5中关于Route的配置介绍

        SAPUI5要实现页面的跳转，则需要借助Route实现。之所以想要写关于Route的配置的文章，是因为该组件的配置项比较抽象难懂。在我第一次接触的时候，就有很多疑惑，API简绍的也不够详细，后来随着学习的深入，发现SAPUI5有一个极佳的例子，专门讲述Route的用法，SAPUI5 SDK 里面Demo Kit里面有Dev Guide，其中Tutorial章节有个navigate的练习，专门讲述的Route相关的内容。

        Route主要有以下几个配置项，3个方面：

        第一个是Route类的配置。刚开始不理解的是，既然SAPUI5提供了标准的Route组件，为什么还要显示配置Route的classpath？因为标准的Route功能可能不全面，需要自己扩展，封装常用的Getter Setter方法，经常见到封装一个成MyRoute来使用的用法。

        第二个是routes的配置。routes是一个JSON数组类型配置项，里面的Item包含三个属性，pattern，name，和target，这里就有点要强调说明的了，这里的pattern属性，其实可以理解为显示在浏览器地址栏的URL，主要是为了实现在地址栏的可见，以及通过浏览器地址栏就可唯一定义到一个View。name是routes item的名字，主要是用于Route的调用navTo接口是，唯一标识一个route item，可以理解为route item的ID。容易混淆的是，有些人可能会问，Path属性和Name会不会有点重复，一般URL也能唯一标识一个View，其实的确，简单的规则的情况下，可以直接用pattern来作为ID，但有了name，pattern URL中就可以包含动态内容，参数化，这是主要目的。第三个属性是target，target即代表一个View（也可以是多个，多个情况一般是一个fregment作用view，比如top和content），确切的讲，是target的Item，target Item里面会定义View的classpath。

        第三个是targets配置。targets是JSON Object，key是target的ID，value是一个target item，其中包含，viewName，即view的classpath。  

       此外，还有些更高级的配置项没有讲到，比如target的viewLevel，transition，viewPath，controllerId,controllerAggression，留作以后再说。

分类
SAPUI5

解决HCP中Fiori Application工程odata service数据不加载问题

        最近在集中研究HANA Cloud Platform，简称（HCP），在使用HCP的SAP WebIDE开发SAPUI5 HTML5应用程序时，遇到过两次odata service数据不加载的问题。简言之就是odata service配置了，但是运行程序的时候现实没有数据。

        问题的答案很简单，前提是要对WebIDE中SAPUI5工程的配置文件有一定的了解，由于HCP本身就是比较新的东西，大部分人都没有接触过，还处于探索阶段，我作为先行者，在此把我的成果分享给大家。

对于SAPUI5开发者来说，SAPUI5的工程可能都比较熟悉，一般需要一个sap-ui-core.js，以及一个web环境就够了，但是WebIDE集成了一些便利开发的工具，比如，预览功能，使用mock data调试的功能，自动部署，或者自动打包的功能，也正是为了实现这些功能，WebIDE上面的SAPUI5工程也多了些额外的配置文件。

        主要有这几个：neo-app.json，.user.project.json，.project.json。

        neo-app.json里面定义了该工程会访问哪些destination,即前端程序要消费的odata service，以及index.html的位置。注意：该文件也是会导致odata service数据不加载的问题之一。表现为明明在app descriptor配置了，destination也在cockpit里面配置了，运行时报404。在cockpit的html5应用里面可以看到，destination的地方时缺失的。

        .user.project.json，该文件内容比较直白，类似ecplise里面的run configuration，定义了run功能如何去执行，用哪个index.html作为入口。

        .project.json，这个配置文件内容就比较多了，会包含工程相关的配置信息，包括参数，比如工程类型，版本，语言，mock data信息，如果是开发mobile手机程序，则还包括mobile service server地址等信息，使用了cordova那些硬件接口等信息。

        所以，第一点，neo-app.json中，要有destination的配置。

        其次，第二点，application descriptor里面（即manifest.json文件）要写对odata service model的url，是从/destinations/xxx_destnation/xxx_service_url.svc的/destinations根开始写起的，还要有destination的名字xxx_destination，最后才是odata service具体的url。

        然后就大功告成了。只要是通过ComponentContainer方式加载的SAPUI5应用，只要配置在app descriptor里面的model，就会自动的调用this.setModel(xxxModel, "xxxModelNameSpace")，不用再手动加载了，只需要再界面上进行绑定即可。

效果如下图所示：

Screen Shot 2015-11-20 at 2.58.13 AM.png

        最后，再值得一提的是和mock data的区别，mock data的方式是不需要连接后台的，只需要有service 的$metadata即可，即service的描述元数据，mock server 会根据描述数据自动生成假数据，一般的规则是属性名称+数字，比如，假如属性名是name，第一个item就是name1，第二个就是name2，依次类推，直到第N个就是nameN。反之，如果看到界面上的数据是1、2、3排列的，那就说明一定是用mock data方式在运行。

效果如下图所示：

Screen Shot 2015-11-20 at 2.58.17 AM.png

分类
Coding Experience

今天学了点SAP EP系统Web Dynpro工程的迁移

        这两天在本地出差，一个客户系统升级代码迁移过程出了点问题，请了位我司的专家来指导，我跟着来学习。避免遗忘，仅此记录一下。

        迁移是有指导手册的，说的也比较详细了，但现实情况往往更复杂，一般人照着弄，很容易出错。怎么说呢，虽然感觉我不会出那些个错，但毕竟我不是当局者（迷），而是旁观者（清）。归类错误，可分为以下几类：

  1. 没有一个好的例子做参照，不能做对比试验。对于一个陌生的且庞杂的系统，通常应该先基于一个运行良好的基础版本进行改动，而且改动幅度不能太大，一点点的改，遇到错误了，一点点回退，试也能试出来，改了哪导致不行的。该客户的情况是。。。代码管理出了问题，升级前的代码就不work，更何况升级后呢。

  2. 别一下子猜2步。发现客户的开发特别逗，喜欢猜，并且基于自己猜测的结果为前提，又开始第二步猜测，然而第二步猜测往往诡异而奇怪，比如，我看到错误提示日志里面我的模块名的前缀和我定义的不一样，我看到工程属性这个地方有显示，和日志里面的一样，感觉是改这里，但是！这里为什么编辑不了呢？好奇怪。。。我也觉得好奇怪，怎么能往这个方向猜呢。。。最后问题解决了，真正原因是有些更基础的基础包没有迁移。。。

  3. 没有理清原理就开始干，干一点，算一点。怎么说呢，就算我没用过SAP的产品，我用过Java，至少知道jar包之间是有依赖关系的，最底层的包要先部署，要先搞对。否则先搞上层的没有意义。Java里面有maven或gradle，专门解决这个问题。

        下面说说技术相关的经验：

  1. 越是奇怪的问题，导因往往越简单，简单到甚至是可能某个文件没有访问权限。。。

  2. 有顺序，或者依赖关系的事情，千万要按照步骤来，否则出了错都没意义，比如迁移过程，有些东西就要先做，有些后做，别存在侥幸心理，认为只是换了个顺序。

  3. 站在程序的角度想想，就好比让你做这个迁移工具，每一步需要知道什么信息，你是否提供了？否则不可能无中生有，巧妇难为无米之炊。

        综上，其实迁移这个过程可以这么理解，由于JDK版本升级了，以及部分产品接口模块重构了，所以导致旧的代码直接用不了，所以需要迁移，并且有些改动，已经不是工具能自动化完成了。然而Web Dynpro不仅仅是源码，而且还有生成的代码，所以要这么干：

        先把生成的代码清理掉，然后导入到新的工作空间，IDE会自动识别出旧版本的工程，并且提供了迁移按钮，有初始化向导，自动完成迁移，主要是工程配置文件的变更，先搬进新的工程，然后在新的工程下，代码会有错误，首先就是该JDK版本，其次按照指导手册里面的对应关系表，把新旧类改成新类名，等没错了，然后再编译生成新的代码，最后再部署到新系统。完成。

        我喜欢程序的思维，因为程序的思维缜密，有逻辑，而且不会偷懒，不会骗人，让人觉得放心，踏实。