创建没有模型的对象，而创建需要在其他表中创建多个条目

In application user can enter new post which contain title, content of the post and category of post. So creating new post will be through some simple html form with few fields. Now i don't know where to put logic for creating new post for following reasons:

在应用程序中,用户可以输入包含标题,帖子内容和帖子类别的新帖子。所以创建新帖子将通过一些简单的html表单,几个字段。现在我不知道在哪里放置逻辑来创建新帖子,原因如下:

Post(or posts collection) is object which is constructed from different tables, for example.

Post(或posts集合)是例如由不同表构造的对象。

@posts = User.joins(entries: [{storage: :vote}, :category]) 
             .where("votes.count > ?", 0)
             .select("users.username AS username,
                      storages.id AS storage_id,
                      storages.title AS title, 
                      storages.content AS content, 
                      votes.count AS votes, 
                      categories.category_name AS category_name")
             .order("votes.count DESC")

So when user create new post application must create new entries in different tables:

因此,当用户创建新的应用程序时,必须在不同的表中创建新条目:

1.Create new entry in entries table. (id, user_id, category_id)
2. Create new entry in storages table.(id, title, content, entry_id)
3. Create new entry in vote table.(id, count, storage_id)

1.在条目表中创建新条目。 (id,user_id,category_id)2。在存储表中创建新条目。(id,title,content,entry_id)3。在投票表中创建新条目。(id,count,storage_id)

In situation where post is model i can use something like resources: posts then in posts controller through new and create i can create new post, but what in situation like this where i don't need posts controller nor post model? So, question is: which place is more appropriate to put logic for creating new post? Q1

在帖子是模型的情况下我可以使用类似资源的东西:帖子然后在帖子控制器中通过new和创建我可以创建新帖子,但在这样的情况下我不需要帖子控制器或发布模型?所以,问题是:哪个地方更适合用于创建新帖子的逻辑? Q1

My solution is to craete Storages controller with resource: storages, :only => [:new, :create] then through new and create of this controller to populate different tables in db? I'm forcing here only because i dont see any point of other CRUD actions here(like showing all or one storage), because i will not use storages individually but in conjunction with other tables. So from views/storages through new.html.erb and create.html.erb i can construct new post? Q2

我的解决方案是使用资源来创建存储控制器:存储,:only => [:new,:create]然后通过new和create这个控制器来填充db中的不同表?我在这里强迫只是因为我没有看到其他CRUD动作的任何一点(比如显示全部或一个存储),因为我不会单独使用存储,而是与其他表一起使用。所以从视图/存储到new.html.erb和create.html.erb我可以构建新帖子吗? Q2

Another solution is to create Post controller which doesn't have "corresponding" post model as i stated before. Here i'm guessing i can't use restful routes(CRUD) because there is not :id of post? I only can make manually non-restful routes like:
post 'posts/create/:title/:content/:category' => 'posts#create', :as => 'create_post' then from params[:title], params[:content] and params[:category] to populate other tables. Q3

另一种解决方案是创建Post控制器,其不具有我之前所述的“对应”后置模型。在这里,我猜我不能使用宁静的路线(CRUD),因为没有:发布的ID?我只能手动制作非宁静的路线,例如:post'posst / create /:title /:content /:category'=>'posts #create',:as =>'create_post',然后来自params [:title],params [:content]和params [:category]填充其他表。 Q3

Im new to rails so dont yell please :D

我是铁杆新手所以请不要大叫:D

2 个解决方案

#1

This sound like a call for nested forms, its covered in a screen cast here.

这听起来像是对嵌套表单的调用,它覆盖在这里的屏幕上。

You use the resources of the top model, in this case Entry. and drill down to the 3rd model.

您使用*模型的资源,在本例中为Entry。并深入到第3个模型。

Simple sample of what to do is bellow. Model should look like so,

下面简单的做什么样本。模型看起来应该是这样的,

entry.rb

class Entry < ActiveRecord::Base
  has_many :storages, :dependent => :destroy
  accepts_nested_attributes_for :storages, :allow_destroy => true
end

storage.rb

class Storage < ActiveRecord::Base

  belongs_to :entry
  has_many :votes, :dependent => :destroy
  accepts_nested_attributes_for :votes, :allow_destroy => true
end

vote.rb

class Vote < ActiveRecord::Base
  belongs_to :storage
end

and the form should look like so, in simple_form style

并且表单应该是这样的,以simple_form样式

<%= simple_form_for @entry do |f| %>

  <%= f.simple_fields_for :storages do |storage_fields| %>
    <%= storage_fields_for :votes do |vote_fields| %>

    <% end %> 
  <% end %>
<% end %>

and if you have all the models set up, you shouldn't have to do anything to the controller.

如果您设置了所有模型,则不必对控制器执行任何操作。

This approach is also nice because you can add multiple storages and votes ajax style(without reloading the page) if needed, which is always nice.

这种方法也很好,因为如果需要,你可以添加多个存储并投票ajax样式(无需重新加载页面),这总是很好。

#2

I'd use a form class instead of nested attributes any day, see http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ for an example of this pattern (Chapter "3. Extract Form Objects")

我会在任何时候使用表单类而不是嵌套属性,请参阅http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/作为示例此模式(“提取表单对象”一章)

I've used the pattern often enough to gemify it https://github.com/bbozo/simple_form_class and it's used roughly in this way: https://gist.github.com/bbozo/5036937, if you're interested to use it I'll push some docs

我经常使用这种模式来创建它https://github.com/bbozo/simple_form_class并且大致以这种方式使用它:https://gist.github.com/bbozo/5036937,如果你有兴趣使用它我会推送一些文档

EDIT: reason why I tend to go the form class route most of the time is because nested attributes never failed to bite me in the end, either because strong parameter handling got cumbersome, or validators get too complicated (if persisted? else ...), or persistence logic needs to be extended to support some little knack that resolves into callback hell or recursive saves in the model (before/after save spaghetti troubles)

编辑:为什么我倾向于大多数时间去表单类路由是因为嵌套属性最终永远不会咬我,因为强参数处理变得麻烦,或验证器变得太复杂(如果持久化?其他... ),或持久性逻辑需要扩展,以支持一些小诀窍,解决回调地狱或模型中的递归保存(保存意大利面条故障之前/之后)

#1