本周巨痛感冒中，基本上没有任何药可以医治，只有我自身产生更强的抗体。。。
Jquery 控件使用：
老板要求用一个Jquery控件，将树形将组织结构（具体不能说，签了保密协议滴。。。）信息显示出来，而且要延迟加载（当节点被展开时，才从后台查询数据），还要有CheckBox的标准功能（即，选中子节点，必须影响父节点的选中状态；选中父节点点，能够应用到所有子节点），虽然阅读过Jquery的一些书籍，但是，本人很负责地说，ca ，从来没有用过。。。属于半理论主义者！
在网上找到一组ztree的控件，由于是第一次，不知从何下手，于是决定将这个使用的过程记录下来，相信将这个过程“重构”的话，肯定有收获！！！
一.找资料跳过，开工前准备
阅读ztree Demo，了解ztree 中大致有什么样的功能。并熟悉基本信息的配置（附：多说两句，熟悉基本信息配置，主要指API基础信息配置，比如ztree中的var setting；每一种Jquery TreeView都可能有自己的API结构，使用的方式不同，一句话，就是知道怎么用）。
二.具体过程
找到自己需要的功能，将Demo上的代码拷贝，确保能够模仿成功。
功能1）CheckBox：这个还算顺利，基本上设置一下就搞定。
功能2）而分批异步加载大数据量（即延迟加载）就悲剧了（主要因为比新手还新手）。
问题：怎样传递请求到后台，async: {
enable: true,
url: “some.php”
}
Demo中给出的是php，我用asp.net不会，差点疯了
后来一个同事告诉我用“一般处理程序”；果然这样可以解决
功能3）接着在Handler（一般处理程序）中写了一大堆的后台代码，主要是写树形结构的查询，本来是不难写的，但数据库文档基本为0，所以费了好大时间才知道需要什么样的字段。这里用了N多时间。
总结这个过程：基本上这是一个“白老鼠”的工作过程，浪费了太多时间。根本原因是对JS不熟悉，这个应当总结。当然，学会了JS的调试，debugger关键字；学会了使用handler接受ajax请求处理。
理想化过程：1获取Jquery控件资料，包括Demo，API，源码 ==》 2查看Demo，寻找自己所需要的功能集合，确保能够出现 ==》 3通过Demo 中的页面源码并结合API将所有需求功能组合在一起 ==》 4提供后台数据 ==》 5一个个地测试功能。
耗时异常处理（指处理得不好，将浪费时间）
1不能浪费时间查看过多的API细节，坚信一句话，很多知识是在“运行时”学到的，如果不用的话，很难理解透彻的，至少我是这样的；
2查看全部Demo的源码浪费时间，不能追求全部，只有能够达到目标即可，因为很多东西看起来不够完美，但是却能正常工作working well；
3组合时要对照API描述，这里不提倡一个功能一个功能地测试，因为往往组装（集成）还有后续的测试，当然要做好注释，这样确保一眼能够看清属于哪个功能，不然很可能会运行页面Nn次。。。我就是这样干的，人才啊；
4如果有现成的后台数据，则不用写；如果没有，最好思维转移，将后台数据处理代码写得尽量好，不能随便写点来测试，不然，悲剧的是，将一遍一遍“重写”后台代码，我还是这样干的。。。；
5 用JS断点+debugger测试，这样确保能够按照自己的期望运行，这里没有新的体会。
思想体会：我国的大学中，我没有学到Lambda演算，函数式编程，这次用Jquery，体会到了，Lambda如此强大，类似的，匿名方法+委托，Linq中都有变种，或者是实现。
以上过程用了2天（自己加班），新手嘛，加班属于自己的兴趣。
第三天主要实现一个功能：查询当前部分下的所有人员信息，包括子部门的人员信息。即需要递归地查询。
前两天的劳累，第三天有点懒散了，做事也比较慢。
由于查询时通过WCF远程操作，而有没有对应的数据库文档，悲剧啊。。。就对应客户端协定（Contract）函数看，一个个地找，试图找到类似GetAllPersonInDeptAndSubDept()的签名，眼睛都快吊出来了，结果只看到一个 GetPersonsInDept（），没办法了，递归吧，写好递归函数之后，出现了两个牛逼的错误。。。
- 传入DataTable 保存每一个人员的信息，我大致是这样操作的，
Foreach(DataRow item in ds.Table[0])
{
dtRet.Rows.Add(item);
}
死活提示“。。。已属于另一个表”，ca，网上一搜，才知道，需要用ImportDataRow方法，不能用Add。（解释一下，前提是我想在一个空的DataTable中插入相同列的DataRow，而不用初始化DataTable列结构，如果初始化了DataTable的列结构，是可以用Add的）
在结合百度知道的代码， DataTable dt= datarows[0].Table.Clone(); for { dt.ImportDataRow(datarows[i]); }才搞定。于是，开始思考微软是否做得不够好（YY一下！） 一句话，先获取DataRow的表架构（Table Schema）信息，然后一条条导入ImportDatRow。
2.这个错误，我好想哭，但是明白了之后，又很火，最后觉得自己傻。
调用递归获取人员信息函数GetPersonInDepts（nodeId）之后，一直在等待，最后爆了。。。栈溢出，一次运行大概2分钟，很漫长的一个过程，同行肯定了解2分钟是一个超级长的时间，我果断不用单步调试
（当年做ZOJ 1002还是1004，我对着递归函数调试了50次出栈，最后没看懂，后来花了很多时间明白了递归的原理，以后凡是遇到递归函数，绝对不调试），
采用看数据，然后一条条数据出现的时候，我哭了，如：
查询编号为001 的第一条数据居然是本身001，这是死递归（由于采用的是前序遍历方式）啊。。。。。。这谁设计的，这谁公开的协定，真的好火。。。然后加一个if就AC了。
总结：
1.如果程序逻辑正确，却出现了知识领域中莫名的异常，最好在网上找到答案，并稍作记录；
2.如果先看一下数据，就不会产生如此多的 StackOverFlow，所以，写程序，不只是要求能够写好代码，得出结构，而这其中的写程序的流程策略也是非常重要的。
第四天，以为又要加班了，但是比较轻松，就写了一份文档，不，是改了一份文档。
但是还是认真地做了，Joel（《软件随想录》的作者）说了，写作能力很重要，一个好的程序员更需要好的沟通能力与写作能力。
由于星期五还没到来，明天再写。
Thursday, August 16, 2012