0

私は現在、その一部が招待/登録システムであるアプリケーションを構築しています。現在、システムには「コース」と「教室」があります。したがって、「コース」は何らかのコースであり、「クラスルーム」はコースの特定のインスタンスです。F.ex。1 つのコースがあるかもしれませんが、そのコースの 3 つの教室インスタンスがあり、開始日/終了日が異なり、資料がわずかに異なります/更新されているなどです。これで、「従業員」を「コース」に参加するよう招待できますが、「従業員は「自分自身が登録する特定の「教室」を選択する必要があります。そのため、従業員は招待状が表示される自分のプロフィール ページに移動します。ここで、従業員は招待状をクリックして、登録する特定のクラスルームを選択できます。これにより、明らかに登録が作成されます。しかし、「受け入れられた」ので、招待も取り除く必要があります。現在、「従業員」が「入学」を通じて多くの「教室」を持つように設定しています。また、「従業員」には「招待」を通じて多くの「コース」があります。ただし、従業員が招待状をクリックすると、登録ページ (登録コントローラー) が表示され、そこで登録が作成されるため、これは正しくないようです。ただし、登録が作成されると、招待状は削除する必要があります。したがって、現在、登録コントローラーは登録を作成し、招待を削除できるはずです。これは悪い設計のようです。教室と従業員の関係はかなり満足ですが、従業員と招待状の関係は悪いようです。どのようにしますか？「認められた」からです。現在、「従業員」が「入学」を通じて多くの「教室」を持つように設定しています。また、「従業員」には「招待」を通じて多くの「コース」があります。ただし、従業員が招待状をクリックすると、登録ページ (登録コントローラー) が表示され、そこで登録が作成されるため、これは正しくないようです。ただし、登録が作成されると、招待状は削除する必要があります。したがって、現在、登録コントローラーは登録を作成し、招待を削除できるはずです。これは悪い設計のようです。教室と従業員の関係はかなり満足ですが、従業員と招待状の関係は悪いようです。どのようにしますか？「認められた」からです。現在、「従業員」が「入学」を通じて多くの「教室」を持つように設定しています。また、「従業員」には「招待」を通じて多くの「コース」があります。ただし、従業員が招待状をクリックすると、登録ページ (登録コントローラー) が表示され、そこで登録が作成されるため、これは正しくないようです。ただし、登録が作成されると、招待状は削除する必要があります。したがって、現在、登録コントローラーは登録を作成し、招待を削除できるはずです。これは悪い設計のようです。教室と従業員の関係はかなり満足ですが、従業員と招待状の関係は悪いようです。どのようにしますか？「招待状」を通して。ただし、従業員が招待状をクリックすると、登録ページ (登録コントローラー) が表示され、そこで登録が作成されるため、これは正しくないようです。ただし、登録が作成されると、招待状は削除する必要があります。したがって、現在、登録コントローラーは登録を作成し、招待を削除できるはずです。これは悪い設計のようです。教室と従業員の関係はかなり満足ですが、従業員と招待状の関係は悪いようです。どのようにしますか？「招待状」を通して。ただし、従業員が招待状をクリックすると、登録ページ (登録コントローラー) が表示され、そこで登録が作成されるため、これは正しくないようです。ただし、登録が作成されると、招待状は削除する必要があります。したがって、現在、登録コントローラーは登録を作成し、招待を削除できるはずです。これは悪い設計のようです。教室と従業員の関係はかなり満足ですが、従業員と招待状の関係は悪いようです。どのようにしますか？ただし、招待状は削除する必要があります。したがって、現在、登録コントローラーは登録を作成し、招待を削除できるはずです。これは悪い設計のようです。教室と従業員の関係はかなり満足ですが、従業員と招待状の関係は悪いようです。どのようにしますか？ただし、招待状は削除する必要があります。したがって、現在、登録コントローラーは登録を作成し、招待を削除できるはずです。これは悪い設計のようです。教室と従業員の関係はかなり満足ですが、従業員と招待状の関係は悪いようです。どのようにしますか？

4

2 に答える 2

0

モデルの属性だけを使用statusして、招待手順を管理してみませんか？

次のモデルを使用します。

  1. Employee、アプリのユーザー。
  2. Course、従うべきコース;
  3. Classroom、に属するCourse（多くのコースclassrooms）。
  4. Participation、従業員、コース、教室の間のリンクを作成します。このモデルは、コースへの参加の進化に応じたステータスになります。invited従業員が招待されenrolledたとき、従業員が教室を選択したときなどです。

Participationモデルのスケルトンは次のようになります。

 class Participation < ActiveRecord::Base
   attr_accessible :status

   belongs_to :employee
   belongs_to :course
   belongs_to :classroom
   #...

   validates_uniqueness_of :employee_id, :scope => [course_id, :classroom_id]
 end

コースと教室を与えられた従業員の一意性の要件。そして、あなたの選択によっては、教室を考慮せずにコース自体のためだけかもしれません。

Participationsテーブルに一意のインデックスを追加します。

 add_index :participation, [employee_id, course_id, classroom_id], unique => true

招待時に、参加インスタンスが作成され（status invited）、対応するemployee_idとが空のcourse_idままclassroom_idになります。登録時に、参加はclassroom_idとステータスで更新されますenrolled。

それはあなたのニーズに合っていますか？

于 2012-10-27T20:20:33.940 に答える
0

accepted簡単な解決策は、招待モデルにブールフィールドを追加することです。教室/コースを選択したら、acceptedtrueに設定します。次に、プロフィールページで、acceptedfalseの場合にのみ招待状を表示します。

于 2012-10-27T20:24:52.047 に答える