浏览 4126 次
|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-12-03
关注了一下zkj_beyond提到的这个项目：
http://www.theserverside.com/news/thread.tss?thread_id=37868 最大的亮点在于作者设计了比较优雅的JS对象，这些JS对象封装了基本的操作组件， 而这些组件的API设计都比较统一和基本匹配于java/c#的对象体系，这意味这在服务端用更好的对象封装这些JS对象成为可能。下面是开头很有意思的几个回贴： 引用 Posted by: Mileta Cekovic on December 02, 2005 in response to Message #192648 2 replies in this thread
This (JS widgets) library is the way to go for browser based applications. We need JS objects for widgets to be manipulated by client side JS code. But, we also need these widget components on the server side too, preferably with the similar object model. With similar I meen that at least the names and meaning of the properties, methods and events are the same. There are progreses on both sides (client and server) to provide decent component model, but we need unified one. That means server side component framework which renders JS objects instead of HTML, letting JS objects render HTML. And the object model for both must be similar at least (as described above). Yes, go for "server-side api" and "presentation engine".. Posted by: Marc Domenig on December 02, 2005 in response to Message #192673 1 replies in this thread I agree with Mileta. The "server-side" approach is preferable. Not only because of the object model api but also because it allows packing the shaky JS code into an application independent "presentation engine" such that you can write your apps in pure server-side Java. This approach is feasible with JS, Java, or Flash, as described in http://www.javalobby.org/articles/ajax-ria-overview/. You can find a concrete design solution in http://javadesktop.org/articles/canoo/index.html (based on Java, but also feasible in JS) 从作者的谈话中不难看到，很多人正在朝这方面努力，赫赫，不久的将来，必定会有这样的框架出现，而且也可以想象，一旦JS Objects-->server side Object model完成，意味着IDE对浏览器构架RIA成为可能，意味着拖动式开发RIA成为可能。 
声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2005-12-03
里面有个讨论很有意思，一个JSF的开发者说JSF正式作这样的框架，在服务端绘制各种基本组件。 然而，作者回贴说JSF并不是他们所讨论的东西，因为JSF直接绘制HTML，而他们的框架希望服务端绘制JS object model ,然后再让JS Object Model绘制HTML DOM .
原贴在这里： 引用 Posted by: Kito Mann on December 02, 2005 in response to Message #192693 1 replies in this thread
That's the benefit of JSF. A lot of JSF components are AJAX-enabled these days, and you still get a full component object model on the server. Otrix's WebStudio Enterprise, Oracle's ADF Faces, and JScape's WebGalielo components all include AJAX functionality (and will be including even more). Kito D. Mann Author, JSF in Action http://www.jsfcentral.com Posted by: Mileta Cekovic on December 02, 2005 in response to Message #192708 1 replies in this thread But we need JSF renderers that render JS objects, NOT HTML. JS objects themselves should render HTML (and have 'the same' object model as JSF components if possible). 这个讨论非常有意义，讨论的焦点就是在于服务端该怎么绘制界面。作者希望服务端能够直接绘制JS代码，是希望能够利用已经实现的成熟的JS 客户端基本组件来实现更好的RIA，这个理由我觉得还是很合理的，因为很多JS高手可以用JS代码写出比较优雅的客户端基本组件。 至于服务端绘制HTML代码，或许更直接一些，因为相比上一种而言，少了中间一个过渡，不过意味着很多已经成熟的JS客户组件框架不能再利用，而且因为少了服务端对象模型到客户端JS对象模型的匹配优势，所以使得客户端基本组件的设计从初版到用户满意将是一个漫长的过程。 |
| 返回顶楼 | |
|
发表时间：2005-12-06
cocoon 的 cform-ajax 就是这么做的.
cform-ajax使用很方便 但用cocoon的都是些骇客 没有开发可视的工具 和库. 不过最近好像开始重视起来了. 我个人也很喜欢手工写文件 但这样做确实缺乏效率. 我认为ajax 只是一个开始. xml 会逐步深入到所有角落 html css也会逐步被取缔 客户端是 ajax svg 等纯xml标准 开发框架也会逐步向xml框架靠拢 |
| 返回顶楼 | |
