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,留作以后再说。

解决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

深圳房子引发的关于人生选择的思考

此文也是有感而发,并不是每天都有感,也不是每次感之后都会发

想先说说引发思考的时代背景,我想可以这么描述,这是个2011年毕业参加工作,从毕业到如今的2015年,一直生活在深圳,一名专业的IT民工的感受。

说在前面,首先我是坚定的理性派,因为也算是受过高等教育,比较有主见,并自命不凡的一类青年吧,虽然价值观一直受到深圳房地产的洗礼,但始终不会动摇。。

什么是理论的价值观?努力,奋斗,付出,并得到回报,不一定绝对,但绝大多数更努力的人,得到了更好的回报,表现为财富就是,那些更有想法的,才智聪明,敢于拼搏,实践,坚持,始终忙碌,像蜜蜂一样辛勤工作,对社会贡献最大的人,会是财富最多的人。

然而现实的深圳,给年轻人的直观感受,并不是这样,像是一群暴发户聚集的地方,房子像是他们炫富,过双11,财产增值的唯一渠道,争相购买的商品,好像他们除了投资房地产,并不知道怎么用这个钱,因为没有文化,没有技术,没有经验,然而有的只有钱。所以传递出来的价值观就是,奋斗什么,胆子大点,给自己大的压力,早点买房,能少奋斗30年。这还是比较好听的解读。再粗点就是,纵观这10年,买房子的都富了,在工作岗位上专心上班的都落后了,而且落后了30年。好吧,财富和努力没有毛线关系。

影响?没有主见的人,或者不能坚持主见的人,都跟风买房去了,赚了的人,一心想着再怎么买一套,如何存钱,什么时机出手,没赚的人,背着大大的房子,紧巴巴的过自己的生活,不敢辞职,不敢断供,谈什么创业?谈什么理想?

跟风就对了?No,更错了,一个通俗的语言,兔子和鸟的故事,兔子说鸟真好,可以悠闲站在那,兔子也学它,结果没狼吃了。就是说事情都是因人而异的,不是土豪不要学土豪。

这么算账,如果土豪有4套房产,每套月租是4000,每个月不劳动就有16000,如果你是这样的人,那么再想着买套房子,每个月再还1W的月供就是正确且理智的。此所谓,房生房,富越富。

其实,面对现实我不悲哀,毕竟有知识的穷人还是多,像我一样的人还大量有,悲哀的是,有些有知识的人,在我工作上的领导,成功的典范们,一个个也告诉我,“早买房吧,我用10年的经验告诉我这个道理,当初和你一样,也认为会跌,结果越来越高”,一个大约2000年左右毕业的来深圳的名校大学毕业生这么给我说。

我相信,他的话是对的,是实践检验出来的。我只想说,时间还是有差,毕竟收入和房价比,差太多,实在没钱,就算知道是对的,也没用。

其实,没房的深圳人越来越不孤单了,大家基本都一样,家境一般的人毕竟在多数,就算你是名牌大学毕业,学霸,优秀,这些标签的人也不例外,说句不好听的,在深圳,穷的都是学习好的。高收入与财富没什么关系,因为差距太悬殊,你就算月薪2w,扣完税1.4w,就算算上年终奖,也其实不过是20~30w,面对动辄1000万的房价,有什么差别?可能有人想买个200~300w的房子,呵呵,在深圳,这种房子,要不然远到你不觉得是深圳(一般在40km吧),要不然破旧的你不忍心看。怎么说呢,如果是辛苦钱,这钱花的就不值!

好吧,吐槽归吐槽,我自岿然不动,我还是相信,看个人能力和对社会贡献的价值观,在未来,仍然会是深圳的主流价值观。其实就算哪天深圳真的变质了,也没什么好担心的,淡然的离开就好,美国都有金融危机,是人也都会犯错,更何况一个刚发展30多年的深圳呢?

当初来,也是看着这里压力相对其他一线城市比较小,环境还不错,才来的。因为我个人是这么一类人,觉得,压力小,才能专心生活,才能专心工作,不用整天担心房子房子,搬家搬家,户口户口。

路要自己走,每个人都是不一样的,家境,工作能力,性格以及所适应的工作环境氛围,不要去盲目模仿走别人的路。可以听一听,而且要多听,但要自己做决定。

还想说说德国和日本,这两个国家的民族,敬业,团队精神,一种工匠精神,的确是值得我们学习的地方。

压力要在工作上面找(意思是别在房子上找),压力大点,没关系,人还能保持一种高效的工作劲头。高中就开始引用钱钟书的“看庭前花开花落,望天上云卷云舒”表达的那种理想的心境,到了现实、社会、工作中是否还有能力、定力去保持?

我是个码农,技术自认为还不错,比较喜欢钻研。当年没有赶上移动互联网,遗憾,走的是农村包围城市路线,从传统行业逐渐的像这方面靠。虽然慢了一拍,可能错过了很多一飞冲天的机会,但发现走了远路看过一路上的风景也是种不错的体验,会对编程世界的底层基础了解的更清晰些,对现在的学习也是有帮助的。比如之前精通了Socket,现在再去学习HTTP,看上去是那么的简单透明,熟悉了HTTP,在去看什么WebService,RESTful就能简单了。

始终明白方向,始终知道该努力,就始终不会晚。中途可以休息,可以间断,甚至可以懈怠,但是绝对不能放弃。

面对频繁骤变的世界,我们为何要慌?我想不到理由。呵呵。

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

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

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

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

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

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

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

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

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

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

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

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

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