还是关于树，这回是个新问题：一个有上千个节点的树怎么做？

Question

学学MSDN，用延迟load节点的方法

Answer 1

什么意思？选中节点了再请求子节点的内容吗？延迟只怕太大，而且受限于网络状况，还不如我自己的服务器端stringbuffer解决方法呢。
我想要的是一个纯jscript解决方法。

Answer 2

try:
http://colorweb.go.163.com/CodeLib/XML/deeptree.htm

Answer 3

看来延迟load也不是不能考虑。谁能给我一份代码吗，自己再去写一个，觉得太重复劳动了。

Answer 4

我理论上知道，应该是用xmlhttp或者xmldom或者其他的数据控件在节点onclick时要求子节点的资料，动态插进当前的树里面。
不过自己不想从头做起，有段经典代码来改效率和代码质量要好一些。

Answer 5

给一个建议。
用延迟的方法固然做出来的比较好看，但是不一定长久。
我觉得没有必要用XML等很夸张的技术，只要一步一步来就行了。
比如第一层有20个节点，IE上就是20个，点击以后换页，如果还是20个，画面上就是20个父节点，加20个子节点。也就是说，每次画面仅仅打开一个儿子，或者一个孙子。这样，不要说1000个，哪怕上万，在IE里面载入和并不多，可能100都不到。
用各种新技术实现，将来维护起来可能麻烦，另外过多的JS会带来过多的Bug，还有浏览器的兼容性的问题。我的这个方法，Netscape或者任何低版本的浏览器都可以适用。
至于代码部分，这个方法自己写一下应该一下午差不多了。

Answer 6

我看你这种情况要重新考虑是不是把所有员工都放到树上去，把员工加到树上未必方便使用,能不能只把员工的上一级"部门"放到树上去，点某一部门节点的时候，有个列表显示该部门下员工的信息
-----------------------------------------------------------------
想想win的资源管理器，为什么文件不直接放到左边的导航树上做为节点？而只是把文件夹做为树上节点？

Answer 7

to： rosbicn(rosbicn），你的意思是每次页面都刷新,象linuxaid的论坛上的树一样？这当然也是个解决方法，不过我不怎么喜欢。其实那样做可能代码量差不多，而且每次都要装载新的页面，还一定要为这个页面开个框架。我一开始就没考虑过这中方式to： sunbeamy(阳光灿烂的深夜) 你说的对，我一开始就钻死胡同了，因为以前做的都是一次读完。用资源管理器的方式可能代码写出来更漂亮些。有时间了我会试试。to;all 其实我原来想问的是算法上能不能优化，因为把运算交到服务端让我有点不服气。不过现在想想，用延迟装载其实也许比我原来的解决方式要好。谁手头有代码的发挥一下互助精神嘛。孟斑竹呢？

Answer 8

emu同志，请你搞清楚，js只是脚本语言，是轻量级方法，是用来实现简单功能或者设计原型的。要更强大的功能和效率请用java、C++或者C#。当然事实上也不是不能用js，你可以把树分成许多部分，每次只把需要的loading进来。MSDN就是如此。但是不要跟你的机器开玩笑，把有成千上万的节点的xml读进来。

Answer 9

呵呵，我搞的很清楚，js比我们原来想象的要强大很多的，关键是要用得好。
我现在一般作列表的分页都不在服务器端做了。用js做的时候可以简单的实现分页、翻页、排序，可以控制每页显示几行，而且反应飞快，又减轻了服务器的负担。js里面的数组排序是快速排序法（我怎么知道的？我测试的结果是时间复杂度为1.3啦），排起来又快又好（当然对大量的对象排序的时候要用一点点小技巧来加速啦）。明明在客户端有那么多的计算资源可以利用，为什么要压死我的服务器呢？尤其是在局域网中的B/S应用。数据传输速度又快。

Answer 10

这是关于字符串累加的加速处理:
http://www.csdn.net/expert/topic/752/752688.xml?temp=.6397974
对你也许会有帮助。

Answer 11

这个讨论（字符串累加加速）本身是很好的。但是我认为这样有误导作用。javascript、jscript的标准本身并不定义具体实现，例如排序的算法，而你们所追求的技巧只是对于特定的javascript语言的实现（也许IE 5的js引擎是这样，但IE 4呢？Netscape呢？Opera呢？其他呢？）javascipt只是脚本语言，Netscape的设计文档讲得很清楚了。即使MS也清楚的说明javascript的用途有限（虽然在某些领域很有用），例如scriptlet只是轻量级的组件，或者用于快速原型设计。熟悉软件工程的人都知道，原型和最终产品的天壤之别。所以这些技巧充其量只是技巧。最后，尽管我们的机器越来越好，但是过度使用js还是会造成客户机的严重负担。而且，更重要的是，大量的在客户端进行逻辑计算，不利于贯彻MVC或者data-logic-style的三层分离的设计原则。我的看法是，浏览器的脚本应该只用来实现一些面向表现的功能。

Answer 12

这取决于你怎么定义“面向表现的功能”了。重新排序算吗？分页、翻页呢？我认为跟表现有关的逻辑运算都可以算表现层的事。三层结构中的逻辑层应该是业务处理的逻辑，把哪个数据和哪个数据进行怎样的处理后放到哪里去。把什么运算都往逻辑层上放，他的逻辑往往反而不那么清晰。再来说说效率问题。假设我现在从数据库查询出来500条记录，分页显示在页面上，同时提供安字段排序的功能，我们可以有哪些方法可以做这见事呢？1 在查询的时候orderby排序，limit分页，offset定位（SQLServer好像还不大支持，要用什么游标，屁烂M$，不如用免费的pgsql）。用户每动一下都重新select，改变一下条件，又把他们全部重新查出来一遍。用户少的时候时候这是最简洁的做法。代价是数据库的压力，逻辑层每次也要跑一遍，要算的东西不多，表现层每次都要生成新的页面，代价不算大，但是会有点延迟。2 一次查出来了放在逻辑层，由逻辑层来处理分页、排序。这样作的代价不只是计算上的，用户的session对象变的庞大，特别是多用户在线的时候，最好多加点内存，再设个巨无霸交换空间。（要是用application对象的话，技术上我想不出有多复杂，而且在什么时候释放它呢？）3 一次查出来了放在客户端，由jscript做分页和排序。这样做的坏处是：页面打开的延迟较长，所以只适合在局域网或者其他宽频网络上使用。客户端运算量？我测试过，不采用优化过的算法排序，1000条记录排了5秒钟，因为jscript访问对象内部的数据很慢。优化后只花了1秒，排序半秒，动态生成页面半秒（赛扬633，不算什么奢侈的机器）。客户端占用内存：一个记录算1k吧，1M的内存，比起浏览器本身浪费掉的，不算什么大数目。我觉得每种方法各有所长，要看应用的场合。在某些场合，用jscript还是有明显的优势的。

Answer 13

比较同意emu(ston) 的看法，jscript用的得当可以很好的减轻服务器的负担,如何适量是个关键问题，比如要查询10000条纪录，那么每500条由jscript取一次，我想比每页显示20条,次次都去服务器要好得多,就是说不能奢望jscript去处理10000条纪录，但可以有方法去改变这个状况，当然这确实仅仅是技巧，只适用于某些情况，不过不去思考是不对的。

Answer 14

再说一个情况，假如在局域网的OA系统里如果有几千个用户，往往是同时在线操作你的系统，如果大量运算在服务器的话，可想而知是什么结果，大型网站可以用很大型的服务器来做，但是局域网的OA系统一般是不会这样的,而且局域网的客户端机器一般是有一定标准的，不像互联网上机器那么多种多样，如果均衡考虑的话，这种情况利用客户端减少服务器消耗我觉得是挺必要的。

Answer 15

孟夫子用xml的方法也挺漂亮的，自动就装载进来了，但是我实在搞不清楚要怎么做。有一些xml通过地址访问不到（都是“/”打头的地址，一试图打开就出来个163的广告页面），访问得到的都保存下来了，在本地打开也不出来树。孟夫子多给点提示嘛。

Answer 16

Online Carpentry: Crafting a New MSDN Table of Contentshttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebgen/html/msdntoc.asphttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebgen/html/msdntoc2.asp