ans*_*gri 15 user-interface metaprogramming
我问的是模式,而不是框架.这是关于UI自动生成问题的后续行动.
您是否相信元数据中UI自动生成的概念？
这种方式可以解决哪些问题？
当我创建一个小型库以支持我的学生项目时,问题出现了,该项目基于对象的元数据在运行时生成交互式CLI.我认为它产生的CLI非常不错.
另一个极端是裸体对象框架,这是相当普遍的,但它产生的UI是可怕的,IMO.
很明显,每个问题都是特定的,需要特定的用户界面,但也许有几类问题可以接受自动生成？
Mic*_*rdt 15
是的,我相信基于元数据的自动生成应用程序的概念非常合理 - 主要是因为它通过减少大多数应用程序中的大量冗余来减少开发时间并提高代码质量,其中每个域数据字段都在数据库中表示,在模型中,在UI中,并且通常还在各种映射层中多次.
我认为未来是自动生成的应用程序,可以在必要时进行修改.目前,这是AFAIK真的不可能; 例如,Rails只允许您在使用静态脚手架时完全自定义UI,这基本上意味着代码生成,即域模型中的许多进一步更改不会自动在UI中表示,因为生成代码时发生了重复.
我相信第一个能够将完整的自动生成与完全可修改性结合起来的框架将成为以前未知程度的事实上的开发标准.虽然我们很可能会以小步骤到达那里,以便不会有这样一个统治框架.
看看JMatter,这是一个相当好看的Naked Objects实现.
还有Chris Muller关于MAUI的工作,以及Lukas Renggli关于Magritte(Squeak/Smalltalk)的工作
我们在应用程序的配置部分中有很多生成的UI.所有这些列表永远存在,并由系统管理员在蓝色的月亮中更改一次.
我发现大多数具有数据库后端的应用程序往往从OO和NO角度来看设计不好,如Pawson和Matthews的NO书中所示.
看待这个问题的一种方法是考虑从 Toad 或 MySQL 浏览器等工具获得的用户界面与熟练的设计人员所获得的用户界面之间的差异，在这些用户界面中，用户界面是直接从表及其关联的元数据构建的。为实际应用而开发。如果没有太大的不同，那么对于自动生成框架来说，它应该是相当容易实现的目标。
正如您所说，有些问题可以很好地解决这种自动生成问题，而有些问题则不能。在我看来，关键在于您在用户界面中公开的实现模型（或其部分）如何映射到用户的概念模型。其次，通过一组有限的用户界面组件可以很好地表达应用程序的行为（假设这是一个通用的 UI 生成框架）。
这篇文章“用户界面的通用模型”可能会引起您的兴趣。