300行代码你能做什么

这一点说得有道理，但这正是代码生成界面的潜力所在。一个精心设计的框架可以使它变得不乏味。
例如：

menu_bar do
  menu 'File', :item => ['Open', 'Close', '_', 'Quit']
  menu 'View', :item => ['Copy', 'Edit']
  menu :item => ['About'], :layout => :last
end

我不认为上面的代码会比可视化编辑菜单更乏味。

（注：GtkSimpleLayout目前还不支持以上代码，它还是v0.1.x呢)




我说的可以从数据库中生成界面不是针对.NET FORM或任何一种语言，而是针对“可视化”。如果可以“可视化”地动态生成界面，那么用代码生成界面就没有这个优势了。

WPF果然很好很强大，不过这些好像和我始终表述的观点没有什么关系啊，你要是从头开始看这个贴你就可以看到我的观点是：

1. 一个合适的布局器使代码编写界面很直观，不乏味，大大弱化“可视化”在编写UI程序的重要性，很多时候“可视化”根本不需要。
例如我反驳


我反驳


我反驳



2. 代码可以动态生成界面，而“可视化”缺少这样的灵活性。
3. 代码生成界面可以用普通的代码版本管理工具就可以跟踪变化记录，并且具有良好的可读性。

你举的WPF的例子（1）既不能说明“可视化”如何优于代码生成界面，（2）也没有反驳代码可以动态生成界面而“可视化”不能（实际上你的例子反而是支持了代码生成界面的做法，只不过C#没有builder-style方式而已）。（3）WPF使用XAML表述UI，由于XAML体现UI层次而且是文本，因此在UI变化后是可以在diff上看出来，这是一个进步。不过WPF XAML的可读性如何，以及是否优于代码（特别是动态语言）值得探讨。

本文起由于RubyGnome2的代码体现不出UI的实际样子，因此有了GtkSimpleLayout，可以让代码和UI高度一致，从而使大部分情况下不用Glade。由此再延伸到关于代码生成界面和“可视化”编辑界面的讨论...RubyGnome2的案例并不一定是适用于其他情况，但应该有参考价值。我的观点只是抛砖引玉，大家接着来。

我的关于“可视化”不能动态生成界面的观点在VS/WPF面前不完全正确，subwayline13提供的例子中，WPF的定制控件确实是在代码的支持下“可视化”地生成了界面！这的确是个好主意，well done MS !

超过300行，内容已删除，另起一贴。

我不是期望这个几百行代码的东西能够替代VS或者和微软WPF叫板，但是作为程序员不要把眼光仅仅限于人家为你设定好的路线上，应该勇于尝试勇于思考。

如果你是程序员，请继续用代码说话，或者你至少要对这里所讨论的东西亲自尝试一下。

讨论问题的一个基本前提就是尊重别人的观点，有不同意见就有理有据的反驳，而不是马上论起大棒子。如果你没有讨论问题的心态的话，对你而言确实是空谈。

我喜欢这小工具，既然我拿了红宝石做锤子，自然想希望能敲多些钉子

除了god以外，没有人什么都懂，注意用词就是了，一个良好的讨论氛围尊重是基础。


注意我的原文，我说的是“不过WPF XAML的可读性如何，以及是否优于代码（特别是动态语言）值得探讨“，我不是拿XAML和builder-style比较，他们没有可比性。builder-style只是一种表达方法而已，它的作用是体现层次。XAML基于XML，已经体现了层次。关于XML和代码相比，其优劣点相信已经有很多讨论了。


清再仔细阅读我所说的，注意我的用词。
VS／WFP是让生成的界面在设计时“可视”了，但是生成界面的是后面代码所作的工作。所以我说“不完全正确”。

其实关于这个问题真的无须再讨论了。



1. 这里的人在工作中只使用MS工具开发的人可能真的不多，熟悉MS开发的人员却是不少，因此说”充满了偏见“是不公平的。

2. 我的确“亲自尝试”了，举手之劳而已，为什么不做？同样我也强烈建议你尝试一下RubyGnome2，花不了多长时间。

3. 只要MS认为有必要，我认为VS生成可读性很好的UI代码完全可以。问题是逆向（即：从可读性很好的代码转化为可视化编辑界面）比较困难。XAML应该是在“可读性”和“逆向方便性”之间取得了一个很好的平衡。
从早期的VB完全隐藏UI部分的代码，到.net winform允许你修改UI代码（不过要小心），到现在WPF用单独用XAML作为UI描述分离出来，MS在保持可视化的同时也在不断使对可视化的依赖程度下降。

由于目前VS支持的主流语言尚不能用来构建合适的DSL来描述UI，因此XAML是好选择。如果MS有更好的语言可以构建合适的DSL来描述UI，它替代XAML，大大弱化可视化也不是不可能的。



你完全没有理解我的观点，连重复我的观点都不会，只会用攻击性的语言，这样的讨论没有意义了。

管理员请锁了这贴吧。

赞成～ 可以的话人人都想偷懒用自动生成的代码 ～ 不是不想要可视化设计，而是现在的可视化工具没有或者不够好～不能让我们达到预期目的,仅此而已

仅仅以部分技术的情况，来评判整个可视化开发方式的好坏有点太过笼统了~

咱应该具体问题具体分析啦～

这样的菜单是简单又简单的，一个真正意义上的菜单，有快捷键，有图片，有子菜单，有enable/disable的属性，你在代码里敲敲看吧，看不出有什么必要开历史的倒车。

通过XML生成.NET form的界面，早在XAML之前，就有人发明了，首先这种生成需求到底有多少，其次扯上生成界面和DSL完全没必要，这主要原因是ruby是动态语言而已，.NET如果真要生成，也可以通过CodeDOM一行行, 也可以通过一个Form的模板生成后编译，甚至可以采用别人的经验，从XML把整个过程自动化。

一个大型团队，一个拥有重型界面的软件，都会要求一种分离界面和逻辑的开发方式，把图形设计师和程序员放在一张桌子前是不现实的。

图形设计师应该和产品设计师进行沟通，让程序员浪费时间找出应该把按钮放在什么位置是愚蠢的。