Rails 3 - 应用程序布局问题

发布于 2024-11-06 17:20:07 字数 659 浏览 0 评论 0原文

我在理解 Rails 的一般应用程序布局时遇到了一些困难。

基本上,我正在制作一个用于足球比赛的网络应用程序。教练登录并进入 /coach/index 页面。在该页面上,他们可以使用 JavaScript 前端绘制他们的游戏等。我的问题是,为了保存游戏,我需要将该 JSON 发送到服务器,以将其记录到正确的 Play 数据库条目中。

  1. 我的布局在逻辑上正确吗?例如,登录的教练应该将他带到该页面,然后他在那里绘制比赛并保存它们、创建新比赛、加载它们等,还是我应该在比赛控制器控制的页面上执行此操作? p>

  2. 我想将播放绘图引擎生成的JSON保存到数据库中。执行此操作的最佳方法是什么?我看到的所有 Rails AJAX 教程都基于简单的表单,您可以在其中设置远程 =>他们的真实财产等等。如何在没有显式表单的情况下向 Rails DB 进行 AJAX POST/GET 并处理输入?

  3. 这可能是因为我缺乏 Rails 专业知识(我正在努力学习),但在您更有经验的观点中,什么是我确保正确播放的最佳方法创造它们的教练?我在理解控制器如何访问其他控制器控制的东西方面遇到了一些困难。我确信这种事情一定有一些约定。

我想得越多,我就越觉得登录应该把你带到 /plays 目录,我应该修改那里的 create 等,以便做我想做的事情。 提前致谢。

I'm having some difficulties getting my head around Rails' general application layout.

Basically, I am making a web app for football plays. Coaches login and get brought to the /coach/index page. On that page they can draw their play and such, using a JavaScript front end. My problem is, in order to save the play, I need to send that JSON to the server, to log it in the right Play database entry.

  1. Is my layout correct, logically? As in, should a coach logging in bring him to that page, and then he draws the plays there and saves them, creates new ones, loads them etc, or should I be doing this on the pages governed by the Play controller?

  2. I want to save the JSON generated by the play drawing engine to the database. What's the best way to go about doing this? All the Rails AJAX tutorials I see are based on simple forms where you set the remote => true property on them and such. How do I make an AJAX POST/GET to the Rails DB without an explicit form, and handle the input?

  3. This is probably down to my lack of Rails know-how (I'm trying to learn as I go), but what, in your more experienced view, is the best way for me to ensure the right plays get shown to the coach who made them? I'm struggling a little in understanding how controllers access things controlled by other controllers. I'm sure there must be some conventions for this kind of thing.

The more I think about it, the more it seems to me that logging in should take you to the /plays directory, and I should be modifying the create and such in there in order to do what I want to do.
Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

阪姬 2024-11-13 17:20:07
  1. 你的布局符合逻辑吗? /coaches 作为登录教练的目的地是有意义的。如果您的应用程序用户只是教练,那么即使是 root 也有意义。当教练登录时,他会进入某种形式的 coaches#show,但这并不意味着您仅仅因为 URL 类似于 /profile 就做错了什么>。并非所有内容都需要在 URL 方面遵守完整的 REST。在现实世界中,操作不会驻留在其自己的小而古怪的页面上。如果在 /coaches 页面上嵌套新的 Play 表单有意义,则您的 URL 不需要反映它。

控制器控制与资源的交互。在 /coaches 页面中,您仍将向 plays#destroy 发送删除比赛请求,并通过 plays#create 验证新比赛,这可以在失败时渲染“coaches/index”。

  1. 我从未真正处理过 Rails 中的 AJAX。

  2. 确保教练只看到自己的比赛的最佳方法是通过 Coach has_many :plays 关联来确定他们的范围。 Rails 身份验证解决方案(如 Devise)中的惯例是提供一个方法 current_user,该方法返回当前登录用户的 User 模型实例。

您的 coaches#index操作可能如下所示:

# Coaches controller
def index
  @plays = current_user.plays
end

那么您的视图可能具有:

# views/coaches/index.erb
<ul>
<% for play in @plays %>
  <li><%= play.name %></li>
<% end %>
</ul>

您不会做的事情:@plays = Play.where(:user_id => @user.id)

它还简化并保护其他操作。考虑:

@play = current_user.plays.new

@play = current_user.plays.build(:name => "My First Play")
redirect_to @play, :notice => "Success!" if @play.save

current_user.plays.find(params[:id]).destroy

要回答作为评论添加的问题:

# Coaches controller
def new
  @play = current_user.plays.new
end

def create
  @play = current_user.plays.build(params[:play]) # @play now already contains the association to the coach that created it.
  if @play.save!
    redirect_to # somewhere
  else
    render 'coaches/index'
  end
end
  • 如果您不熟悉Railscasts,我强烈推荐Railscasts。即使观看有关您不会很快实施的主题的剧集也会给您带来良好的曝光度。
  • 例如,下面是 Devise 上的 Railscast。 Devise 在 Github 上也有不错的文档。
  • 我最近在 Rals Best Practices 上购买了 CodeSchool 的课程。尽管其中一些内容可能超出您的直接掌握范围,但您可以随时重新访问它。我一直查阅附带的幻灯片来寻找更好的做事方法。
  1. Is your layout logical? /coaches makes sense as a destination for Coaches that log in. If your application users are only coaches, then even the root makes sense. When a Coach logs in, he's going to some form of coaches#show, but that doesn't mean you're doing something wrong just because the URL is something like /profile. Not everything needs to adhere to full REST.on the URL side. In the real world, not ever new action resides on its own little quaint page. If it makes sense to nest a new Play form on the /coaches page, your URL doesn't need to reflect it.

Controllers control interactions with a resource. From the /coaches page, you'll still be sending delete play requests to plays#destroy and validating new plays through plays#create which can render 'coaches/index' when it fails.

  1. I've never really dealt with AJAX in Rails.

  2. The best way to ensure that Coaches only see their own plays is to scope them through the Coach has_many :plays association. The convention in Rails authentication solutions (like Devise) is to provide a method current_user which returns an instance of the User model of the user that's current logged in.

Your coaches#index action could look like:

# Coaches controller
def index
  @plays = current_user.plays
end

Then your view could have:

# views/coaches/index.erb
<ul>
<% for play in @plays %>
  <li><%= play.name %></li>
<% end %>
</ul>

What you wouldn't do: @plays = Play.where(:user_id => @user.id).

It also simplifies and secures other actions. Consider:

@play = current_user.plays.new

@play = current_user.plays.build(:name => "My First Play")
redirect_to @play, :notice => "Success!" if @play.save

current_user.plays.find(params[:id]).destroy

To answer your question added as a comment:

# Coaches controller
def new
  @play = current_user.plays.new
end

def create
  @play = current_user.plays.build(params[:play]) # @play now already contains the association to the coach that created it.
  if @play.save!
    redirect_to # somewhere
  else
    render 'coaches/index'
  end
end
  • I highly recommend Railscasts if you aren't familiar with them. Even watching episodes on topics you're not going to implement anytime soon will give you good exposure.
  • For example, here's a Railscast on Devise. Devise also has decent documentation on Github.
  • I recently bought CodeSchool's couse on Rals Best Practices. Even though some of it might be beyond your immediate grasp, it's a resource that you can always revisit. I consult the slides that came with it all the time to look for better ways of doing things.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文