OSGi + XML = XML应用程序？

最近将N久以前的项目整理了一下，发现我很早之前搁置的项目，现在已经是时机重新启动了，它就是 XMLX 项目。

 

XMLX项目建立之初本想使用Java的一些模块特性，来动态把XML解析成应用程序，例如图形界面等。但是当时由于没有成熟的模块机制，所涉及出来的功能模块开发时非常繁琐，直接导致入门门槛很高（主要是因为是自己设计的API，文档没有及时跟上），于是乎，就被搁置了。

 

如今，OSGi技术已经成熟了，使用OSGi作为XMLX的模块平台，可以说是极爽的一件事情。

 

对于我的想法，可以从下面的代码中展示出来：

<?xml version="1.0" encoding="utf-8"?>
<!-- com.cmspad.xmla.swt 为支持SWT核心部件标记的Bundle -->
<!-- com.cmspad.xmla.swt.layout 为支持SWT布局部件标记的Bundle -->
<!-- com.cmspad.osgi 为系统核心功能标记，提供各种有用的功能 -->
<Shell xmlns="com.cmspad.xmla.swt:(1.0.0,2.0.0]" xmlns:t="com.cmspad.osgi" xmlns:l="com.cmspad.xmla.swt.layout:1.0.0"
  t:id="hello" 
  text="Hello World" 
  style="DIALOG_TRIM,MAX,MIN" 
  size="300,200"
  l:layout="grid"
  l:numColumns="3"
  defaultButton="aButton">
<button text="Button 1"/>
<button text="Button 2"/>
<button t:id="aButton" text="Button 3" l:horizontalAlignment="FILL" l:grabExcessHorizontalSpace="yes"/>
<button text="Button 4"/>
<button>Button 5</button>
<button text="Button 6" l:horizontalAlignment="FILL" l:grabExcessHorizontalSpace="yes"/>
</Shell>

 以上的代码，用过SWT的同学应该不难理解。XML与OSGi结合之处，就是通过XML的命名空间，来区分不同Bundles的功能。 看看效果图吧：

 

这样，我们只要在开发相应的Bundles，就可以实现各种应用，当然，在这过程中还需要有一个API规范来指导开发。

 

这只是一个想法，距离完整实现还有一段时间，大家可以发表一下自己的想法和建议～～

有这个必要吗？
微软的xaml，mozira的xul都提出多少年了

楼上的看的懂人话吗？人家就是个想法，和TMD微软xaml有个鸟关系？我认为这个就是很不错的想法。最鄙视你这样人，不奉献自己的思想还在旁边风言风语。话说回来，这个和xml应用确实关系不大，只是用osgi来区分buddle？模块化？

说话跟文革红卫兵一样，lz自己都说了“大家可以发表一下自己的想法和建议”，难道容不得别人一点点的质疑吗？

“如无必要，勿增实体”，重复做别人做的事情，如果不能做的更好，有意思吗？
无非是浪费自己和别人的时间精力
时间精力可以做别的更多的事情，软件还很多领域可以去做

我对XAML和XUL没有太深入的了解，但据我所知，XAML主要是用于界面的设计上，而XUL它只能在浏览器沙箱里工作。两者好像扩展起来都非常复杂。

我的想法就是在OSGi平台下，可以快速开发出标记插件来实现对XML应用程序的支持。而对于OSGi的开发，目前有强大的Eclipse在支持，可所谓踩在巨人的脚背上....

如果把这个项目做成只要鼠标一点击特定后缀名的XML文件，就可以直接运行，就像执行一个可执行程序一样。这样的话，假设说我们开发出来了HTML的扩展插件，那么会HTML的人，就可以写程序了，不是么？

可怕的家伙

据我所知，XAML里面可以内嵌代码

想法很不错

不过程序很难写，准确说很难调试，想想把，Java编译器，跟踪器全被你废了武功了，呵呵，楼主够狠的。

你这个项目不就是用来做UI的吗？现在都提倡UI与逻辑分离，你要把这2者榜定在一起？

逻辑是什么呢？就是控制事件和事务处理？这些都可以在插件中做以达到UI与逻辑分离呀，而XML作为UI部分仅仅是调用插件的功能和进行一些简单互动而已，不是么？

关于嵌入代码问题，曾经的 XMLX 前身 SWT-XUI 就支持JavaScript、BeanShell、Groovy等嵌入式脚本，这个实现起来是没有问题。

至于调试问题，我觉得应该跟网页调试差不多了，加入使用javascript做脚本引擎，一旦脚本有问题了，rhino也会抛出各种错误。当然，如果这项目实现出来了，也会把错误定位这块儿给尽力做出来的。