【发布时间】：2011-05-08 07:19:57
【问题描述】：
我有一个项目，其中包含多个嵌套图像的内容类型（文章、采访等）。为了处理图片，我实现了一个弹出的“图片上传”框（使用 Paperclip 和 Uploadify 的组合），以便用户可以立即将图片上传到文章中。
流程如下：用户单击“上传图像”图标，然后弹出一个框，他们可以在其中添加回形针文件上传字段，以上传所需数量的图像。 Uploadify 会立即上传照片并为其分配所附的文章 ID 号。然后照片的 HTML 被发送到 WYSIWYG 编辑器。如果他们也想删除照片，他们可以。如果它听起来像 WordPress，那就是它的基础。
无论如何，我的这个工作很棒。照片与各自的文章保持关联并附加，而不是将所有内容都放在一个巨大的文件夹中（就像许多所见即所得的图片上传者所做的那样），任何人都可以添加/删除任何内容。
但这有一个小缺陷......正如我所说，在执行上传时，图像被分配了内容的 ID 号。好吧，您可以在创建全新文章时看到这是一个问题，因为新文章在保存之前没有 ID 号。所以图片上传失败。因此，整个过程仅适用于“编辑/更新”操作。
在此期间，我告诉团队确保先保存文章，然后当他们回去编辑时，他们可以将图片上传到正文。但很自然，他们会忘记，因为这是一件容易的事情，而且这对用户非常不友好，我必须解决这个问题。
我认为有两种方法可以解决这个问题。
为“新”表单上的文章分配一个 ID（隐藏字段或其他）。这会安抚上传者，因为它会填充错误的“nil”值，然后当第一次保存文章时，它会为其分配相同的编号。但是我看到了一个潜在的问题……如果另一个用户同时创建了一篇文章并且数据库为其分配了一个相同的 ID 号怎么办？
我注意到，当您创建新的 WordPress 文档时，新文档会立即“自动保存”为草稿。所以我的思路是这样的......当用户去创建一个新文档时，“新”操作实际上会触发一个“保存”操作，绕过任何验证错误（因为字段是空白的），然后立即重定向到“编辑”动作。这样一来，ID 将被保存，一切都会正常进行，并且整个过程对用户来说可能看起来是无缝的。
你会如何处理这种情况？就像我上面建议的那样，还是有更好的方法？
【问题讨论】：
标签： ruby-on-rails paperclip uploadify