为什么直接操作 Rails 表单参数哈希被认为是代码异味？

Question

我有一个 Rails 表单，其中包含一个父模型和另一个模型的可能多个子节点的嵌套属性。

子模型有一个属性，该属性在逻辑中作为数组进行操作，但使用 Rails 内置的序列化方法序列化为 YAML 字符串。

在表单中，我显示了数组的每个单独成员，以便用户可以选择性地删除成员。

当用户销毁所有成员时会出现问题。表单不会将参数的任何值传递给 Rails 控制器，当调用 UPDATE 操作时，它会忽略该属性，因为在表单参数哈希中没有它的键。这当然是复选框之类的已知问题，因此 Rails 会自动为每个复选框放置 2 个复选框 HTML 元素，一个隐藏的只有在复选框被选中时才会处理。

我在这里处理的不是复选框，而是隐藏的输入文本字段。

我实现的解决方案是直接在控制器的 UPDATE 动作中操作 params 哈希，像这样：

params[:series][:time_slots_attributes].each { |k,v| v[:exdates] ||= [] }

这算不算代码异味？

我是否应该添加一个额外的隐藏字段，该字段已禁用并且仅在用户删除最后一个成员时才启用？这个解决方案也很有效，但对我来说似乎很笨重。

Answer 1

这远不是一个详尽的答案...但是在考虑了这个问题之后，我可以看到一个问题是，如果将来构建利用相同 UPDATE 操作的表单，则会发生意外行为，这违反了最少原则惊喜。如果稍后构建第二个表单，它不希望更改 exdates 属性的值（因为它没有传递它们），则 UPDATE 操作无论如何都会将一个空数组写入该属性。

我决定通过添加一个具有真正布尔值的隐藏表单字段来解决此问题，然后在将所有时隙 exdates 设置为空数组之前检查该值。这样，如果未来的开发人员创建了一个利用系列控制器的 UPDATE 操作的新表单，他们将不会遇到将其 exdates 设置为空数组的意外行为。如果他们想在他们的表单中处理 exdates，他们需要具有相同的隐藏表单字段和真值。这似乎是一个更简单的解决方案，然后为 exdates、migration 和 AR 关联添加一个类和表，并添加另一层嵌套属性，这样我不仅有父属性和子属性，还包含父、子和孙子。这个解决方案有点像 Rails hack，用于处理带有第二个隐藏复选框字段的复选框。

Answer 2

这在 NestedAttributes 模块中通过允许“_destroy”参数触发对该特定嵌套属性的销毁调用来处理：

http://apidock.com/rails/ActiveRecord/NestedAttributes/ClassMethods/accepts_nested_attributes_for.

如果您没有使用嵌套属性（您可能应该使用嵌套属性，在很多情况下它都非常简洁），那么是的，您必须自己手动处理一些东西，通过确定哪些值应该 em> 一直在场并与他们一起做一些特别的事情。