|
锁定老帖子 主题：XMLHTTP和浏览器端表现技术的讨论
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-11-27
这点上面我想我们是一致的
只是我还没有找到如何在portlet里面获取reponse的方法 目前阶段也只有依靠web变量和服务器变量交互的方式完成认证的 可是这样做也很难杜绝弱权限提升的漏洞的，基本上是没有可能的 所以我的建议仍然是业务你还是老老实实的在服务器上完成的，不要 把接口放给客户端的 https不是问题的关键的，就算xmlhttp支持，reponsetxt也可以完整的拿到 你的数据，你和服务器的交互也还是要通过parameter来完成，别人还是看得 一清二楚的，不需要sniffer这种东西的，所以除了一些公用的查询或者是数据下发，以及一些web组件上，这个功能还是要慎用的 |
| 返回顶楼 | |
|
发表时间：2004-11-27
willmac 写道 所以我的建议仍然是业务你还是老老实实的在服务器上完成的，不要把接口放给客户端的。
要么是我没有完全理解你的含义，要么是你没有完全理解我的含义，两者必居其一。 我们当然是把业务放在服务器端做了，发到客户端的都是当时需要显示的数据。这里的关键是可靠的用户身份鉴别和杜绝身份伪装，而不是什么接口都不放开。分层清晰是非常重要的，现在我介绍的这种架构，仅仅是把表示层的逻辑放到客户端来做。业务层和持久层都完全放在服务器端来做，通过一个 Servlet 构成的 facade 来向客户端暴露访问的接口，完全不存在客户端提交一个"drop table xxx"就会引起服务器端某种操作的情况。那么你对安全性的某种担忧到底是什么呢？这种担忧究竟是一个普遍性的问题，还是 XMLHTTP 这个孽种所特有的问题呢？ |
| 返回顶楼 | |
|
发表时间：2004-11-27
我觉得， 即使使用XMLHTTP，业务逻辑必定也是需要在服务器上完成的，我想dlee也没有说他们的业务逻辑是用js完成的吧。
如果我们认同业务逻辑必须在服务器上完成这个前提，那么上面提到的安全性问题，XMLHTTP有的， http一样也有啊，那么http是怎样解决的，xmlhttp也差不多啊。 |
| 返回顶楼 | |
|
发表时间：2004-11-27
不是的，我只是提出大家在使用xmlhttp的过程中应该注意的问题的，不是反对这个框架或者技术的，你看我自己也用得不亦乐乎的，这个东西使得浏览器客户端成为可能的，可是他不够健壮，却有足够的简单的，在里面该写什么，不该写什么非常的重要，你要始终记得，你的每一部工作都是开放给用户的，这也只是我强调的。就像为什么我是用portlet的数据源而不是servlet的，就是因为安全的考虑的，用户的权利由portal去判定而不是由你的程序去判定
ps:我觉得我们之间不存在分歧，只是有了这个东西，浏览器更强大了，我们应该 注意怎么用好这个东西的 |
| 返回顶楼 | |
|
发表时间：2004-11-27
to willmac：
呵呵，我故意说话比较激烈是想让你多说一些啊。 其实 JS+XMLHTTP 只不过是最基本的技术。就象一把刀，能否把它用好，还是要看用刀的人是谁。我们可以总结出一些采用这种技术的最佳实践和设计模式。但是对于这类基本的技术谁好谁坏的争论真的是没有什么必要的。这类争论还有很多，例如：Java vs. C#。这类争论在各种论坛中总是会引起最多的关注，而且会引起很多人血压上升，气冲斗牛，但是对于论坛的发展其实是没有任何帮助的，所以最近 robbin 把 Java vs. .Net 的话题禁掉了。 |
| 返回顶楼 | |
|
发表时间：2004-12-01
JS做了很多,但对于XMLHTTP是刚开始接触.
大家对这方面似乎都很精通,不才想请教一个实际的问题. 我在后台使用dom4j解析xml,最后要传递给前台时,用document.asXML()做了个字符串转换,前台loadXML获得. 现在问题在于, 如果我的XML文件中包含中文的话,前台无法正确的识别它. 我把后台传来的字符串alert一下,发现默认的encoding是UTF-8. 我在后台手动将encoding设为GBK或是GB2312依然不行... 请问这个中文问题如何解决? 谢谢. |
| 返回顶楼 | |
|
发表时间：2004-12-01
response.setContentType("text/xml;charset=gb2312");
|
| 返回顶楼 | |
|
发表时间：2004-12-02
本来回答他了，可是这个人倒出乱贴有灌水嫌疑，然后我把答案删了
|
| 返回顶楼 | |
|
发表时间：2005-01-28
xmlhttp的技术是好的，但是js的编写调试我不知道采用什么工具比较好，都感觉不尽人意，总觉得浏览器（IE）好像不会自动释放资源，进行垃圾回收，内存一个劲的往上涨。Flex，比蜗牛还慢，在本机调试，还需要好几秒钟的初始化时间，放到公网上给别人浏览，还是算了吧。bindows也不是完美的东东，启动慢不说，还经常崩溃（也许我的IE有问题）。如果说仅仅是在企业内部，没有进入公网，applet也许是一个比js更好地解决方案，起码我认为对于java程序员开发来说效率更高，工作效率上来说，写js，可能大部分的程序员都会觉得枯燥无味。B/S真的有传说中的那么美好吗？浏览器端的技术，基本上都尝试过，让我兴奋的技术是xmlhttp，让我期待的是Flex，让我失望的是bindows。
|
| 返回顶楼 | |
|
发表时间：2005-11-28
swing 写道 哦，其实就是因为这样才想同你交流下嘛，因为我现在也是做的基本一样的东西，xmlhttp我是有了解过并研究过的，最终权衡再三感觉还是选择使用form好。
其实说起来，让用户绑定IE，我们确实是这样，而且要求版本必须一致，但是最近XP新打乐个补丁，结果导致JS不兼容，让我很头疼（其实也只是偶尔疼下，毕竟还没有潮水般的用户反馈过来），最怕就是这个乐。 js的优点很多，但是缺点也非常明显，希望有一种更好的面向对象的语言能够介入进来。 不过，让客户端尽量瘦些，也是目标之一，呵呵。 其实用户有要求过，不要做翻页的，一次把所有数据都拿到界面，本来我们40行左右分页，后来实在不行乐，没办法，就页面按1000行分页。其实用户的想法真的很简单，为什么要按一下按钮等待页面数据重新载入，而不是用滚动条。 但是很多事情我想还不是我们想象的这样的， 拿着锤子就满世界找钉子。 相对来说，我会喜欢有用就好，关键是达到目的， 另外问问JS的编辑器你有没有好用的？我找乐很多， 感觉都是差强人意，我公司界面方面的头子他也是 用editplus之类， 老实说，好的开发工具真的是会事半功倍，js这方面好缺感觉。 不懂了？ XMLHTTP和Form有啥相背的？，你的意思是用了XMLHTTP就不能用form了？ XMLHTTP和IE绑的紧？ XMLHTTP可以cross browser的呀！ |
| 返回顶楼 | |
