OSGi + XML = XML应用程序？

OSGI 与XML 关联还是OSGI 吗？

运用XML 配置 后 OSGI 还能热插热拨吗？

OSGI是模块化开发最重要是理清bundle引用依赖关系 ,bundle关系理顺了模块功能找分清楚了才能事半功倍，in mind bunlde 就是一个服务 应该是自包含 可描述的

为什么要跟XML扯上关系 ，我讨厌动不动就拿XML搞事 本来基于XML 的java 配置已经多的让人无所事从了。。

还有人说OSGI 不能调试 ，我想问这些人有没有真的去动手试下OSIG 啊。。

看不下去了。。。你们这些人不要来侮辱OSGI。。。

可能我没写清楚,我的意思其实就是开发效率,一个程序不单只有界面,Java在描述业务逻辑方面要比HTML强,也要比javascript强.

我认为Flex,WPF的价值并不是在新手也可以轻松使用上,而主要是在重用UI组件,和UI组件的组织上.
如果你需要定制特殊组件,那么你还是得用低层API去写代码(很可惜,浏览器规范就没有提供2D的API),在这一点上结构性的标记语言帮不了你什么忙.

不需要这样的框架,IDE也提供一些可视化编辑(VE),这些工具对于新手或者组件定制化要求不高的人来说,已经足够了.

想法到挺独特

OSGI只是实现了部分.net framework已经实现的功能

我想请教你 osgi 跟 .net framework 有什么关系


哎 我连osgi是什么都不懂了。。。。。。。。

 

 

真正能做到热插拔的是在Service Layer，这个在我之前的博客中已经讲到了，Core Layer 是做不了的，如果真能做的话，Eclipse每次安装新的插件也就不用重启了。

 

本文的XML，是充分利用了OSGi的插件加载机制，通过namespace与bundles进行关联。个人感觉真是个比较好玩儿的事情... 呵呵

 

 solonote 写道

 

至于开发效率呢：

 

1. 如果只是写一些很常用的软件界面，是写几行XML代码（新建个xml文件，打开文本编辑器（如notepad），然后写代码）快还是写Java代码（打开IDE创建个Java项目，新建个Java类，然后写代码编译最后运行出来）快呢？结果很明显，至于像调试问题，完全取决于未来实现的解释器的支持程度，跟XML本身没什么关系。

 

2. 如果需要写比较复杂的界面，我倒是希望未来能做出来个可视化设计器，就像现在Java的一些设计器一样，只不过生成出来的是XML代码，我想开发这东西应该比生成Java代码要容易吧。

 

我认为如果插件中实现的常用功能能解决80%的需求就足够了，就像HTML一样，它本身也只是有那么几个常用组件而已，对于复杂的UI组件，HTML使用的是CSS/JavaScript扩展，而理想中的XML应用程序，还可以像你说的用底层API去写代码进行扩展，当然业务逻辑也可以这样（大部分时候的原因是考虑到其保密性）。

 

我个人认为XML应用程序是双击本地运行的，而不是在浏览器上运行。

 

.net framework = jdk + osgi

to lz:

不建议将UI生成与OSGI相关联，原因很简单，不够专注。你既无法与专注UI生成的JFormDesginer、Netbeans等等竞争，也将在OSGI模块化、可插拔化上丧失太多。

如果实在要做，我建议你分成两个无关的独立框架来设计：

1)一个专注于UI生成，可以用XML描述，但必须生成JAVA code（因为以个人的经验看大部分UI生成的代码都需程序员手工修改，这样做也更灵活）。框架设计前功能建议参考一下竞争对手，如果你认为没能力比他们做的好那还是放弃吧（出于兴趣练手除外）。
2）一个专注于基于OSGI的Swing插件应用快速程序开发（也可以包括SWT等其他实现方式）。OSGI热插拔特性我认为在桌面应用中极为重要，新插件插入，非Core插件的更新，这些都可以做到不重启应用。基于OSGI的框架设计不应仅仅包括UI机制（不是UI生成，可以为View生命周期管理、docking支持等等其他特性），Plugin机制、Resource机制、Event机制、I18N机制、异常处理机制、数据库机制、皮肤机制等等也是必不可少的。另外如果要支持企业级的CS架构开发，Net访问机制（包括数据的推与拉，还要考虑穿越防火墙）、插件自动下载与升级机制、权限机制、缓存机制甚至离线浏览机制也要必须提供。

目前框架2的swing开源实现比较少，个人认为还是可以一做的。

你也不怕闪掉了牙，你查查Java什么时候出来的，OSGI又是什么出来的，.net除了抄袭还会什么？
这里是 Java编程和Java企业应用版，你该回哪回哪里去吧。