在 Objective-C 中从模型（a la django ModelForms）生成表单答案

【问题标题】：Generating forms from models (a la django ModelForms) in Objective-C在 Objective-C 中从模型（a la django ModelForms）生成表单
【发布时间】：2009-07-04 03:08:26
【问题描述】：

在与 django 合作大约两年后，我开始涉足 iPhone 开发。当我完成教程和阅读文档时，iPhone 开发中使用的各种库让我感到不便的一件事是为数据模型创建用户输入表单时所需的重复量。

我知道创建用户输入表单的两种常规方法：

在 Interface Builder 中创建一组与模型类上的属性相对应的 UITextField，并将它们链接到自定义表单控制器上相应的 IBOutlets。
使用自定义表单视图控制器类的表中的 UITextField 以编程方式创建表单视图。该类将与模型属性对应的名称列表保存在数组中，然后遍历数组以为每个表格单元格创建 UITextField。使用特殊的大小写来确定正在迭代的模型属性，并使用该信息创建具有相应 UILabel 和 UITextFields 的表格单元格。*

在两者中，只有第一个似乎对迭代开发很实用，第二个非常冗长并且（对我来说）阅读起来非常困难。借助 Objective-C 的内省功能，似乎可以编写接受模型类作为参数的代码，并在运行时根据该信息生成表单控制器（甚至可能是表单视图）。

所以我有三个问题：

除了我上面列出的两个模型之外，是否还有传统的替代方法可以为模型创建表单视图和控制器？我不喜欢上面列出的任何一种方法。
在 Objective-C 中运行时自动生成表单控制器/视图是否可行，还是我只是在找错树？
是否已经尝试或完成了这种自动生成？（有点谷歌搜索没有发现）

*我对此的主要参考来自第 9 章中的示例 #6：Apress 的导航控制器和表格视图“Beginning iPhone 3 Development”

【问题讨论】：

标签： iphone objective-c django cocoa-touch model-view-controller

【解决方案1】：

我现在正在解决同样的问题，就我而言，我有一组来自 WSDL 的复杂模型，并且有很多表单元素会不时更改。我绝对不想在代码或 IB 中手工填写表格。

Objective-C 是一种完全动态的语言，您绝对可以以完全动态的方式做您想做的事情。假设您的模型是 Core Data 模型，您可以使用 [[myCoreDataObject entity] propertiesByName] 之类的内容找到所有属性。然后，您可以遍历这些属性，根据它们的类型自动创建适当的表单字段。

然后，您将创建一个例如 UITableViewController 的子类，将 NSManagedObject 传递给它，它会自动创建一个与模型对象匹配的表单。

【讨论】：

谢谢 - 当我写这个问题时，我对 Obj C 很陌生，但一切似乎都表明你可以在 python 中做什么，你可以在 Obj C 中做。很高兴得到确认。也感谢代码 sn-p。
我认为在您拥有可管理的小型表单的情况下，使用 Interface Builder 会更好。但是在我的情况下，我正在查看具有几十个元素的几十个表单，在我的例子中是在 WSDL 中定义的，这在 IB 中实现是禁止的。另外，我知道它们将来会发生变化。

【解决方案2】：

您似乎想像编写 Django 网站一样编写 iPhone 应用程序，但两者完全不同。

以下是可可中 MVC 的简要介绍：

独立于任何控制器或视图编写模型类
编写一个将模型类存储为键的控制器（例如 -[MyController model] 和 -[MyController setModel:]）
打开界面生成器并设计您的视图。在控制器中使用绑定或代码使视图与模型交互

【讨论】：

我在上面描述了两种方法，用于创建数据输入表单以进入模型。我不确定您在这里写的内容与我在 #1 中描述的内容有何不同。
“将模型类的属性重新声明为一组 UIView 子类”听起来好像您将 UIView 子类放入模型中，这是错误的做法。我认为您的问题不够清楚，无法得到您想要的答案。
谢谢汤姆，我已经稍微修改了我的问题，你说得对，原来不够清楚。

【解决方案3】：

请记住，像 Django 这样的系统是基于完全脚本化的环境。语言结构可以在执行过程中多次动态创建、解释和重新解释。

业务规则和表单逻辑等概念可以在页面发送到客户端/浏览器时直接编写。

对于编译型语言，所有这些活动部分都必须预先创建并完全解析（大部分情况下）。大多数基于 UML 的经典源代码生成或基于模板的系统都是复杂的庞然大物，生成的代码非常难以使用。

MVC 模型和 Cocoa 和 Carbon 等库虽然可能不像 Django 中的技术那样“优雅”，但确实围绕解决一些相同挑战的需要而发展。

尽管存在其他替代方案，例如将 Objective-C 与 LUA 或 Python 等解释性语言结合是可行的。还有几个开源项目专注于构建完全动态的“无线”用户界面客户端，这些客户端位于基于服务器的系统之上，这些系统广播了界面外观和行为的详细信息。（我找不到项目，但我会编辑）

我不知道这方面有什么重大工作，我怀疑大多数普通的 iPhone 应用程序在范围或可变程度方面都不够复杂，不足以保证创建这些自动化系统的努力。

用户界面很少是 iPhone 应用程序的复杂部分，也许除了一些独特的游戏。

巴尼

【讨论】：

感谢您周到的回复，您知道 - 正是因为您所说的“用户界面很少是 iPhone 应用程序的复杂部分”，我认为您必须重复这些无聊的细节一遍又一遍可能是抽象的候选者。不应该是这样吗？案例在通用时按惯例隐式处理，当它们变得复杂和特定于应用程序时被覆盖。对吗？ ...伙计们
为了进一步说明你的观点，Barney，我认为 iPhone 开发者许可协议禁止在 Cocoa Touch 环境中使用解释性语言。
我对法律文件中的引用很熟悉，但我相信它并不像听起来那么严格（我当然不是法律专家）。至少有两个用于 iPhone 的商业引擎包括脚本引擎，并且一些产品已经附带了基于 LUA 的内核。 Apple 禁止运行用户生成的代码或动态代码（可能与审查的产品不同），但似乎允许解释器在某些严格的限制范围内。
我只是给了这个答案，因为与像 python 这样的脚本语言相比，Objective-C 不够动态是完全错误的。事实上，ObjC 完全有能力做你想做的事，并且和 python 或 ruby 一样动态，尽管在你做的时候语法可能会有点混乱。
@sbwoodside - 实际上我也更新了我的想法。我正在使用我为 Cocos2D 创建的动态系统非常成功。它本身不是“脚本”，但它确实提供了创建“动态”内容的能力。我已经很久没有回到这个问题了，我已经忘记了它。许多道歉。 @quartz - 你是对的，但苹果为“刻录”的脚本内容留下了一些灰色区域。现在有几个程序使用 Lua 和 Python，只要脚本在发布后不能更改。

【解决方案4】：

实际上，这是解决同一问题的两种方法，而且哪一种都不比另一种更正确。你当然可以很容易地完成第一个——ObjC 是一种完全动态的语言。

但是，我个人建议不要“与框架抗争”。就像在 Django 中完全可以采用路线 #2 一样，该框架并不是围绕该方法构建的，您最终会编写很多您不必编写的代码。

Cocoa 的方法——路线#1——当然有它的优点。我强烈建议给它一个机会。

【讨论】：