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

  • 主题发起人 主题发起人 creation-zy
  • 开始时间 开始时间
C

creation-zy

Unregistered / Unconfirmed
GUEST, unregistred user!
现在的软件界面多是像Delphi这样在运行之前就确定了(或者说基本确定)的。我们想做
成可配置、可扩充的(比如说,要加一个编辑框、按钮乃至窗体什么的,不用改源代码,也
不用进行任何形式的“编译”,直接生效)。
我们的想法是:软件界面有很多种——WinForm、网页乃至字符终端界面、游戏界面等,
都是UI。UI有多种不同的类型,每个类型又有不同的风格。而不同的风格所对应的用于描述
元素的要素可能都有差异。总之比较头晕。
最近新出来了XForm等标准,还没来得及仔细研究,有了解这些新技术的朋友吗?能否说
说他们的优缺点以及适用范围?谢谢大家了!
 
你加了东西就必须得写代码,要不你加来有什么用??就是放着看的?
 
要加一个编辑框、按钮乃至窗体什么的---很简单,但是相对应的事件触发程序该怎么办呢?
 
呵呵,代码的事情不用担心——我们正在构造基于描述的过程执行机制。就目前的进展而
言,绑定界面元素与内存中的域/方法易如反掌:)
 
有皮肤控件啊
 
可以使用sc_DragMove消息.
 
现在通用web界面,扩展性好。。不需要改代码。
 
Web界面是好,但是还是需要编写HTML代码啊——摆脱不了“人”的劳动... 我们的想法
是,“告诉”系统某个界面多了一个元素,系统就能自动或者半自动的生成新界面——让系
统成为“助手”,而不是“工具”。
 
你所说的这种方案,我们现在有在用不过是在C#的WebForm中。里面有很多的东西,涵盖设计模式,单元测试,重构,迭代等各种办法。
其中,描述控件的方式采用的是Xml,在我们进行了很长一段时间的这种编译时到运行时的转换以后发现。当这种编译时转换到运行时有形成太多的运行时代码后又产生了其他问题,例如这些配置代码的有效性判断,调试性处理等各种东东都少了不少。
所以在这当中编译时和运行时需要一个度,切不可完全依赖于运行时的东东,但是完全编译时也会带来如你所说的问题,因而其实这个度,才是最重要东东。
欢迎大家一起探讨,我的MSN:leiyangcl@hotmail.com
 
每种界面需要一个引擎吧, 如,普通form界面和web页面,肯定是不同的东西。 每种界面的配置,产生,管理,需要自己的引擎。每种引擎是派生自抽象引擎。 配置应该保存在xml。 便于管理和扩展。
 
谢谢大家:)
XML是一种可行的方案,但是我更加倾向于关系型数据库——因为做为文本,XML的内容几
乎是不可控的,难以进行规范。而采用了知识库技术的关系型数据库可以在表达任意复杂结
构的同时允许进行极为完备的语义级约束。
我们现在的方案是:针对几种典型的应用,给出相应的空白模板——框架以及基本功能都
有了。然后,利用元知识在空白处生成针对具体界面的控件。不过,现在的界面还是完全依
赖于数据结构的描述,没有独立出来(比如,在一个界面上同时存在多个相关的不同数据对
象)。
Go on~~ :-)
 
XML开发成本高,而且很少人用。界面可以使用好的架构,方式就是一般的网页最好。
菜菜的观点。
 
复制DELPHI设计器方法,别忘了DELPHI本来就是个EXE
 
Delphi 的窗体文件 *.dfm 格式,不行吗?我现在就是用它动态生成界面,界面的配置与更换直接换一个 dfm 文件就行了。
网页 Web 这种方式,总是在项目中觉得不够用,用户的操作需求很高的,比 Word、Excel 做地灵活,他们觉得是必要条件。
 
同意楼上的观点,针对DFM格式,将将生成代码放到数据库里,再统就好
 
关注中,最近也在考虑这个问题
 
XForm标准是什么新东东?听课.
简单的界面用浏览器好办.但菜单啊树啊什么的不大好弄吧?不知哪位有比较详细的DEMO?
 
我也觉得xml是比较可行的描述界面的方案,关系数据库有一点的局限性。
 
以前考虑过这方面的问题,“动态界面”。
将界面描述语句放进数据库,运行时动态生成界面。
核心问题是必须内嵌一个pascal语言解析器。
太难了,后来放弃了。
 

Similar threads

回复
0
查看
873
不得闲
S
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
911
SUNSTONE的Delphi笔记
S
后退
顶部