论坛首页 Java企业应用论坛

UI开发模式对比:JSP、Android、Flex

浏览 9056 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2013-07-12  

前一篇文章分析了Java平台下不同类型WEB框架对开发模式的影响,多数Java领域的WEB框架都是聚焦于服务端MVC的实现,这些框架对View的支持,通常是基于标准的JSP或类似JSP的模板技术如Freemarker或Velocity。JSP或类JSP的模板技术已经是上个世纪的页面技术了,它能跟上时代的发展和技术的进步吗?

我们先看一段典型的JSP页面代码(摘自Struts2样例代码):

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<%@ taglib prefix="s" uri="/struts-tags" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Hello World!</title>
</head>
<body>
<h2><s:property value="messageStore.message" /></h2>
<p>I've said hello <s:property value="helloCount" /> times!</p>
<p><s:property value="messageStore" /></p>
</body>
</html>

再看一段Android平台下UI开发的代码(摘自Android开发手册):

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
              android:layout_width="fill_parent" 
              android:layout_height="fill_parent"
              android:orientation="vertical" >
    <TextView android:id="@+id/text"
              android:layout_width="wrap_content"
              android:layout_height="wrap_content"
              android:text="I am a TextView" />
    <Button android:id="@+id/button"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="I am a Button" />
</LinearLayout>

还可以看看Flex UI代码(摘自Flex开发手册):

<?xml version="1.0"?>
<!-- containers\layouts\VBoxSimple.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">

    <mx:VBox borderStyle="solid" 
        paddingTop="10"
        paddingBottom="10" 
        paddingLeft="10" 
        paddingRight="10">
        
        <mx:Button id="fname" label="Button 1"/>
        <mx:Button id="lname" label="Button 2"/>
        <mx:Button id="addr1" label="Button 3"/>
        <mx:ComboBox id="state">
              <mx:ArrayCollection>
                 <mx:String>ComboBox 1</mx:String>
              </mx:ArrayCollection>         
        </mx:ComboBox>
    </mx:VBox>
</mx:Application>

对比上面三段代码,可以看出JSP页面技术与Android及Flex UI技术的差异:

  • 命令式 vs. 声明式:JSP是命令式代码编写方式,而Android及Flex是声明式;
  • 组件化:JSP代码的组件能力很差,主要通过标签库tag lib实现展现逻辑的利用,而Android及Flex都有专门设计的组件机制;
  • 布局支持:JSP对页面展示的布局没有支持,Android及Flex都有大量的布局组件实现声明式布局;
  • 数据组件:JSP没有支持,Android有ContentProvider抽象,Flex则有各种数据对象,用于存取本地或远程数据

声明式和组件化应该是必然的趋势,由此可见JSP技术的落后。但遗憾的是目前Java平台还没有什么技术可以取代JSP:JSF是基于JSP的新一代页面技术,但从设计上看JSF相比Android和Flex还较大差距;GWT之类的框架也可以取代JSP,但GWT走向了纯命令式的相反方向。

 

如果向Android和Flex的开发模式看齐,基于Java平台开发WEB应用的最佳方式应该是HTML+JS+JSON。HTML也是声明式的,本质上和前面Android及Flex的UI技术类似;JS相当于Android中的Java及Flex中的ActionScript,JSON用于客户端与服务端进行数据交换。只是HTML+JS+JSON也有其不足之处:

  • HTML内建组件(tag)相比Flex及Android的组件,其表现力不够,比如HTML没有布局组件,HTML的table相比Flex的DataGrid组件过于低层;
  • HTML本身的设计并非是用于UI,比如其没有考虑数据绑定机制,也没有数据组件之类的概念;
  • HTML没有组件定制能力,而Android及Flex都设计了自定义组件的机制;

由于存在以上不足,就出现了EasyUI/DWZ等声明式的UI框架,这也是WEB开发模式浅析中建议采用EasyUI/DWZ等框架的理由。

 

回到Java世界,是否可以在服务端设计一种声明式、组件化的页面技术用于取代传统JSP页面技术呢?

 

 

   发表时间:2013-07-12  
我觉得现在互联网应用制约View层设计的问题主要有两个,一是如何支持瘦客户,或者说支持只提供基本通用编程能力(HTML+JS)的多种客户端; 二是如何处理服务器端跨请求的状态。在组件化这个特定话题上,又引申出来一个问题:数据如何与组件绑定

JSP的定位是提供一种基础设施,它根本不能假定客户端上有组件级别的现成设施 (它本身就是基础设施),自然也不能假定一种特定的数据绑定方式,所以在RIA方面跟后两种技术其实没有可比性(人家定位就不在这里,就比如你不能用汇编跟ruby比较然后说汇编不够先进一样的道理)。在RIA企业应用方面JCP的意图是用JSF来填补,轻量级互联网应用方面由于不对JCP的稳重路线,感觉官方支持不多,主要通过扶植JVM上的动态语言并依靠第三方框架实现。

Android相当于本地应用,组件实际绑定本地数据,完全没有请求状态的问题,想怎么玩都行,这个跟互联网编程没法比,跟C#写本地应用时来比才对题。如果Android应用要访问服务器端,服务器端的编程模型里肯定没有Android本地的组件模型。

Flex有富客户端支持,能在客户端预先定义好一种特定的数据绑定方式和一堆基础组件,这是它能使用很简明的声明式页面定义语言的前提。我对Flex不太熟识,不知道在服务器端是否能通过组件模型来编程(就是在服务器端代码里能取到“组件”实例并进行编程)。如果不行,说明它选择回避服务器状态的问题,由开发者自行管理或使用RESTFUL风格,那它在UI角度本质上跟Android差不多,可以看成是本地应用。

说点题外话:在企业应用和互联网应用的长远角度看,我个人不太看好Flash,Flex,JavaFX这类通过在浏览器上装插件来解决跨浏览器问题以及浏览器缺乏基础设施问题的技术(游戏和广告领域不算)。如果这类技术能解决根本问题,现在的浏览器市场从一开始就不会这样混乱。在HTML之前,也有过一段流行“Active Document”(好像叫这个名称)的时期,也是一款浏览软件配搭自己一套声明语言,根本不存在跨软件浏览的问题。等真正强大的HTML+Netscape+javascript出现,这些软件全部挂掉。而一旦HTML成为事实标准,什么IE,Opera等等基于HTML的竞争者必定会冒出来。厂商不同,实现必然有差异,甚至为了抢夺市场故意扩大差异(当然明着都说要标准化——以我为标准)。 现在这类插件技术,只不过又在浏览器基础上递归一次这个过程而已(以前的浏览器标榜跨操作系统,现在的插件技术标榜跨浏览器),它们目前之所以能守着自己一亩三分地,就是因为在语言层面谁也赢不了谁,还不值得去模仿。如果某一家能在语言层面上一统江湖,在客户端层面上就必然开始混乱。到时又会出现一些“跨(跨浏览插件)的插件”来解决兼容问题。

回到楼主最后的问题,感觉现在JCP的态度就是“想组件化,找JSF”。JSF页面倒是声明式的,JSF2规范里就把页面上用的语言叫VDL(页面定义语言),默认首选是facelet。你可能觉得在VDL里写CSS不够纯粹,但别忘了CSS本身也是声明式的。原则上VDL里不应该出现命令式的东西(除非你图方便直接在页面里写javascript代码)。

说到组件化,JSF最大的问题正是组件化思维太深,从前端到后端的组件模型都要统一起来(服务器端编程时可以直接引用组件实例),还试图屏蔽跨http请求状态问题(视图状态),瘦客户端问题(组件渲染发生在服务端,而不是直接把VDL发给客户端),数据绑定问题(数据从前端控件一路绑定到服务器端的Model层上)。代价是既影响了并发访问能力,又削弱了开发者对UI的控制能力,成了一个理论上只适合企业应用的框架。(不过话说回来,这并没有违背JCP的设计理念) 但JSF之所以被设计成这样,是因为它兼顾了前面说的基于瘦客户端,托管http状态,以及一路到底的数据绑定。我觉得至少在今后几年内,它可以作为Java互联网组件化编程模型的一个基准,你要在某些方面做得比它更好,就只能牺牲另一些方面。
0 请登录后投票
   发表时间:2013-07-16  
看了楼上关于Flex、JSF问题及前景的分析,很受启发。

关于JSP的定位,楼上说得也很好,即JSP太底层,就是一个基础设施。但目前我接触的多数基于JAVA平台的WEB应用都还是直接在JSP,使用JSF的很少,使用其它具有声明式及组件化特性的页面技术的应用也很少。

通过对比android, flex,甚至前端的easyui, backbone等框架的开发模式,感觉现在用jsp开发前端实在过于原始。为什么java平台除了jsf之外,再没有更多的页面技术框架出现呢?我能想到的原因只是现在前端越来越受大家重视,页面技术完全可以用前端框架代替,所以java世界没有做这种页面框架的动力。

但由于很多团队还没有专业的前端,即使有,那也属于稀缺资源(受眼界所限,个人所在的企业开发领域是这种现状),这种时候是否有必要使用java技术基于jsp实现更好的页面框架呢?这是我这篇帖子想提出的问题。
0 请登录后投票
   发表时间:2013-07-17  
习惯Web开发的人很难适应Android的布局定义,虽然这是一个跨领域的问题,但Android开发必然要走类似Servlet->JSP这样的便于开发的变革道路。JSP中的Java代码几乎被所有人诟病,我也不喜欢,但对比一下类似的PHP,没有人指责PHP中的Server端代码,想必是对待事物的视角不一样,如果只用JSP做几个简单的页面,填上一些Java代码又有何不可,只要达到目的就好了。所以,我觉得技术没有利弊,有的是特色,发挥技术特色达到项目目的就是最佳实践。
0 请登录后投票
   发表时间:2013-07-17  
gafking 写道
习惯Web开发的人很难适应Android的布局定义,虽然这是一个跨领域的问题,但Android开发必然要走类似Servlet->JSP这样的便于开发的变革道路。JSP中的Java代码几乎被所有人诟病,我也不喜欢,但对比一下类似的PHP,没有人指责PHP中的Server端代码,想必是对待事物的视角不一样,如果只用JSP做几个简单的页面,填上一些Java代码又有何不可,只要达到目的就好了。所以,我觉得技术没有利弊,有的是特色,发挥技术特色达到项目目的就是最佳实践。

拿PHP做对比的思考角度,值得考虑
0 请登录后投票
   发表时间:2013-07-18  
jxb8901 写道
看了楼上关于Flex、JSF问题及前景的分析,很受启发。

关于JSP的定位,楼上说得也很好,即JSP太底层,就是一个基础设施。但目前我接触的多数基于JAVA平台的WEB应用都还是直接在JSP,使用JSF的很少,使用其它具有声明式及组件化特性的页面技术的应用也很少。

通过对比android, flex,甚至前端的easyui, backbone等框架的开发模式,感觉现在用jsp开发前端实在过于原始。为什么java平台除了jsf之外,再没有更多的页面技术框架出现呢?我能想到的原因只是现在前端越来越受大家重视,页面技术完全可以用前端框架代替,所以java世界没有做这种页面框架的动力。

但由于很多团队还没有专业的前端,即使有,那也属于稀缺资源(受眼界所限,个人所在的企业开发领域是这种现状),这种时候是否有必要使用java技术基于jsp实现更好的页面框架呢?这是我这篇帖子想提出的问题。


我目前的看法是现在web开发的view模板组件化有两个大方向,一是JSF这类服务器端模板,二是客户端模板组件化方案。因为一楼主要讨论java端模板,所以我上面着重说JSF。至于在纯jsp(或者说纯html)这个层面,我觉得Google的AngularJS ( www.angularjs.org )代表了一种比较有前途的前端模板组件化模式。 (这里有篇中文的介绍文章 http://gbin1.com/gb/share/262.htm ,随手google的)

view层模板组件化的最终目的是把js和html的硬编码耦合分离开,模板只负责对展现的初始布局进行声明,组件实现部分只负责针对与具体页面无关的组件或组件属性进行编程,最终通过提供数据绑定和一种易用的自定义组件方案来支持复杂的UI交互行为。而这种交互行为,应该是由绑定的model数据驱动的,也就是说多个组件之间的联动,应该是某个组件改动了model层的状态,其他组件根据model的新状态进行刷新(本地应用一般会用观察者模式来实现自动刷新,但基于AJAX的JSF目前没有提供类似机制,只能由发动更新的组件指定刷新区域,这点上AngularJs有很大优势,毕竟这是纯客户端方案的强项),这样就能有效避免在组件中声明中嵌入大量的联动程序。我觉得不管是服务器端还是客户端的模板组件化方案,至少应该符合上面的要求,才算是真正意义的组件化。而easyui,extjs这类js组件库,我认为并不是模板组件的开发方式,你还是免不了要在页面里嵌入大量js脚本或者在js文件里硬编码到DOM树的selector。

AngularJs在模板层面是基于纯html的,它提供了一种简单的方案(directive)让你可以自定义新的tag或给现有的tag加入新属性,自带的与服务器端交互方式使用Restful风格。(但也可以选择不使用自带的交互方案,我在公司的Richfaces(JSF)项目里用Angular处理客户端的联动逻辑也没有任何问题。)这种客户端组件模板的开发方式就更类似Android和Flex的方式,服务器端仅充当数据提供者,主要的MVC逻辑均在客户端实现。

至于没有专业前端或前端水平不够,我觉得即使是使用JSF这类服务器端组件方案,如果想页面做得好看,精准控制UI逻辑,js开发是逃不掉的,问题在于js开发与页面布局开发如何解耦。而且一旦解耦,就可能出现专业的第三方组件项目,至少能解决部分问题。JSF因为是JEE标准,且出现较久,第三方组件库有不少( http://www.primefaces.org/ 是一个比较好的纯组件库 )。AngularJs作为独立框架出现还不久(去年6月1.0版),目前还没有看到专业的第三方组件库,但我觉得它代表了一种不错的发展方向。
0 请登录后投票
   发表时间:2013-07-19  
解释一下JSP & Android| Flex 原理上的不同:
JSP的方式:
JSP(标记语言) -> Container 转义 -> Java 代码 -> 字符串输出html代码 -> 浏览器API绑定 -> 生成UI

Android | Flex
xml标记语言 -> 本地API绑定(对应浏览器解析) -> 生成UI

在看一下这个过程:
浏览器环境:  html代码 -> 浏览器API绑定 -> 生成UI
Android/Flex环境: xml标记语言 -> 本地API绑定 -> 生成UI

在对比一下各个环境的状态:
浏览器环境: javascript, BOM, DOM
Android/Flex环境:  Java/ActionScript, 本地API

专注在后台生成js, css, html。就如同做个后台生成Android/Flex用的xml ui描述一样。只想说,这个思路很蛋疼。
0 请登录后投票
   发表时间:2013-07-21  
witcheryne 写道
解释一下JSP & Android| Flex 原理上的不同:
JSP的方式:
JSP(标记语言) -> Container 转义 -> Java 代码 -> 字符串输出html代码 -> 浏览器API绑定 -> 生成UI

Android | Flex
xml标记语言 -> 本地API绑定(对应浏览器解析) -> 生成UI

在看一下这个过程:
浏览器环境:  html代码 -> 浏览器API绑定 -> 生成UI
Android/Flex环境: xml标记语言 -> 本地API绑定 -> 生成UI

在对比一下各个环境的状态:
浏览器环境: javascript, BOM, DOM
Android/Flex环境:  Java/ActionScript, 本地API

专注在后台生成js, css, html。就如同做个后台生成Android/Flex用的xml ui描述一样。只想说,这个思路很蛋疼。


对比WEB的HTML-CSS/JS技术、Android的XML/Java技术、Flex的MXML/ActionScript技术,三者之间确实很有可比性,在某种程度上是完全类似和对等的技术。但是在以下方面,这三种技术又不具有可比性:

1、相比Android和Flex来讲,HTML技术的应用范围非常广泛:比如不可能用Android的XML技术实现一个淘宝首页吧?也不可能用Flex技术(不是Flash技术)实现网页游戏吧?

2、相对Android和Flex来讲,HTML更底层:看一下他们的标记定义,如布局标记、树形组件等等,在HTML中不可能定义原生的标记去实现。不是技术上做不到,而是定位不同,因为HTML的定位更底层。

说到WEB开发,其实范围非常广泛,从电子商城、博客论坛,到网页游戏、实时监控,再到企业应用、管理系统等,差异非常大。HTML技术由于非常底层,因此这些应用都可以用基于HTML的技术去实现。但我想每一个应用都会基于HTML技术做出一些内部的框架以固化特定领域的知识从而提升开发效率降低开发难度。

我们这里讨论的页面模板技术的许多想法,其实也是基于特定领域(如企业应用类的管理系统)的一些思考。如果去除这个背景和范围,那很多想法可能都有问题。

在网上讨论这类技术问题的难度就于,每个人的行业背景、技术背景都不一样,每个人都有每个人的假设和经验,很多时候可能是牛头不对马嘴。这就要我们能尽量理解对比想法的出发点。


0 请登录后投票
   发表时间:2013-07-21  
TO:kidneyball

AngularJs确实是很好的思路,代表了末来WEB的一个方向。我也很怀疑在Java端用JSP做文章有多大意义。

有这样一种感觉:别人在前面领跑,我们不但没有跟跑,反而在背道而驰。
0 请登录后投票
   发表时间:2013-07-21  
jxb8901 写道

对比WEB的HTML-CSS/JS技术、Android的XML/Java技术、Flex的MXML/ActionScript技术,三者之间确实很有可比性,在某种程度上是完全类似和对等的技术。但是在以下方面,这三种技术又不具有可比性:

1、相比Android和Flex来讲,HTML技术的应用范围非常广泛:比如不可能用Android的XML技术实现一个淘宝首页吧?也不可能用Flex技术(不是Flash技术)实现网页游戏吧?

2、相对Android和Flex来讲,HTML更底层:看一下他们的标记定义,如布局标记、树形组件等等,在HTML中不可能定义原生的标记去实现。不是技术上做不到,而是定位不同,因为HTML的定位更底层。

说到WEB开发,其实范围非常广泛,从电子商城、博客论坛,到网页游戏、实时监控,再到企业应用、管理系统等,差异非常大。HTML技术由于非常底层,因此这些应用都可以用基于HTML的技术去实现。但我想每一个应用都会基于HTML技术做出一些内部的框架以固化特定领域的知识从而提升开发效率降低开发难度。

我们这里讨论的页面模板技术的许多想法,其实也是基于特定领域(如企业应用类的管理系统)的一些思考。如果去除这个背景和范围,那很多想法可能都有问题。

在网上讨论这类技术问题的难度就于,每个人的行业背景、技术背景都不一样,每个人都有每个人的假设和经验,很多时候可能是牛头不对马嘴。这就要我们能尽量理解对比想法的出发点。


看了你的回复,还是忍不住做个回复。
之前的对比是比较泛化,并且用“蛋疼”以此来戏说型的否定这个切入点,不太恰当。

Android/Flex UI描述XML, 对应的运行环境是Android/Flex。JSP对应servlet container, 输出的执行结果是html/js/css, 最终运行环境是浏览器。
从技术环节层面分析,得出结论。浏览器端的模板技术,应该使用浏览器端的语言去实现。 AnglarJS, 是非常棒实现,最近在关注,还没有尝试使用,AnglarJS核心内容是dom-binding。
在了解AnglarJS之前,我尝试过使用backbone来解决UI组件模板的化的问题,主要来解决公司表单页面组件话的问题。
整体思路:
1. 定义一个json格式, 这个格式类似android中的xml描述
2. 在web创建设计器,使用预设组件(选人,选时间,选设备项目自用的特殊组件),设计UI。
3. web端设计好后生成json描述
4. 根据json描述生成html/js/css代码, 计划中打算生成C++代码共C/S程序使用。

由于部门协调原因,最终项目实现成如下情况:
1. 将定义的json格式,换成老项目中的文本配置。这类配置仅仅提供字段映射,label描述,宽度等信息
2. 设计器所有组件都是text组件。
3. web端设计好后生成text配置。
4. b/s项目(GWT)中的页面还沿用动态布局的方式, C++中的实现同b/s项目,动态实现UI

项目地址, 整理出来供学习用:
https://github.com/lvjian700/formdesigner



0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics