問題タブ [nested-resources]

これらは私のモデルです：

ルートでネストされたリソースとして定義しました

その構造に一致するカタログにコントローラーとビューを配置したかった

社内に製品ディレクトリを作成し、電話をかけようとするとすぐに

私は得る

誰かが私が間違っていることを知っていますか？

Rails 3で一般的な構造上の問題が発生しており、新しいroutes.rbで少し混乱しています。ヘルプやガイダンスをありがとう。

ネストされたリソースを持つフォーラムアプリケーションがあります。セクション、トピック、および返信があります。ルート.rb構造は次のようになります。

私のsection.rb：

私のtopic.rb：

私のreply.rb：

そして、これは素晴らしく機能しています。今ここで私は混乱しています。

Deviseを使用してユーザーコントローラーを追加し、ユーザー名のログイン/ログアウトシステムが機能しています。'current_user'を返信やトピックに接続しようとしています。モデルを修正する方法については良い考えがあると思いますが、routes.rbファイルで何をすべきか非常に混乱しています。

user.rbの場合、「has_many：topics」と「has_many：replies、：through =>：topics」を追加する必要があると思います。そして、私のトピックでは、「belongs_to：user」を追加する必要があります。reply.rbは同じままだと思いますか？

ルートについては、私はちょっと困惑しています。ルートを編集してユーザーを追加すると、sectionid / username / topicid /のようなパスが得られますが、必ずしもそのようなルートにユーザー名を保存する必要はありません。したがって、セクションとトピックの間にユーザーをネストすることはできますか、それともroutes.rbファイルからユーザーを除外することはできますか。

Rails アプリのバージョニングの実装 モデルのすべてのバージョンを表示するビューに、元に戻すなどの追加機能が必要paper_trailです。バージョニングには gem を使用します。

すべてのモデルのようなコントローラー関数versionsとビューを作成することでそれを実行できることはわかっていますが、すべてのモデルに対して一度に実行したいと考えています。model.versions属性は常に同じように構造化されているため、これは可能なはずです。

理想的には、URL は次のようになります/pages/testpage/versionsがtestpage、 はページ ID です。

これは、レールのネストされたルートの概念に似ているようです。

ただし、ネストされたルートの問題は次のとおりです。

• モデルごとに追加の構成が必要
• testpageインスタンスであるモデルを知らずにオブジェクトにアクセスすることはできません。また、バージョン コントローラーに提供されるのは params ハッシュだけであるため、モデルを特定する方法を見つけることもできませんでした。

私は、最初のアイデアに従わない可能性のある代替ソリューションに対して完全にオープンです。

ネストされたルート（優れたURLヘルパー、アクセスなど）とaccepts_nested_attributes_forを使用したフォームのネストされたリソースを処理できると思いますが、両方を見ると、ルートで何を使用しますか？

そしてまた

これらの違いを教えてください。
明らかに、has_manyは1対多の関係のためのものです。パスヘルパーを生成し、正しいルーティングを必要としますか？ブロックする場合、それはどのような関係を意味しますか？パスヘルパー（/ schools / document）と、学校の下に複数のリソース（本、たとえばドキュメント以外）が必要な場合は、最初の方法でdo-endブロックに追加できますが、2番目の方法では2行だけです。 、has_manyごとに1つ？
ガイドとAPIを読んだことがありますが、ここでは違いや使用法がよくわかりません。2つの違いを明確に説明できる人は誰でも（「aはxを実行し、bはyを実行する」という形式で）すばらしいでしょう。 ）大歓迎です:)

ああ、そしてもちろん、それらがモデルにhas_manyを持っていることにどのように関係しているのか-したがって、これらの関係は、has_many、コントローラー（主にパスの使用による）、およびビュー（ネストされた属性を持つフォームを介して）を持つモデルにあると思います。

こんにちは、私は Rails チュートリアル ブックに従って、ユーザーと投稿、および投稿を表示するフィードを作成しています。ただし、著者はネストされたリソースを使用したことはありません。これは、レールで非常に重要であるように思われるため、自分でそれらの使用方法を発見したいと考えています。ただし、Ruby on Rails ガイドに従って投稿リソースをネストすると、その後、すべてのフォームとパスが壊れます。

最初からやり直すのではなく、ネストされたリソースに切り替えて、その過程で違いが何であるかを正確に学びたいと考えています。これについてどうすればよいか、誰か助けてもらえますか？助けてくれてありがとう。

特にフィードをどうするかは戸惑います。現在、feed_item は古い post_path を呼び出します。

shared/_feed_item パーシャル

マイクロポストコントローラー

これは、この章http://ruby.railstutorial.org/chapters/user-microposts#topのセクション 11.3.3 で開始され、この章の 12.3 で実際にビルドされますhttp://ruby.railstutorial.org/chapters/following -ユーザー#トップ

私は自分のアプリケーションのメッセージボードに取り組んでおり、それをすべて機能させるための典型的な3つのリソース、フォーラム、トピック、投稿があります。ルートは次のように定義されます。

トピックには、ネストされたリソースとして定義された投稿があります。新しいトピックを作成すると、スレッドを開始するための新しい投稿が作成されます。すべてがうまくいくように。しかし、私はトピックの「表示」ページで立ち往生しています。そのページでは、他の掲示板モデルと同様に、すべての投稿を表示した後、下部に新しい投稿/返信を追加するためのフォームがあります。投稿の作成アクションがトリガーされると、トピックなどにリダイレクトされます。そのフォームを実装することは、私がつまずいたことです。

通常、私はこのようなことを考えます...

...ページのみが「未定義のメソッド`topic_posts_path'」エラーを返します。そして、それは驚くべきことではありません。レーキルートを見ると、これが投稿の作成アクションとして返されます。

<％= form_for（[@ forum、@topic、@post]）do |f|を試してみようと考えました form_forの％>ですが、同じエラーが返されました。代わりに実際のパスを指定する必要があると考えて、<％= form_for：url => forum_topic_posts_url do |f|を指定しました。％>試してみましたが、それも気にしませんでした。

グーグルの後、ほとんどのフォーラムチュートリアルは時代遅れであるか、トピックページに新しい投稿フォームを追加することをやめ、私がすでに解決したほとんどすべてのものだけを表示しました。

私が明らかにすることができた他の唯一のことは、リソースを3レベル以上下にネストしないことを提案しましたが、「なぜ」の手前で止まり、ましてや適切な代替案を提案しませんでした。さらに、上記のルートパスは、この種のアクションの最も論理的なパスのようです。

では、この種の設定で投稿フォームをトピック表示ページで機能させるにはどうすればよいですか？

エラー：

No route matches {:action=>"new", :controller=>"comments", :parent_id=>1}

ルート.rb：

モデル：

見る：

コントローラ：

ancestryコードを読むことで、私がgemをネストされたリソースで動作させようとしていることがわかったかもしれません。私は祖先の宝石のRailscastsエピソードを使って私を導いてきました。私の質問を読んでくれてありがとう。

基本的なソーシャル ネットワーク機能を実装して、ユーザーが友達の追加、削除、フライドシップ リクエストの承認と拒否を行えるようにしようとしています。

私のユーザーリソースは次のようになります:

このルートを生成するuser_friend DELETE /users/:user_id/friends/:id

しかし問題は、 にアクセスする/users/1と、生成された へのリンクがdelete_user_friend_path次のようになることです。http://localhost:3000/users/5/friends/1

次の Web アプリ用に Rails 3 を取り上げます。

基本的に、ネストされたリソースのセットがあります。

ユーザー => アプリ => フォーム

前にセッションを使用して app_id を保持し、そのアプリ フォームにアクセスできるようにしました。

しかしその後、Rails 3 でネストされたルートを発見しました。Forms の後に別のレイヤーがある可能性があるため、3 ～ 4 回ネストされます。Rails ガイドhttp://weblog.jamisbuck.org/2007/2/5/nesting-resourcesを読んでいるときにこのリソースに出くわしました。

ネストされたリソースをレールで使用する必要がありますか?それとも、ネストされたリソースが大量にある可能性があるため、セッションの使用を開始する必要がありますか?

何かに頭を悩ませている。基本的に、私はグループのグループのグループのグループのグループを含む新しいプロジェクトを開始しています...そうですね。

いずれにせよ、アプリケーション全体である程度「普遍的」な唯一のモデルは、ユーザーの概念です (ユーザーは 1 人が持つ権限を決定するものであるため)。問題は、他のグループを「所有」できるグループがある場合に発生します。たとえば、「国家」支部が所有する「州」支部が所有する「市」支部を持つことができます。また、各支部は、その下にあるすべてのグループに対する権限を持つときに、独自のユーザーを持つことができます。 .

ただし、1 つのグループが別のグループによって所有 (または使用) されることが保証されているわけではないため、個別に管理する必要があります。この性質のものを処理するための方法論がどうなるかを完全に概念化することはできません。おそらくある種のacts_as_nestedセットアップを使用できるということですが、それでさえ手に負えなくなるのではないかと心配しています。また、グループ自体に関する限り、ある種の継承モデルを使用する必要がありますか (多くのプロパティを共有する可能性が高いことを考えると)。

おそらく、グループごとに個別の MVC セットアップを作成する必要がありますが、ユーザーの関連付けなどの問題はまだあります。誰か提案を提供できますか?

一番