Hallo Dietmar,
ah, ich liebe diesen nested-resources-thread, der alle paar Wochen mal
wieder auftaucht und dann wieder einschläft, ohne dass man wirklich zu
einer Lösung gekommen wäre :)
Wir benutzen hier noch immer, wirklich wirklich tief geschachtelte
ressourcen (project -> container -> quiz -> question -> answer), vor
allem, weil ich das damals für die "natürlichste" Art gehalten habe,
das abzubilden, weil das Business-Model genau so ist. Die Lehrmeinung
ist: Don't use deeply nested routes. Eine wirkliche, schlagende
Argumenation dagegen habe ich bislang aber auch noch nicht gehört -
hier sind die die Vor- Nachteile, die wir hier praktisch erfahren:
Contra:
- die routes werden deutlich komplizierter/länger.
- eine Hierarchie-Änderung ist beinah immer tödlich, weil diese
Hierarchie in vielen verschiedenen Controllern/views benutzt wird.
- not DRY: die Modelle sind ja schon genestet, die iteration kennt ihr
Projekt, der task seine iteration, damit hat projects/2/iterations/36/
tasks/140 dieselben Informationen wie /tasks/140
pro:
- ein einheitlicher Weg, den Kontext für einen Controller wieder
herzustellen: Wenn man einen Task editiert, dann braucht man im View
in der Regel auch immer Informationen über project und iteration. Wir
machen das über einen before_filter, der davon ausgeht, dass in der
route immer project und iteration drin sind. Hat man das nicht, dann
muß man entweder im View oder im Controller den Pfad bis nach oben
wiede ablaufen, bis man bei den Kontext-Objekten angekommen ist - und
dieser Pfad ist halt nicht immer derselbe.
- für den edit/view sind die Informationen redundant (/tasks/140),
aber für den create nicht: /tasks/140, da braucht man die iteration im
Pfad. Aber man muss sich halt für eine Variante der route entscheiden
und dann ist die genestete in der Regel die "natürlichere" (die, die
besser zum Modell passt).
In der Praxis überwiegen die Contras: Das "natürlichere" Nesting ist
besser, um zu verstehen, wie die Controller funktionieren müssen, aber
irgendwann macht einen das wahnsinnig, diese ganzen Parameter überall
mitschleppen zu müssen. Man kommt da zwar mit helpern für die Routes
und Konventionen drum herum, aber schön ist das nicht. Wir sind
inzwischen dazu übergegangen: So tief wie nötig und so flach wie
möglich schachteln.
Wirklich Abhilfe kommt da aber glaub ich erst mit 2.2:
http://ryandaigle.com/articles/2008/9/7/what-s-new-in-edge-rails-shallow-routes
Damit kann man das Beste aus beiden Welten haben: Lange, natürliche
Pfade für's Create, und kurze für's edit, wenn man bereits eine id
hat, the holy grail of nesting...
Viele Grüße
Stefan
Am 01.11.2008 um 19:57 schrieb Herman Müller:
Hallo Thomas,
vielen Dank!!
Hat einwandfrei funktioniert.
Aber irgendwie kann ich mich mit den langen URLs nicht anfreunden, ist
erheblich mehr Arbeit als mit den kurzen URLs, über z.B.
map.resources :projects, :has_many => [ :iterations]
map.resources :iterations, :has_many => [ :tasks]
Ergebnis --> http://localhost:3000/iterations/36/tasks/140
Diese URL ist zwar nicht so schön erklärend wie,
http://localhost:3000/projects/2/iterations/36/tasks/140
welche jedoch einen erheblich höheren Code-Aufwand bedeutet.
Hast Du vielleicht noch irgendwelche Tipps für Applicationen mit
tiefer
verschachtelten nested resources?
Wünsche Dir ein schönes Wochenende!
Gruß
Dietmar
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
----
stefan frank
vierundsechzig.de
software&service
weberstr. 10
69120 heidelberg
tel. +49 (0) 6221 7277049
mobil +40 (0) 173 2383390
mail [EMAIL PROTECTED]
www.vierundsechzig.de
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
