提一个JS+XMLHTTP开发的思路，大家看看是否可行

为什么就不能一次把数据全取过来呢？你点一次取一页数据不是很麻烦么？

那么玩了，你们俩个还在哦，

楼上的吃好了么？

这个问题我记得之前在那个帖子就提到过了吧。
一次把数据全取过来，一个是数据传输量的问题，
一个是客户端内存的问题。如果是成千上万条数据，
肯定吃不消，所以分页的支持肯定是需要的。

那你查询条件设置一下呀，几万条数据，界面的接受对象是人不是电脑

人好像是无法处理这么庞大的数据吧

如果用户不指明查询条件呢？

用户通常是不指明查询条件的，他们都有直接去点击查询按钮的冲动。如果不分页有时你会发现你的浏览器的下拉框中的下拉条变成细细的一根线了。当然这么壮观的景象还要你的电脑足够坚强才能看到。

分页很容易实现的，只要传两个整数pagesize 和pageno到服务器就行了，这两个整数我是从页面的＜select＞中取的。

用户不指明，但是界面可以限制呀，禁止这种操作的执行

当然我是说数据一次取出来并不代表不分页

dlee， 我告知一声， potian在最近的一个比较大的项目中位置是技术总监，而这个项目采用一个类似js+xmlhttp的框架。xml和js嘛， 他不但早就见识过，而且亲身经历过。 这点，gigix也是知道的。

   而且那个框架已经比较成熟了。

   potian在这个领域是有发言权的。
    

to weihello：
软件开发这个东西怎么说呢，我现在感觉是相当唯心的东西。以前我在这里参与的很多争论其实都是虚耗生命。如果确信一种开发方式可行，最好的方法是自己去写代码将其变为现实，然后解决遇到的一切困难（如果全部解决了就是牛人了，Gavin King 就是这么走过来的）。而不是跑到某个论坛去讨论，这样讨论结果往往是众说纷纭，最后很容易使自己丧失了方向。
有什么东西可以验证一个设计的可行性，唯有形成可以运行的代码才能验证。好在在这个领域我确实是做过以后才跑来说的。我们这些代码运行的很正常，我们非常依赖这些代码。你过来跟我说，根据某条 OOAD 原则，你的这些代码有可能在某日引起某些问题，我的感觉就和 gigix 那个电单车的比喻中是一样的。

我现在说的是 JS+XMLHTTP 是一种可行的设计，并不是说它是一种完美的设计（JS+XMLHTTP 只是基本的技术，还完全谈不上设计，不同的人用相同的技术都会有完全不同的设计）。我们现在用 JS 处理 HTML 非常顺手，开发效率也很高。potian 并没有完全否定这种开发方式。只能说在这个领域，我和一些朋友感到了满意，而 potian 感到了失望，仅此而已。potian 有空了可以把那个框架的设计拿出来讨论一下，可能很多人都会非常感兴趣的。

这种开发方式只是在目前完全抛弃 HTML 尚不成熟时的一种过渡方案。比 JSP 好一些（一些传统的 JSP+Taglib 很难实现的交互我们现在可以做了，软件的易用性得到了提高，用户感觉比较满意），但是并不是最终 Web 表示层的解决方案。我想你也是亲自带过项目的人，我的看法是我们现在最现实的还是利用好现有的技术来把产品做好。别人当然会有不同的看法，这个我是没有办法干涉的。

weihello,dlee，这个东西我可没有发言权，内部的很多细节我都是不了解的

我个人虽然不喜欢这种方式，但这种架构有时候甚至是唯一的选择，客户需要浏览器和方便易用的操作界面，你还能怎么样

dlee:weihello对采用hessian+Swing的richclient研究了很久，他们有一套产品是基于这个框架的。

我认为现在这些方法都还有很多问题（废话），但确实没有感觉哪一种方法更好或者更差。

这里很多人都在用js+xmlHTTP嘛，我们不要争论这种做法的好坏了，没多大的意义了。

有成熟项目的能不能谈谈具体的实现呢？如界面的逻辑设计等。

这种js+xmlＨＴＴＰ感觉跟随ｓｔｒｕｃｔｓ有点相似，都可以很好地限制开发人员的个人发挥。但是这种方式（ｊｓ＋ｘｍｌＨＴＴＰ）可能要求更强的表示层设计，有很多跟ｓｔｒｕｃｔｓ不同的地方，可以我不能很清楚地说出来，很多认识都是一个模糊的阶段。