`
李宏喜
  • 浏览: 119505 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论
文章列表
Ext.define("Component.controller.CommonController", { extend: 'Ext.app.Controller', refs:[ //搜索Form的ID需要是searchForm { ref : 'searchForm', selector: '#searchForm'} ], selectQueryCondition : function (comboxName) { var combobox = this.getSearc ...
    在重构时,抽取组件,在复用组件时,如果复用组件的地方,代码非常乱,直接复用组件,就特别容易产生方向性错误。如果还没有复用,建议首先整理或者重构这种混乱的代码。如果已经复用,那么特别容易产生错误,因为根基是比较混乱的,所以一旦产生错误,因为这种错误,是方向导致的错误,所以首先回退代码,保持对系统和结构的可控,也就是说,在重构时,要坚持正确的方法论。    事实上,这与版本产生错误,之后又回退版本的的机制是一样的。
这个时期,业余一直在看时间管理方面的书籍,这些天在回家的地铁里,我在读GTD《无压工作的艺术》,作者是戴维.艾伦。其中讲到了纵向管理项目计划的五个阶段。     作为程序员,似乎总免不了面临Block,面临压力,这本书第三章讲到:     为了:     控制某个项目     找出解决方案     确保行动切实可行     需要将精力聚焦某项活动上,做纵向管理。     我是程序员,深知自己的潜意识里,甚至是在逃避面临这样的问题,只是最近,我发现自己在潜移默化的改变。     在预计到开发进程中,在面临的困难时,自己对重点问题,重点局面,使用思维导图,在工作之余,做了预计划式的分析,有效地较少压 ...
周五,对一个模块的代码做重构,这部分的代码,是采用Ext4以MVC的方式实现的,在修改代码的过程中,经历了两个阶段,从混乱到清晰,而从混乱到清晰的转变的关键是静下心,思考一下,画出代码的结构草图,整个过程,我使用下面的一个草图来表达 1.混乱   从图的上半部,可以看到 A、B两个Panel中分别拥有属于自己的Record, 而A和B属于同一个命名空间,所有对于record的处理,特别命名时,出现混淆、逻辑不清的现象,越改越乱,这时候,我停了下来,静静地思考了一下!   对我自己说,我应该跳出来,上升到一个新的高度。于是在旁边的笔记本上,画出这张图的下半部。 2.清晰     2.1 ...
对于Ext4的树,与Ext.grid.Panel是属于同一个父类Ext.panel.Table,所有有树的有许多的基本特性可以参照Table和grid来学习,当然树也有自己的特性。如下图: 在树的动态加载,有如下配置: Tree的Store中需要的属性: autoLoad: true, ...
在使用Ext4的过程中,因为刚开始对Ext4,固有的技术特点不是很了解,在调试时,出现了 layout error,这样的布局错误,其它的提示信息很少,对与复杂的布局,要找到布局出现错误的地方,非常的困难。 在stackoverflow网站找到(后来在Ext设计权威指南中也看到过),Ext4,是有自己的布局调试工具的: 所以,我在html文件中,加入如下的引用: <script src="../ext-4.1.1a/src/diag/layout/Context.js"></script> <script src=&quo ...
调用端Ext的加载配置 Ext.Loader.setConfig({ enabled: true, paths : { 'CommonView.common.plugin' : '../common/plugin' } }); 在公用的命名域内,可以做action,event,logic等的处理,如下图: 在plugin中的controller文件夹中的CommonController中,可以定义如下的页面引用: refs : [ { ref : 'displa ...
loadFormData: function (modelPath, formName, centerpage, record) { Ext.ModelManager.getModel(modelPath).load(record.data.id, { failure:function (record, operation) { // console.log(operation); }, success:function (record, operatio ...
布局的合理利用: 如图: { xtype:'container', margins:'5 0 0 0', layout:{ align:'stretch', type:'hbox' }, ...
在Ext中,具有合计功能的grid,有时会出现小数位运算溢出的问题,可以在合计列上加入如下代码来解除问题: summaryType: 'sum', renderer: function(val) { return Ext.util.Format.round(val, 6); }, ..... 校验时也可以使用函数Ext.util.Format.round 下面的两个函数,我认为在计算合计时,比较有用的: Ext.util.Format.round(value, precision) 四舍五入 Ext.util.F ...
   在软件开发中,有时候,会碰到一些“灾难”, 例如:    1. 本地最新的版本突然间不能启动,也没有具体的错误显示出来。而周围的程序猿们都在很努力的工作中,进度的压力随之而来。    2. 本地的运行环境突然间,连不上数据库,但是配置文件等一切正常,后台编译也一切正常,网络也能ping通, 还有一些其它的莫明的错误,突然间出现!    怎么办?    是沿着版本线继续鲁莽前进,还是冷静思考,另找出路?    回退!             本地部署稳定版本,在功能分支上小心的调试通过!       总之,良好的版本意识,将在开发的进程中,给开发者提供良 ...
最近,碰到一个问题,在不同的模块间产生了强的依赖,导致模块A的数据执行完毕之后,在模块B,C无法找到模块A的数据,而模块B和C属于同一类型的业务数据,如下图所示: 当业务 A 调用 UNION_DATA_FLOW时,同时也会调用逻辑B和逻辑C,这时逻辑B和逻辑C对于业务A就是冗余逻辑 当业务B或C调用UNION_DATA_FLOW时,同时也会调用逻辑A,这时逻辑A相对于业务B和C就是冗余逻辑 这时,业务A和业务B、C之间就产生强依赖,并且容易导致业务A与业务B、C之间的数据丢失 可以看到union_data_flow所包含的逻辑A、B、C,分别有它们特有的实现目的,它们分别对业务A、B、C ...
    在A,B,C三个类中的不同的方法method中分布有重复逻辑,如果需要新增业务。不消除重复逻辑,只是简单地通过复制,粘贴的方式来实现新增的业务,重复逻辑会继续增加,会造成不必要的复杂度。如下图:                  抽取出重复逻辑,形成一个新的数组组件LogicHandler,如果需要使用就可以通过注入的方式,以关联的形式,来使用逻辑。    如下图所示:           谢谢大师Martin Fowler的知识给予我的灵感!呵呵...    
   在平时的开发中,我们总是习惯于使用过程化的思维方式来编写代码,没有通过开发高内聚的方法,来结构化自己的思维,从而消除逻辑重复,逻辑复用不仅仅是指在一个平面内的逻辑复用,更应该是一种结构化的逻辑复用。下面,我用平时开发过程中一个重构的过程,来做一个描述。    假设,现在有三个类,如下图所示:    在这三个class中,分别有三个重复的属性:a, b, c, 而且这三个属性具有相关性,对应于一个功能的具体实现, 而这个具体实现,分别分布在了三个不同的业务中。首先,从这三个不同业务实现类中,抽取出一个基类。需要说明的是对于spring这样的使用注解方式,来注入依赖关系的,基类注解的 ...

逻辑的线索

      读过Kent Beck 的《实现模式》,书中有一段提到,当山鹰,看到雪线的时候,就知道山上的雪开始融化了,可以到融雪形成的溪水中,去捕食溪水中鱼了。这是线索的一种很形象的说明。因为山鹰看到了雪线,就能够推理到可以去溪流中去捕食鱼了,这也是一种逻辑的推理。 同样,在《暗时间》这本书中也提到了记忆线索和记忆编码。在我们的开发工作,经常会碰到逻辑的块,那么可以根据 线索迅速地找到逻辑。在读《实现模式》的时候,总是会想到“联想”这个词,根据线索迅速地建立自己的联想。这也是一种场景。       Kent Beck 在书中也提到,根据地球自转和速率,可以推理到下一个时刻的具体位置。       ...
Global site tag (gtag.js) - Google Analytics