精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2004-11-13
根据这个思路,我们可以这样做。在页面中: <script src="AdminUser.jse"></script> 服务器的 web.xml 设置 *.jse mapping 到一个Servlet, 例如 JsMappingHandler,这个Servlet首先读 取配置文件,配置文件大概是这样的: <mapping> <class name="AdminUser"> <interface>a.b.c.domain.IUser</interface> <implement>a.b.c.domain.UserImpl</implement> </class> <class name="AnothorClass"> ... </class> </mapping> 其中 IUser 可以这样: public interface IUser { public String getName();; public void setName(String name);; public void store();; } 然后根据请求("AdminUser"),以及对应的接口(a.b.c.domain.IUser),动态生成相应的JavaScript 代码并输出。例如输出类似这样的代码 function User() { } User.prototype.setName = function(name) { Delegate.invoke(setName, name); } User.prototype.getName = function() { return Delegate.invoke(getName); } User.prototype.store = function() { Delegate.invoke(store); } 其中Delegate也是动态生成的,它根据调用的方法,生成XML,然后通过XMLHTTP提交到服务器的Servlet ,例如客户端调用 setName("Bin") 时生成这样的XML <class name="AdminUser"> <method invoke="setName"> <arg>Bin</arg> </method> </class> 服务器端Servlet收到XML后,解析XML,根据配置文件,实例化 a.b.c.domain.UserImpl ,并调用其 setName() 方法。 其它: 1。JsMappingHandler 可以把输出的JS代码缓存起来,提高性能,当配置文件改变后就清空缓存。 2。代码生成的JS对象,每次调用方法都要进行一次HTTP请求,感觉比较耗资源。 我的想法考虑还有很多不足之处,希望各位谈谈看法。另外我并不太懂得JS,上述有何错误之处,请指正,谢谢。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2004-11-13
这样做肯定是可以的。但是我感觉你没有搞清楚我所提到的 JS+XMLHTTP+Spring+Hibernate 这样一种架构中 JS 所扮演的角色。JS 在这样一种架构中应该严格地只做与显示有关的工作。就是说 JS 所做的事情就是通过 XMLHTTP 从服务器请求数据,然后以适当的方式呈现在页面上面。JS 所操作的就是 HTML DOM、XML DOM 这些东西。这种动态生成 JS 的开发方式我认为增加的开发的复杂度,我更愿意直接写 JS,而不是采用这种略微有些别扭的开发方式。这种开发方式所带来的灵活性的好处我并没有明显地感觉出来,可能无法抵消它所带来的复杂性。动态生成简单的 JS(例如象这样只有一些简单的 set/get 方法)是可以的,但是动态生成复杂的 JS 这样做就有些不顺手了。
把表示逻辑完全放到浏览器端来做,其实表示层的开发模式与以前相比有了非常大的改变,这种新的开发模式需要换一种思路来考虑。我感觉你现在的思路还是以服务器为中心的。其实我自从 3 月份以来在这里说了这么多关于 JS+XMLHTTP 的事情,感觉还是有很多人不理解这种开发方式到底是怎么回事。其实我们的思路就是表示层开发是要和显示设备直接打交道的,完全在服务器端做开发无法解决好表示层的问题(MVC 可以解决表示逻辑/业务逻辑分离的问题,但是还有另外一个同样重要的提高页面表现能力的问题)。现在我们做 B/S 开发的显示设备就是浏览器,显示设备所用到显示技术是 HTML+CSS,完全基于服务器端的技术(例如 JSP、Taglib)无法充分利用好 HTML+CSS 的能力,现在所有这些编程技术中 JS 与 HTML+CSS 结合的是最紧密的。在 XMLHTTP 没有出现之前,我们只能依靠基于 Form 的请求/相应模式来做 B/S 开发,因此我们不得不依赖服务器端的脚本技术(ASP、PHP、JSP、etc.),自从有了 XMLHTTP 以后,JS 就可以主动与服务器进行交互,自主决定页面呈现的形式,因此完全基于 JS 来做表示层开发就成为了可能。而且这种新的架构其实和 WebService 的架构是相同的,我认为代表了一种 B/S 开发更先进的架构。 Arbow 写道 1。JsMappingHandler 可以把输出的JS代码缓存起来,提高性能,当配置文件改变后就清空缓存。
2。代码生成的JS对象,每次调用方法都要进行一次HTTP请求,感觉比较耗资源。 1、JS 代码只要没有发生改变,浏览器是会做缓存的,不需要服务器端再做缓存。 2、没有什么证据证明 HTTP 请求就一定会耗费大量的资源。尤其是你在只传递需要显示的数据的时候。一个页面中需要显示的数据很多吗?其实大部分情况下是不多的(尤其是在你们实现了后台分页/缓存以后),多了也不过只有几 K 的数据量。 总之我的想法是大家最好不要主观臆测,自己去试一下并不会花费很大的力气。既然有人说源代码=设计,那么我们多写些代码总是有好处的。 |
|
返回顶楼 | |
发表时间:2004-11-13
引用 我所提到的 JS+XMLHTTP+Spring+Hibernate 这样一种架构
说说你这套架构是如何整合和运作的,如何? 引用 自从有了 XMLHTTP 以后,JS 就可以主动与服务器进行交互,自主决定页面呈现的形式。因此完全基于 JS 来做表示层开发就成为了可能。 potian 写道 据我的观察,这种方式在数据交互较少的情况以及用户并发行不高时可以使用。但是数据量一大,相应的XML标签占有很大的百分比,传输的效率就非常低,从 JavaScript界面构造XML的过程相当长,并且都是难以测试的代码,服务端计算负载也大大提高,每次都需要解析XML成为实际的业务对象或SQL 语句。返回结果也是XML,用Script去解析这个返回结果困难多多,所以决大多数情况下就是一个成功了、失败了之类的提示。用户提交以后等了半天,最后就是一个提交失败、请重试之类的话。本来想改进易用性,结果适得其反。
引用 而且这种新的架构其实和 WebService 的架构是相同的,我认为是一种更先进的架构。
为什么和WebService架构相同呢? |
|
返回顶楼 | |
发表时间:2004-11-13
potian 的观点只是相对的,而不是绝对的。而且这种开发方式他也完全没有试验过,我不认为他在这方面有很大的发言权。我们现在用 JS 做开发其实比以前我用过的 JSP+MVC 要顺手得多。
robbin,我说了这么多,你有过一点点尝试的欲望吗?你若不愿意尝试,我说的再多对你会有帮助吗?我来这里的目的其实也不过只是为了和同样有经验的人进行交流啊。 robbin 写道 为什么和WebService架构相同呢?
现在这样的架构做开发,服务器端的角色转换为了单纯的服务提供者的角色,所提供的服务就是为客户端提供需要显示的数据,所以我说和 WebService 的架构是相同的。请明确地说出你不以为然的理由,以便对我也有帮助。 |
|
返回顶楼 | |
发表时间:2004-11-13
等你们的开源JS+XMLHTTP的框架做出来以后,我非常有兴趣尝试。
|
|
返回顶楼 | |
发表时间:2004-11-13
to robbin:
别光盯着我啊,兄弟。问问 femto,看看他有没有什么进展。如果说做开源软件的动机很多时候是搔到了痒处的话那也是 femto 觉得痒啊,我们现在已经不觉得痒了。 |
|
返回顶楼 | |
发表时间:2004-11-13
不要急阿不要急,因为是业余时间做,所以不会那么快。最近正在研究七七八八的东东呢:)
有没有谁研究过XUL?交流一下~ 其实不管我痒阿,Quake,曹晓刚,庄标伟他们不是也很希望做出 一个xmlhttp框架么 |
|
返回顶楼 | |
发表时间:2004-11-13
to femto:
其实不管采用什么技术,只要能够以更容易的方式实现更好的界面和交互,对于表示层开发人员就是有价值的。现在有几种技术可以选择: 1、JS+XMLHTTP 2、XUL+JS 3、Flex+XML 4、XAML+C# 在这几种技术中间,目前可以做到跨平台的是 1、3,但是 gigix 说过 Flex 要搭配 MM 的服务器才能使用(是否确实是这样,Readonly 也来说说)。那么实际上现在各种浏览器中支持度最广的只有 1。如果完全不考虑 Mozilla/FireFox(我现在已经接近于同意这其实也是一种可行的策略),4 也是可行的,但是 4 能否采用 Java 当作服务器我现在还有很大的疑虑(请支持者举些例子或者给些资源链接)。虽然我这么多年来坚持不懈地宣传 Mozilla/FireFox 的优点,但是 2 对于商业软件公司,采用的可能性确实是最小的。 femto,你要动一动,先做一个简单的东西出来(就是先把对 XMLHTTP 封装、打包解包的那部分代码实现了),然后我才能帮的上忙啊。 |
|
返回顶楼 | |
发表时间:2004-11-13
呵呵,我是关注ing,希望有人早点做出来,femto要加油呀:)
|
|
返回顶楼 | |
发表时间:2004-11-13
femto,对于这样一个架构,安全性也是非常重要的考虑因素。因为现在表示逻辑完全移到浏览器端来做,所以安全性更需要受到重视。
我的建议是采用 Cookie 来实现,在服务器端实现一个全局可见(跨 WebApp)的 session 缓存区,每次用户登录了以后,给他分配一个随机生成的 session id,保存在浏览器的 Cookie 中,具体的用户登录信息(用户id、角色id、组织机构、权限、etc.)保存在服务器端的 session 中。然后对每次浏览器发来的请求进行验证,确实正常登录了才把数据发过去。如何有效地防止身份伪装是一个需要提前解决的问题。 因为 Web 容器的 ClassLoader 的体系结构,这样一个 session 缓存区必须要由 Web 容器本身来启动,这样所有的 WebApp 才能看到。如果用一个 WebApp 来创建,这些信息对于其它的 WebApp 就是不可见的了。我们其实修改了 Jetty 的启动代码,在 Jetty 启动的时候就把我们自己的很多服务同时启动起来,否则是难以解决这个问题的。这些对于我们来说也根本就不算是什么了不起的商业机密了。 |
|
返回顶楼 | |