浏览 2718 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-06-10
感觉好处是,客户端表现层可以灵活的扩展和重用,比如可以把分页,过滤,excel导出等等常用功能封装成自己的grid,然后再此基础上可以把树和grid结合成新的tree_grid组件,如果增强grid功能,tree_grid也自然而然继承grid的增强功能 一直想用jsf,不知道jsf的组件可以支持灵活扩展吗? 反正我看到gt_grid用taglib封装后,我感觉很反感,我以前也是用taglib封装我的常用组件,但是觉得如果在之前做的组件上扩展很不方便,就很难实现tree_grid扩展grid的功能,大概应该需要重写,可能我对taglib还不了解的缘故 希望大家多多指点 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-06-12
yufu 写道 我现在是像fins说得那样,前台有ext这样的客户端UI,服务端用strtus2,之间只是json数据传输,逻辑和页面表现分开,通过annotation和jsonlib封装了json的转换,特别是pojo对象的直接转换
感觉好处是,客户端表现层可以灵活的扩展和重用,比如可以把分页,过滤,excel导出等等常用功能封装成自己的grid,然后再此基础上可以把树和grid结合成新的tree_grid组件,如果增强grid功能,tree_grid也自然而然继承grid的增强功能 一直想用jsf,不知道jsf的组件可以支持灵活扩展吗? 反正我看到gt_grid用taglib封装后,我感觉很反感,我以前也是用taglib封装我的常用组件,但是觉得如果在之前做的组件上扩展很不方便,就很难实现tree_grid扩展grid的功能,大概应该需要重写,可能我对taglib还不了解的缘故 希望大家多多指点 从结构上来讲,taglib和传统的程序写页面的方式都属于服务端计算的代码,或者是利用服务端的计算生成“死板”的、“调试不方便的”客户端代码(JS代码),今天突然想到一个词,给这种服务端生成JS的方式通称为JS的重载过程。 楼主都已经使用异步通讯为主的通讯方式,就不要再过过多地依赖服务端生成的方式通讯或者生成通讯代码。 客户端一样可以组件化,而且根据JS的动态语言特性,封装、使用和调试的成本是大大低于服务端生成方式的,而且以后服务端再切换框架的话,切换成本也不大。 |
|
返回顶楼 | |
发表时间:2008-06-12
ajax for asp.net 不就是这个么。
|
|
返回顶楼 | |
发表时间:2008-06-12
哦,我别的了解的比较少,没用过.net和jsf,seam什么的
刚看到很多人议论seam,所以想了解一下,是否应该用seam, 以前看到jsf用到很多taglib,所以一直没用,觉得自定义的组件,扩展方面肯定不是很灵活,不知道seam有没有好的办法 最近,想系统学学jsf,seam,tapestry,但是都学肯定难度很大,所以想看看别人一般都用什么,然后集中经历学习一下 |
|
返回顶楼 | |
发表时间:2008-06-12
taglib根本不具备可视化的条件...开发起来在布局方面要多费时间。
总来的说asp.net在web开发还是比较领先的。 |
|
返回顶楼 | |
发表时间:2008-06-13
ray_linn 写道 taglib根本不具备可视化的条件...开发起来在布局方面要多费时间。
总来的说asp.net在web开发还是比较领先的。 仅仅是开发速度比较领先吧。 |
|
返回顶楼 | |
发表时间:2008-06-13
ray_linn 写道 taglib根本不具备可视化的条件...开发起来在布局方面要多费时间。
总来的说asp.net在web开发还是比较领先的。 asp.net也是在html中的一堆xml tag,有什么不同? 这两个框架都是在server page中用标签负责显示。别误导别人。 |
|
返回顶楼 | |