Ruby onRailsのウェルカム/ホームページ-ベストプラクティス

Question 1

私のホームページ（またはウェルカムページ）は、2つのモデル（著者と投稿と呼びましょう）のデータで構成されます。私はRailsを初めて使用しますが、これを実現するための最良の方法がわかりません。

著者と投稿からデータを収集し、それらをウェルカムインデックスビューに表示するwelcomeという新しいコントローラーを作成する必要がありますか？または、投稿モデルの下で、作成者からもデータを取得するウェルカムビューが必要ですか？またはこれを達成する他の方法はありますか？

私はこれらすべてを技術的に行う方法を理解していますが、railsフレームワークを使用したベストプラクティスの方法がわからないだけです。

Question 2

問題は、あなたのホームページは単なるランディングページなのか、それともページのグループなのかということです。ランディングページだけの場合は、他の場所に移動する場合を除いて、ユーザーがそこに長くとどまるとは思わないでしょう。それがページのグループであるか、既存のグループに類似している場合は、最も似ているコントローラーにアクションを追加できます。

現在のプロジェクトで行ったことはStatic、3つの静的ページが必要なため、という名前のコントローラーを作成することです。ホームページはこれらの1つです。他の場所に移動する以外に、表示したり実行したりすることは何もないからです。

デフォルトルートをマッピングするには、以下を使用しますroutes.rb。

# Place at the end of the routing!
map.root :controller => 'MyController', :action => :index

私の場合、これは次のようになります。

map.root :controller => 'static', :action => :index

必要に応じて、このホームページ専用のコントローラーを作成できます。私はそれをメイン、またはホームページに関連する覚えているものと呼びます。そこから、データとモデルを取得し、出力ビューに従うことができます。

class MainController < ApplicationController
  def index
    @posts = Posts.find(:all, :limit => 10, :order => 'date_posted', :include => :user)
  end
end

モデルの関係が正しく定義されていると仮定すると、それに一致するテンプレートは非常に単純になります。

頑張ってください、これが役立つことを願っています。

Question 3

ベストプラクティスは1つもないようです。

（1）標準config/routes.rbファイルは、ルートページ（またはホーム/ウェルカムページ）をwelcome#index。で処理することを提案しているようです。それによってガイドされる場合は、対応するwelcome#indexコントローラー/アクションを生成するために、次のコマンドを使用できます。

rails generate controller Welcome index

次に、でconfig/routes.rb、get "welcome/index"ジェネレーターによって自動的に追加されたGETルート（）を削除し、ルートルートroot 'welcome#index'（またはroot :to => 'welcome#index'Rails < 4）をファイルの先頭に配置できます。これはおそらく最も人気のあるルートであり、最初に一致する必要があるためです。

またpublic/index.html、Railsで削除することを忘れないでください< 4。

（2）レールルーティングガイドの公式ルビー使用PagesController。それは実際に示唆pages#mainしていますが、私にとっては一緒に行く方が理にかなっていますpages#home（「ホームページ」は遍在する用語/概念であるため）。また、このコントローラは、他の処理できるページ指向のようなアクションpages#about、pages#contact、pages#terms、pages#privacy、など

（3）Railsのチュートリアル上のRubyは、で行くstatic_pages#homeとstatic_pages#help、私は「静的」でこのコントローラを表すのアイデア好きではないものの、など、。これらのページ、特にホームページには、まだいくつかの動的な側面があります。

（4）それがどのように処理するかについては説明しませんが、ホームページを、半静的ページ上RailsCast＃117へのアプローチのさらに別の一連の示唆を示しのみのリソースを。

1または2、あるいはその両方を好むと思います。「and」シナリオでは、welcome＃indexやpages＃aboutなどを使用できますが、「or」シナリオでは、pages＃home、pages＃about、など。選択を余儀なくされた場合は、コードが少なくなるという理由だけでオプション2を選択します。ところで、「静的」という言葉を除けば、2と3はほとんど同じです。

Question 4

Railsを始めたとき、私はこのようなことを自問しました。知っておくべきことは次のとおりです。

モデルは、必ずしもコントローラーやビューに直接関連しているとは限りません。

つまり、特定のコントローラーとビューの組み合わせは、その特定のページを生成するために必要な数のモデルで機能します。

コントローラの目的は、データの保存に使用されるモデルに関係なく、表示する必要のあるデータセットを準備することです。

ビューの目的は、そのデータを最も適切な方法で表示することです。

言い換えると、コントローラーとビューの組み合わせが特定のモデルの下にあることはありません。それらはモデルを使用しますが、階層関係ではモデルの下にありません。実際、彼らは彼らが使用するどんなモデルの仲間でもあります。

混乱は、AWDRやその他の紹介テキストにあるスキャフォールドジェネレータの例から来ていると思います。

Rubyスクリプト/スキャフォールドモデルコントローラーの生成

モデルとコントローラー/ビューの間のこの暗黙の関係が私を少し混乱させたことを私は知っています。しかし、実際には厳密な関係はありません。もしあったとしたら、MVCアプローチで複雑なことをするのは非常に難しいでしょう。そして明らかに、そうではありません。

お役に立てれば。

-ジョン

Question 5

ベストプラクティスは、最初の提案です。'welcome'コントローラーを作成し、必要なモデルからレコードを呼び出します。そのコントローラーへのルートルートポイントを用意します。とても清潔で適切です。

Question 6

Rails3では、これを処理する正しい方法は、routes.rbファイルの最後に次の行を追加することであることに注意してください。

root :to => "welcome#index"

public /index.html.erbを削除します。

また、welcome＃indexはWelcomeControllerのインデックスアクションに対応し、The WickedFleaの回答のコードは次のようになることにも注意してください。

class WelcomeController < ApplicationController
  def index
    @posts = Posts.find(:all, :limit => 10, :order => 'date_posted', :include => :user)
  end
end

Question 7

この答えはRails3.2.1以降のものです。

まず、次のような名前のページ用のコントローラーを設定しますstatic。

$ rails generate controller static

ファイル内app/controllers/static_controller.rb：

class StaticController < ApplicationController
    def index       
    end
end

新しいビューファイルを作成します app/views/index.html.erb

そして最後にあなたのを設定しますconfig/routes.rb：

MyApp::Application.routes.draw do
   match 'home', :to => "static#index"
   root :to => "static#index"
end

これは、両方を行います/homeと/、あなたが作成したビューファイルに入れて何に行きます。

Question 8

できるだけ適切な名前の新しいコントローラーを作成します。SummaryController？StartController？DailyFrontPageController？あなたはアイデアを持っているでしょう。

それだけでなく、 ActiveRecordベースではなく、作成者モデルと投稿モデル（または実際の名前）から情報を収集してビューに表示する新しいモデルを作成することを真剣に検討したいと思います。別の方法は、コントローラーでデータをアセンブルすることです。これはほぼ間違いなく面倒です。試してみるたびに、何度も試してみました。別のモデルは、かなりきれいになってしまうようです。

処理が比較的簡単な場合は、最初にコントローラーでデータをビルドしてから、出力をStructでラップしてから、Structを実際のクラスに置き換えて、そこに構築を移動し、リファクタリングを行ってみませんか。合計時間にあまり多くを追加するべきではなく（ほとんどのコードは再利用できます）、何が最適かを理解できます。