2010-12-17 11 views
0

Ich bin neu bei Rails und versuche zu verstehen, wie wir 'komplexe' Modelle (und ihre Assoziationen) mithilfe von Tools erstellen, die uns in Rails zur Verfügung stehen. Stellen Sie sich schnell das folgende Beispielszenario vor: Users sind ein Mitglied von ONE racing Team. Benutzer können Cars und Schedules erstellen. Diese Autos haben Drivers, Fuel Ebenen, Engines und Wheels. Diese Wheels haben Tires, Hubs und MilesDriven. Sie erhalten die Idee ...Grundlegende Rails-Muster zum Zuordnen von Modellen zu Eltern (Verschachtelung?)

Angesichts all die Warnungen über nur 1 Ebene tief verschachteln ... Ich noch Kampf mit wie RESTful und Rails-y und stellt eine Benutzeroberfläche sein, dass ein Benutzer ein Car bauen mit Tires.

Ich weiß, wir haben eine Session & Cookie zu unserer Verfügung sowie versteckte Felder. So meldet sich der Benutzer an ... und wird auf seine Teamseite teams(current_user.team_id) weitergeleitet. Dann wollen sie eine Car erstellen. diese Routen zu new_team_car_path(current_user.team_id), wo sie ein Auto bauen können ... jetzt möchte ich ein Rad zu diesem Auto hinzufügen ... tut so die Route zu new_team_car_wheel_path(current_user.team_id, car_id), etc, etc ...? Ich denke nicht ... Aber was ist der Rail-y-Weg?

Auch gebaut wie alles verbunden sein wird, schließlich zu einem Team (und Nutzer) ist es am besten zu ‚carry‘ den team_id und/oder user_id Verein der ganzen Weg hinunter zum Tireoder ist es vernünftig zu Abfrage der Team durch Verfolgen der Verbände in der Hierarchie zur Laufzeit?

Ich bin sicher, dass diese grundlegende Dinge ist aber newbness hat mich verwirrt darüber, wie es am besten zu nähern ...

Antwort

1

Es gibt keine einfache Antwort auf diese Frage. Sie erwähnten die Verwendung von Sitzungsvariablen und versteckten Feldern - dies sind praktikable Ansätze, und die Entscheidung muss auf den spezifischen Anforderungen basieren. Die Tatsache, dass Sie darum kämpfen, die beste Antwort zu finden, ist ein gutes Zeichen dafür, dass Sie bereit sind, Alternativen in Betracht zu ziehen.

In diesem Fall haben Sie einen Vorteil, da Sie die Benutzerinformationen oder ihre Zuordnungen nicht in der URL eingeben müssen, da Ihr Autorisierungscode sie bereits in der Steuerung zur Verfügung stellt. Also würde ich den Benutzer und Team-ID aus Ihrem params fallen und greifen Sie von current_user:

# GET/Autos /: car_id/Räder/new

def new 
    @car = Car.find(params[:car_id]) 
    @wheel = @car.wheels.build 
end 

und

# POST/Autos /: car_id/Räder

def create 
    @user = current_user 
    @team = @user.team 
    @car = Car.find(params[:car_id] 
    @wheel = @car.wheels.build(params[:car][:wheel]) 
    ... 
end 

Das einzige Problem ist, wenn Sie ein Benutzer einen anderen Benutzer-Car zugreifen ermöglichen müssen. In diesem Fall sollte ein verstecktes Formularfeld (oder ein Dropdown-Menü) zum Auswählen des Benutzers funktionieren. Umgekehrt benötigen Sie möglicherweise eine Berechtigungsprüfung, um zu verhindern, dass Benutzer auf das "Auto" des anderen zugreifen können.

+0

ok. Vielen Dank! Also, nur um zu klären ... du denkst, es lohnt sich, 'user' * und *' team' in das 'car' (oder' wheel' oder was auch immer tief verschachtelte Ressource) einzubetten? Im Gegensatz zum Gehen die Kette "gehört" zu den "Benutzer" oder "Team" zu finden, wenn oder wie Sie sie brauchen?!? Und wenn ja, ist das aus Optimierungsgründen? Sie fragen also nicht ständig nach der DB? Oder..?? – Meltemi

+0

In dieser speziellen Situation haben Sie bereits die Kosten für die Suche nach dem Benutzer bezahlt, da Devise (oder was auch immer) das bei jeder Anfrage tut. Ich sage also, dass Sie * die Ressourcen nicht verschachteln müssen, da es eine eingebaute Möglichkeit gibt, den Benutzer und seine Assoziationen zu erkennen. – zetetic

Verwandte Themen