XMLHTTP和浏览器端表现技术的讨论

我也很怕这个问题，大部分机器没有问题，而有些却出问题了。
实施的时候，最怕这种问题，你在开发的时候可能没有发现这些问题。

B/S的好处是：集中维护，易部署。至于client端选择胖还是瘦，要看具体的应用架构。

一个在企业内部使用且交互性强的系统，胖客户端的设计是明智的选择。而一个用于信息发布的门户网站，客户端设计得偏瘦是可以理解的。

xmlhttp控件的出现，关键之处在于它提供了一个能同步与服务端数据交互的有效工具。（至于用不用刷新页面到是次要的，用隐藏的iframe也可以实现不用刷新主页面的交互，但它是异步的。而异步导致流程不能很好的被控制）

直接通过http渠道与服务端实现交互，使客户端的设计可以独立出来，不用理会服务端的具体实现，而直接面向数据层的协议而进行设计，从而提高客户端的重用性！
另外客户端可以设计成有状态的，而不是从前无状态的孤立的页面。从而减少b/s之间一些冗余的重复的交互。
关于OO是否必要，我的看法是这样的。OO模式与传统过程型的模式的好坏根本就用不着讨论。看看编程语言的发展史就一清二楚了。

用xmlhttp真得那么让人愉快么？
个人认为这个东西在产品化的过程中还要经历非常长的时间的
但就表现而言，肯定是不如flex之流的
我们先来看看它可以带给我们什么，首先不容置疑，采用这种方式，效率上
我们得到十足的满足，只需要写一个servlet就可以满足我们局部刷新的欲望了
而且这个servlet是如此的高效，只需要完成xml的编码工作就可以了，如果你够懒惰，甚至可以说让servlet直接写html吧，我只要在前台代码写上

<script>
.
var res = xml.responseText;
[id].innerText=res; 
</script>

xml的工作都省掉了，ok这就是我们所能够得到的，我们现在浏览器强大了，强大到和c一样了（你相信么？）我的天，竟然有这么多人要把这个当作主架构来使用的，现在我们开始讨论问题
1、界面的美工，我们提倡mvc的原因在哪里，谁在写dhtml，谁在写js的
   虽然js很简单的，可是谁在做这个工作的
2、安全问题，我们确实是省下了服务器变量的，所有的工作都可以交给web变量去完成的，但是当你在查询，验证的时候，有没有想过，你所作的可都是无状态的，所有查询借口都通过你的servlet或者是jsp暴露给用户，也就是你的servlet写得越通用，你死得越快的
3、调试问题，js这个东西太松散了，并且做出来的东西，丧失了跨平台性，老大
我们之所以强调b/s可不是为了浏览器客户端得好维护阿，他的本质原因是跨平台阿
4、同样是浏览器的c，谁可以告诉他比applet强大在哪里么？如果是超复杂功能
的话，webstart的兼容性是不是更好的，不过flex那个东西我不谈，他的普及率也太高了
ps:xmlhttp我现在也在用，而且用得很爽，可是我只是把他用在局部，都写成了
web控件的，替换起来比较方便的，美工哪个地方，我感触比较深，除了样式表
其他的东西都要自己搞定的，越有创意的设计，越要自己来的
始终觉得表现层的东西，无所谓主要架构的和什么什么技术的，这个和后台有明显区别的，就像画一幅图，你可以用photoshop也可以用画笔，who cares

我的感觉是, 稍微复杂一点的企业应用, 界面基本不会由美工来做, 美工能做的也就是配配色, 确定一下界面的整体效果, 以及提供一些图片罢了; 当然, 某些很厉害的除外


数据安全问题我记得以前讨论过, 我想不管是否基于XMLHTTP, 服务器对客户端来的请求总是需要进行安全验证的吧, 不过你是基于session还是基于什么方式; 难道, 普通的web应用就不需要对请求进行安全验证? 还是老大您使用XMLHTTP的时候从来不做验证...


不论是IE还是Mozilla都有工具进行js调试, Mozilla也支持XMLHTTP, 你不会认为js本身不能跨平台吧?


是啊, 如果是超复杂的功能, 我建议直接给个Application给用户安装得了; 为什么不用applet/webstart, 其一是jre并不是所有操作系统都默认安装的, 而且, 叫你只能写jdk1.1的applet你愿意吗? 就算你愿意, 我看也做到功能强大也难;

Javascript的强大, 很大一部分是它生存在浏览器这个Host里面, 可以很方便的使用浏览器的对象模型, 所以, 不要小看Javascript.

这个观点确实是说到了点子上了。

我不是想要强行推销什么东西。我也不做咨询工作，我只是专心做好自己的产品。别人是否采用与我们相同的技术，对于我的利益没有任何影响。其实 HTML+CSS 如果用好了，表现能力并不象某些人想象的那么弱（我甚至更愿意象孤魂一笑所说的使用 HTML+CSS 而不是 Swing，至少不需要重新编译，而且我确实觉得比 Swing 简单）。换句话说，某种技术能否用好，关键在于你有没有一种把工作真正做好的欲望。而很多时候，你是要在一种资源严重受限的情况下（例如：必须使用浏览器，必须使用 HTML）把工作做好。HTML 发展了这么多年，最终版本为 4.0，现在又进化到了 XHTML 1.1，可能在很长时间内不说是 Web 开发的唯一的主流技术，也是主流技术之一。难道 10 年来为 HTML 的发展贡献力量的这些人都是很愚蠢的人吗？

有人了解 XHTML 1.1 能做哪些事情吗？有空了我来讲一讲。

flex的WebService，HttpService和RemoteObject好像异步的说。

不可能的，它肯定象 XMLHTTP 一样同步和异步两种方式都支持。不信你自己去查一查。

应该是的，文档上这么说的，而且看它的一个例子samples --> explorer --> BlockingUIDemo.mxml，要把主线程block住还颇费了点劲。

呵呵
看来我们对xmlhttp的使用场合有分歧的
传统验证工作我们是在服务器上作的，使用的是服务器变量的，所谓的客户端是
瘦客户，有也仅有一个view,可是当xmlhttp诞生之后，使得我们有可能将以前
服务器所作的工作提到前台了，给浏览器的就是原始数据了，(浏览器不再像是受客户了，更像是客户端，强大与否，就看你的js的能力了阿)这个原来是客户看不到的，之所以讲他的安全级别不够，是因为传统我们给初到胖客户端的无论是
applet或者是webstart用户都很难进行分析，可是js就不一样了，就算是门外汉也会对你的业务逻辑进行分析的。而如果我们把所有的逻辑在教回给服务器的话，那么你使用xmlhttp还可以获得什么呢？这个东西的使用是分场合的，产品
化上作为主架构，我看欠妥的
顺便讲一个我的使用心得的供portal的开发者参考的，我不是使用servlet来充
当xmlhttp的数据源的，我们只需要在portlet的render接口里面实现数据的发放就可以了，前提是你的web容器要支持jsr168哦，一个技巧你可以同过velocity的模板和前台进行数据交互的，结果只有一个爽字，不过还是局部使用就好的，代码贴给你们看看的

public void render(RenderRequest request, RenderResponse response); throws PortletException,
			IOException {
		PortletSession pSes = request.getPortletSession();;
		String vmName = request.getParameter(PARAMVM);;
		String path = prefs.getValue("TemplatesPath", null);;
				VelocityContext ctx = new VelocityContext();;
		ctx.put(CTXREQUEST, request);;
		ctx.put(CTXRESPONSE, response);;
		ctx.put(CTXPORTLETNAME, pConfig.getPortletName();.toString(););;
		ctx.put(CTXVMUTIL, new VmUtil(););;
		ctx.put(CTXACTIIONLINK, new ActionLink(););;

		merge(vmName, ctx, request, response);;
	}

	protected void merge(String path, VelocityContext ctx, RenderRequest req, RenderResponse res);
			throws IOException, PortletException {
		PortletPreferences prefs = req.getPreferences();;
		String tpath = prefs.getValue("TemplatesPath", null);;
		try {
			Velocity.init();;
			Template template = Velocity.getTemplate(path, "UTF-8");;
			StringWriter sw = new StringWriter();;
			template.merge(ctx, sw);;
			res.getWriter();.print(sw.toString(););;

		} catch (ResourceNotFoundException e); {
			String p = tpath + "/errornofile.html";
			if (!path.equals(p);); {
				merge(p, ctx, req, res);;
			} else {
				res.getWriter();.print(path + "错误模板加载参数有错误");;
			}
		} catch (Exception e); {
			res.getWriter();.print("模板加载参数有错误");;
			throw new PortletException(e);;
		}

	}

这样无论你想引用的数据源是xml也好，html也好，web组件也好，用velocity的模板搞定，开发真的不要太爽了

XMLHTTP 在安全方面确实是有些缺陷的。WebService 已经有一些用户身份鉴别的机制，但是 XMLHTTP 完全没有，需要自己来建造，这对于没有能力自己做这件事的公司形成了巨大的应用 XMLHTTP 的门槛。我们现在是这样做的，用户登录后在服务器生成一个随机的 sessionid，用户的身份、组织机构、权限等等相关信息都保存在这个 session 中。sessionid 保存在浏览器的 Cookie 中。这个和 Servlet 的 sesion 很象，不过我们是自己维护了一个全局（所有的 WebApp 可见的）的 session 存储区。每次用户请求数据的时候我们都要根据这个 sessionid 判断用户是否已经登录以及相应的数据访问权限，还要验证用户机器的 IP 地址以避免身份伪装。

这个 sessionid 我们可以确保是真正随机的，没有什么规律，因此用户很难伪造。但是由于中间的信息是 XML 格式的明文，所以还是无法杜绝专业人士截取到数据包后加以伪造。更安全的当然是 HTTPS，最新的 XMLHTTP 是可以支持 HTTPS 的。

关于 XMLHTTP 的安全性，你还有什么意见？