求软件界面描述解决方案 + 讨论现有的界面描述技术

题3501031的标题是： 求软件界面描述解决方案 + 讨论现有的界面描述技术 (300分)
分类：编程心得

creation-zy (2006-07-10 09:29:00)

现在的软件界面多是像Delphi这样在运行之前就确定了（或者说基本确定）的。我们想做 成可配置、可扩充的（比如说，要加一个编辑框、按钮乃至窗体什么的，不用改源代码，也 不用进行任何形式的“编译”，直接生效）。  我们的想法是：软件界面有很多种——WinForm、网页乃至字符终端界面、游戏界面等， 都是UI。UI有多种不同的类型，每个类型又有不同的风格。而不同的风格所对应的用于描述 元素的要素可能都有差异。总之比较头晕。  最近新出来了XForm等标准，还没来得及仔细研究，有了解这些新技术的朋友吗？能否说 说他们的优缺点以及适用范围？谢谢大家了！

陆少 (2006-07-10 09:59:19)

你加了东西就必须得写代码，要不你加来有什么用？？就是放着看的？

tianhf (2006-07-10 10:37:00)

要加一个编辑框、按钮乃至窗体什么的---很简单,但是相对应的事件触发程序该怎么办呢？

creation-zy (2006-07-10 11:11:54)

呵呵，代码的事情不用担心——我们正在构造基于描述的过程执行机制。就目前的进展而 言，绑定界面元素与内存中的域/方法易如反掌:)

网中戏 (2006-07-10 12:02:05)

有皮肤控件啊

寻路 (2006-07-10 13:51:49)

可以使用sc_DragMove消息.

蓝叶菱 (2006-07-10 14:15:06)

现在通用web界面，扩展性好。。不需要改代码。

creation-zy (2006-07-10 16:56:53)

Web界面是好，但是还是需要编写HTML代码啊——摆脱不了“人”的劳动... 我们的想法 是，“告诉”系统某个界面多了一个元素，系统就能自动或者半自动的生成新界面——让系 统成为“助手”，而不是“工具”。

田伯光 (2006-07-12 13:42:00)

你所说的这种方案，我们现在有在用不过是在C#的WebForm中。里面有很多的东西，涵盖设计模式，单元测试，重构，迭代等各种办法。 其中，描述控件的方式采用的是Xml，在我们进行了很长一段时间的这种编译时到运行时的转换以后发现。当这种编译时转换到运行时有形成太多的运行时代码后又产生了其他问题，例如这些配置代码的有效性判断，调试性处理等各种东东都少了不少。 所以在这当中编译时和运行时需要一个度，切不可完全依赖于运行时的东东，但是完全编译时也会带来如你所说的问题，因而其实这个度，才是最重要东东。 欢迎大家一起探讨，我的MSN:leiyangcl@hotmail.com

duhai_lee (2006-07-12 14:12:34)

每种界面需要一个引擎吧， 如，普通form界面和web页面，肯定是不同的东西。 每种界面的配置，产生，管理，需要自己的引擎。每种引擎是派生自抽象引擎。  配置应该保存在xml。 便于管理和扩展。

creation-zy (2006-07-12 17:47:07)

谢谢大家:)  XML是一种可行的方案，但是我更加倾向于关系型数据库——因为做为文本，XML的内容几 乎是不可控的，难以进行规范。而采用了知识库技术的关系型数据库可以在表达任意复杂结 构的同时允许进行极为完备的语义级约束。  我们现在的方案是：针对几种典型的应用，给出相应的空白模板——框架以及基本功能都 有了。然后，利用元知识在空白处生成针对具体界面的控件。不过，现在的界面还是完全依 赖于数据结构的描述，没有独立出来（比如，在一个界面上同时存在多个相关的不同数据对 象）。 Go on~~  :-)

蓝叶菱 (2006-07-12 17:51:33)

XML开发成本高，而且很少人用。界面可以使用好的架构，方式就是一般的网页最好。 菜菜的观点。

kalvin666 (2006-07-12 21:16:48)

guan zhu

chefee (2006-07-12 21:43:38)

复制DELPHI设计器方法,别忘了DELPHI本来就是个EXE

z_cd (2006-07-13 09:38:53)

Delphi 的窗体文件 *.dfm 格式，不行吗？我现在就是用它动态生成界面，界面的配置与更换直接换一个 dfm 文件就行了。 网页 Web 这种方式，总是在项目中觉得不够用，用户的操作需求很高的，比 Word、Excel 做地灵活，他们觉得是必要条件。

ProLove (2006-07-17 13:40:26)

同意楼上的观点，针对DFM格式，将将生成代码放到数据库里，再统就好

raylo (2006-07-17 14:43:58)

关注中，最近也在考虑这个问题

iseek (2006-07-17 14:50:27)

XForm标准是什么新东东？听课. 简单的界面用浏览器好办.但菜单啊树啊什么的不大好弄吧？不知哪位有比较详细的DEMO？

人在昆明 (2006-07-19 09:04:34)

我也觉得xml是比较可行的描述界面的方案，关系数据库有一点的局限性。

a99168 (2006-07-19 15:13:11)

以前考虑过这方面的问题，“动态界面”。 将界面描述语句放进数据库，运行时动态生成界面。 核心问题是必须内嵌一个pascal语言解析器。 太难了，后来放弃了。

creation-zy (2006-07-21 09:55:56)

a99168兄，俗话说磨刀不误砍柴工啊。况且Pascal解释器网上有免费的，非常好用的。  xml只是一种具有层次结构的数据的存放规范，不是数据本身的规范。现在我们需要对数 据本身进行规范，至于以后用什么来存储，无关紧要啊。

creation-zy (2006-08-05 20:30:34)

看来关心这类理论问题的人不多啊...  最近已经基本完成了内核的进化，准备初步搞一个基于Excel这样的二维表格的界面...  ID, ParentID, Row, Col, RowSpan, ColSpan, CtrlType, FieldID  大概就是这些了吧？...

z_cd (2006-08-10 10:01:38)

楼主是看了郭大虾的东东，受到启示准备搞 基于Excel这样的二维表格的界面 吧？ 恩，不错，最好带数据感知功能，做到界面与数据分离

寻路 (2006-08-10 18:25:26)

不知道会做成什么样子,说实在的,我到现在还没有明白creation-zy你要做什么!

a99168 (2006-08-10 18:45:02)

需求来自： 编软件界面太累了，几十个form大部份是相同的，一丁点的界面调整就要修改很多地方， 调整的过程中还可能改动了不想改的地方。 这个是有前途的。

dreamfly1024 (2006-10-01 14:29:23)

从通用性上来讲，基于字符的语言是最终的归宿，这就正如描述算法一样，语言仍然是最好的。 虽然看起来，某种可视化界面可以帮助用户描述算法和界面，但是通用性并不好，徒增加复杂性而已。 从应用系统来讲，基于工作流引擎的系统已经是可配置的极限了，超过这个极限，其复杂度和成本会急剧上升，最终你不得不回到原来的起点上。

dreamfly1024 (2006-10-01 14:33:11)

我们最近开发了一种新的语言：Nuva 语言，完全采用 Html/Xml 作为界面引擎，你只需在 Nuva 代码中嵌入相应的界面元素（Html/Xml 或者说在 Html 中嵌入 Nuva 代码），指定一些绑定属性，一切你就不用管了，你只需写你的业务逻辑就完了，巨方便啊。 详情请参考： http://www.cnblogs.com/wisdom-zh http://www.macrobject.com

kxgkxg (2006-10-03 00:51:48)

将对象的类别，属性，每一项都作为一条记录，放在数据库中，再写一段代码解释就可以了

raylo (2006-10-03 20:56:23)

同意dreamfly1024的看法，对于通用性的追求只能是有限的，太过复杂的话又会绕回来。对于界面，觉得能采用表格方式来排版与设置、并能通过代码生成就已经是很方便了

linlin3 (2006-10-03 21:30:32)

什么时候人不用吃饭就能活下去？

creation-zy (2006-10-18 14:17:15)

>>从应用系统来讲，基于工作流引擎的系统已经是可配置的极限了，超过这个极限，其复杂 度和成本会急剧上升，最终你不得不回到原来的起点上。  老夫就是要将这个曲线由几何级数曲线变成对数曲线，嘿嘿:P  另外，就是单说工作流系统，还有很多东西可以挖掘的，不是放点、连线那么简单。  关于语言，我们已经超越了语言的层次，理论上可以将任易语言的任意特性集成进来，没 有任何限制。现在我正一边搞开发一边汲取别的语言的理念——北冥神功 :D  可以与Java、.Net、Delphi等流行语言以及基于其上各种高级的Mapping框架相提并论的 业务模型、界面模型体系结构，我们现在已经思考的相当成熟了。就等产品推出的那天放分 了，呵呵:)