“XML应用程序”的演示程序

 

基于之前讨论的帖子，做了一个演示。大家看看如何？

 

本程序是个安装程序，里面包含了OSGi运行环境、SWT相关Bundles和一个演示文件 test.xmla，安装之后它会自动创建到桌面上，不过有个问题就是，在某些中文环境下，如果路径包含中文可能会找不到文件，例如：

理想情况 

C:\Documents and Settings\Administrator\桌面\test.xmla

实际情况 

C:\Documents and Settings\Administrator\×???\test.xmla

 

 

尝试转换了字符编码也不好用，目前尚不清楚如何解决。折中的解决办法就是把 test.xmla 文件放到不包含中文路径的目录下。此演示程序需要Java运行环境1.6及以上版本。

 

演示文件中包含了：

 

1. SWT部件生成，演示namespace和bundles关联。

2. SWT布局处理，演示不同的bundles之间通过namespace可以互相处理对方的对象。

3. SWT事件处理，演示可以通过fragment bundle来注入事件，并在XML中使用（TestEvent）。

4. 脚本事件处理，演示直接在XML中编写脚本以处理SWT部件所产生的事件。

<?xml version="1.0" encoding="utf-8"?>
<Shell 
  xmlns="com.cmspad.xmla.swt"
  xmlns:t="com.cmspad.osgi"
  xmlns:l="com.cmspad.xmla.swt.layout" 
  xmlns:e="com.cmspad.xmla.swt.event" 
  t:id="hello" text="XML Application" style="DIALOG_TRIM,MAX,MIN" size="300,200" l:layout="grid" l:numColumns="3" defaultButton="aButton">
<!-- 载入 com.cmspad.xmla.swt.events.TestEvent 事件 -->
<e:event e:class="TestEvent"/>
<button text="Button 1"/>
<!-- 触发 TestEvent.buttonSelection 方法 -->
<button text="Button 2" e:selection="buttonSelection"/>
<button t:id="aButton" text="Button 3" l:horizontalAlignment="FILL" l:grabExcessHorizontalSpace="yes"/>
<button text="Button 4" e:selection="hello.text='Button 4 clicked';"/>
<!-- 调用下方脚本中的 f 函数 -->
<button e:Selection="f">Button 5</button>
<button text="Button 6" l:horizontalAlignment="FILL" l:grabExcessHorizontalSpace="yes"/>
<t:script>
function f(e){
 var kakakaka = 'HOHO';
 hello.text = "Function invoked:" + kakakaka;
}
</t:script>
</Shell>

 

20090927: 默认的 main(String[] args) 参数是通过ISO-8859-1编码的，所以在传递中文名称时会出现乱码，经过改进，删除线部分的问题已经解决，附件已重新上传。

评论

11 楼 yipsilon 2009-09-29  

pufan 写道

需求，有求则有应，市场决定一切。

html(flex,javaFX)的市场定位很明确，满足互联网浏览的用户需要。

java(Swing,swt)的定位也很明确，满足使用桌面程序的用户需要。

你的想法的用户群是那些人呢？又有多少？目前来看，在以上两个领域挑战竞争对手难度不是一般的大，个人对此项目的前景亦不看好，除非你能找到其他蓝海领域。

其实反过来看，为什么非要是挑战，而不能是增强呢？

想要看的高，不需要长得高，踩在他人的肩膀上多好。

侠义上来讲，问题就出在没有中间市场，例如会html的人想处理一些数据然后保存到文件中，在浏览器上做显然是不可能的。

广义上来讲，脚本语言能做什么此程序就能干什么，不是么？既然JVM现在非常支持将其他脚本嵌入到java中，兄台怎么能说出是挑战而非增强的话呢（引用的粗体文字）？难道是我说的？呵呵。

市场是由应用决定的，而不是平台决定的，平台再好而没有在上面的应用，那也是没市场的。现在研究会有多少人用没有意义，如果有一些非常棒的Bundles应用，那相信会有很多人会去用的。

10 楼 pufan 2009-09-29  

yipsilon 写道

pufan 写道

yipsilon 写道

pufan 写道

代码全在XML里？那Java的强类型OOP优势岂不完全丧失，IDE的编译检查、重构、调试等等岂不也荡然无存了？

既然是平台环境，那能带给程序员的好处是什么？比java(eclipse)的平台环境又有什么优势？

找个跟本想法类似的技术，那非HTML莫属，Java端只是解释器和插件实现，或许以后其他语言中也有OSGi技术了，也可以用其他语言来实现，所以这跟Java没有关系的。

调试问题之前也说过了，只要解释器做得比较完美，那调试跟踪是不成问题的。

这个想法目前我所认为直接带来的好处就是降低了学习门槛和实现快速开发能力，最起码可以快速构建简单的应用程序，或者程序界面原型。

姑且认为解释器、开发环境都已成熟，可以与eclipse相媲美了。

那么我们再看：

学习门槛有降低吗？底层用java（swing）的话是不是还得学习java（swing），另外还得学习XML的相关配置。

复用是快速开发的不二法则，配置放到哪里和快速开发关系不大，最终的代码复用岂不还是Java类。至于配置简单，我同样可以基于java class写一个脚手架，配置一样简单，同时还有ide的天生支持。

简单应用程序没有说服力，毕竟我们要做的绝不是example。那么这个开发环境驾驭复杂应用的能力又如何？

还是拿html来说明问题吧。

你应该这么比，如果实现一个Java和HTML都能做出来的界面（例如一个界面里只有一个按钮，点击后弹出对话框），用HTML快还是用Java快呢？

快速开发有两个实际过程：

第一个是构建过程，也就是说从头写代码，如果html和java都用设计器来说，效率是不差上下的，但如果是写代码，网页设计人员只需要懂得html的知识即可，而java开发人员则不仅仅需要懂得java语法，还要学会UI库，例如swing或者swt，学习门槛高了。

第二个是调整过程，也就是在原来的基础上对界面细节进行修改，这样的话，HTML与Java的开发效率就明显了，HTML只需要在文本文件里修改几项就可以搞定，而java源代码改完后，还需要重新编译，打包运行，如果想半自动化搞，还需要打开IDE。

这两个过程中，可以看出HTML和Java的开发效率差别了。这其实也是众多脚本的优势所在，只是XML语法相比其他脚本语言的学习门槛比较低，更何况也已经被大部分人接受了（在web上的html、xhtml都是其近亲）。

我认为做一个东西，要从简单的开始，哪怕最开始只是一个空白的界面，只要能运行起来，就会有动力去继续开发。当前兄台的说法，就好比拿Java 1.0版跟1.6版相比一样，从1.0到1.6演变势必要有个过程。更何况，我一直都在强调目前只是一个想法，连内部开发版都不是，不要这么较真嘛，呵呵。

需求，有求则有应，市场决定一切。

html(flex,javaFX)的市场定位很明确，满足互联网浏览的用户需要。

java(Swing,swt)的定位也很明确，满足使用桌面程序的用户需要。

你的想法的用户群是那些人呢？又有多少？目前来看，在以上两个领域挑战竞争对手难度不是一般的大，个人对此项目的前景亦不看好，除非你能找到其他蓝海领域。

其实反过来看，为什么非要是挑战，而不能是增强呢？

想要看的高，不需要长得高，踩在他人的肩膀上多好。

9 楼 yipsilon 2009-09-29  

pufan 写道

yipsilon 写道

pufan 写道

代码全在XML里？那Java的强类型OOP优势岂不完全丧失，IDE的编译检查、重构、调试等等岂不也荡然无存了？

既然是平台环境，那能带给程序员的好处是什么？比java(eclipse)的平台环境又有什么优势？

找个跟本想法类似的技术，那非HTML莫属，Java端只是解释器和插件实现，或许以后其他语言中也有OSGi技术了，也可以用其他语言来实现，所以这跟Java没有关系的。

调试问题之前也说过了，只要解释器做得比较完美，那调试跟踪是不成问题的。

这个想法目前我所认为直接带来的好处就是降低了学习门槛和实现快速开发能力，最起码可以快速构建简单的应用程序，或者程序界面原型。

姑且认为解释器、开发环境都已成熟，可以与eclipse相媲美了。

那么我们再看：

学习门槛有降低吗？底层用java（swing）的话是不是还得学习java（swing），另外还得学习XML的相关配置。

复用是快速开发的不二法则，配置放到哪里和快速开发关系不大，最终的代码复用岂不还是Java类。至于配置简单，我同样可以基于java class写一个脚手架，配置一样简单，同时还有ide的天生支持。

简单应用程序没有说服力，毕竟我们要做的绝不是example。那么这个开发环境驾驭复杂应用的能力又如何？

还是拿html来说明问题吧。

你应该这么比，如果实现一个Java和HTML都能做出来的界面（例如一个界面里只有一个按钮，点击后弹出对话框），用HTML快还是用Java快呢？

快速开发有两个实际过程：

第一个是构建过程，也就是说从头写代码，如果html和java都用设计器来说，效率是不差上下的，但如果是写代码，网页设计人员只需要懂得html的知识即可，而java开发人员则不仅仅需要懂得java语法，还要学会UI库，例如swing或者swt，学习门槛高了。

第二个是调整过程，也就是在原来的基础上对界面细节进行修改，这样的话，HTML与Java的开发效率就明显了，HTML只需要在文本文件里修改几项就可以搞定，而java源代码改完后，还需要重新编译，打包运行，如果想半自动化搞，还需要打开IDE。

这两个过程中，可以看出HTML和Java的开发效率差别了。这其实也是众多脚本的优势所在，只是XML语法相比其他脚本语言的学习门槛比较低，更何况也已经被大部分人接受了（在web上的html、xhtml都是其近亲）。

我认为做一个东西，要从简单的开始，哪怕最开始只是一个空白的界面，只要能运行起来，就会有动力去继续开发。当前兄台的说法，就好比拿Java 1.0版跟1.6版相比一样，从1.0到1.6演变势必要有个过程。更何况，我一直都在强调目前只是一个想法，连内部开发版都不是，不要这么较真嘛，呵呵。

8 楼 pufan 2009-09-29  

yipsilon 写道

pufan 写道

代码全在XML里？那Java的强类型OOP优势岂不完全丧失，IDE的编译检查、重构、调试等等岂不也荡然无存了？

既然是平台环境，那能带给程序员的好处是什么？比java(eclipse)的平台环境又有什么优势？

找个跟本想法类似的技术，那非HTML莫属，Java端只是解释器和插件实现，或许以后其他语言中也有OSGi技术了，也可以用其他语言来实现，所以这跟Java没有关系的。

调试问题之前也说过了，只要解释器做得比较完美，那调试跟踪是不成问题的。

这个想法目前我所认为直接带来的好处就是降低了学习门槛和实现快速开发能力，最起码可以快速构建简单的应用程序，或者程序界面原型。

姑且认为解释器、开发环境都已成熟，可以与eclipse相媲美了。

那么我们再看：

学习门槛有降低吗？底层用java（swing）的话是不是还得学习java（swing），另外还得学习XML的相关配置。

复用是快速开发的不二法则，配置放到哪里和快速开发关系不大，最终的代码复用岂不还是Java类。至于配置简单，我同样可以基于java class写一个脚手架，配置一样简单，同时还有ide的天生支持。

简单应用程序没有说服力，毕竟我们要做的绝不是example。那么这个开发环境驾驭复杂应用的能力又如何？

7 楼 yipsilon 2009-09-29  

pufan 写道

代码全在XML里？那Java的强类型OOP优势岂不完全丧失，IDE的编译检查、重构、调试等等岂不也荡然无存了？

既然是平台环境，那能带给程序员的好处是什么？比java(eclipse)的平台环境又有什么优势？

找个跟本想法类似的技术，那非HTML莫属，Java端只是解释器和插件实现，或许以后其他语言中也有OSGi技术了，也可以用其他语言来实现，所以这跟Java没有关系的。

调试问题之前也说过了，只要解释器做得比较完美，那调试跟踪是不成问题的。

这个想法目前我所认为直接带来的好处就是降低了学习门槛和实现快速开发能力，最起码可以快速构建简单的应用程序，或者程序界面原型。

6 楼 pufan 2009-09-29  

代码全在XML里？那Java的强类型OOP优势岂不完全丧失，IDE的编译检查、重构、调试等等岂不也荡然无存了？

既然是平台环境，那能带给程序员的好处是什么？比java(eclipse)的平台环境又有什么优势？

5 楼 yipsilon 2009-09-28  

solonote 写道

这么一说就完全明白了，确实拿UI举例有一些误导，在加上取名XML应用程序作为噱头(玩笑:)
OSGI，遇到使用OSGI的场合不太多，曾经做过一个C#项目，我们模仿OSGI，做了多个Bundle，这些Bundle是进程隔离的，中间有一个功能非常简单的核心Bundle负责检查其他Bundle的健康状况。这个系统生命力强悍，一个Bundle挂了马上由核心的Bundle重启，而核心足够简单，不容易挂掉。
如果用OSGI做产品的话，确实你的想法很不错。
OSGI，不知道下次用到你会是什么时候......

其实取名为“XML应用程序”不是噱头，就像之前的标题说的那样“OSGi + XML = XML应用程序”，它包含了OSGi，这个OSGi的含义也有两种，一种是内置的XML解释器，就是运行环境，另一种是各种应用类Bundles，就是类库，而XML则是程序代码。这么类比的话用“运行环境 + 类库 + 代码 = 应用程序”来解释，是很正常不过的事情吧。

就像之前的 SWT-XUI 的例子，难道用XML写出来的 Windows 记事本程序不是应用程序么？为什么就不能叫“XML应用程序”呢？呵呵....

4 楼 solonote 2009-09-28  

这么一说就完全明白了，确实拿UI举例有一些误导，在加上取名XML应用程序作为噱头(玩笑:)
OSGI，遇到使用OSGI的场合不太多，曾经做过一个C#项目，我们模仿OSGI，做了多个Bundle，这些Bundle是进程隔离的，中间有一个功能非常简单的核心Bundle负责检查其他Bundle的健康状况。这个系统生命力强悍，一个Bundle挂了马上由核心的Bundle重启，而核心足够简单，不容易挂掉。
如果用OSGI做产品的话，确实你的想法很不错。
OSGI，不知道下次用到你会是什么时候......

3 楼 yipsilon 2009-09-28  

solonote 写道

运行了Demo,看了代码,东西是不错的.
嘿嘿,楼主还是打着"XML应用程序"的旗号.
用XML来组织UI的模式很早之前就有了,Java方面有eFace,楼主是否是参与者之一?
对比eFace,楼主的程序:
1.加入了脚本支持
2.在XML描述UI组件触发OSGI Bundle的方法
3.双击xmla后缀就能运行程序(这个只能算一个小技巧吧)

楼主的目标是想做一个更好的eFace?我确实没有看到那种从无到有的创新点.
我现在关心的是,你到底想要做一个什么东西.另外,能放出源码吗?

XML应用程序，应该是可以涵盖所有的应用程序，而不仅仅是UI，拿UI做演示主要是可以更直观地体现出程序代码的用法和好处，要是我写个看不见界面的服务器演示，那还有意思么？说不定人家还以为我这是某个主流服务器软件的配置文件呢，呵呵。

eFace的确是社区跟Soyatec联合开发出来的，而且是一个成熟稳定的XAML应用产品，而XML应用程序运行环境是一个提供OSGi底层支持的通用XML解释器，而不是应用，只要有人愿意去做，在Bundle上做任何基于XML的应用都可以，例如 MXML、HTML等等，一个是应用产品而另一个是平台环境，个人认为此想法并不跟eFace冲突呀。你说呢？

至于源代码，初级阶段连路都找不到就放出来那丢人啊，如果想法成熟了自然会放出来的，主要看我们有没有时间和能力开发出来，毕竟都是用业余的时间搞的，哎哎。

2 楼 solonote 2009-09-28  

运行了Demo,看了代码,东西是不错的.
嘿嘿,楼主还是打着"XML应用程序"的旗号.
用XML来组织UI的模式很早之前就有了,Java方面有eFace,楼主是否是参与者之一?
对比eFace,楼主的程序:
1.加入了脚本支持
2.在XML描述UI组件触发OSGI Bundle的方法
3.双击xmla后缀就能运行程序(这个只能算一个小技巧吧)

楼主的目标是想做一个更好的eFace?我确实没有看到那种从无到有的创新点.
我现在关心的是,你到底想要做一个什么东西.另外,能放出源码吗?

1 楼 yipsilon 2009-09-27  

内容已更新，这次测试程序比较完美啦~