Das ist eine schöne Frage, nach einer vernünftigen Antwort darauf hab
ich jetzt auch schon länger mal gesucht. Was tieferes Nesting von
Ressourcen angeht scheint da kaum jemand Erfahrungen gemacht zu
haben. Wir sind dannn hier den Weg gegangen, das einfach mal zu
versuchen und sind da bislang eigentlich sehr zufrieden mit.
Wir kommen hier mittlerweile auf ein Nesting von 5 Ebenen -
eigentlich finde ich das immer noch handlebar, solange es logisch zur
Anwendung passt. Von diesen Ebenen werden die obersten beiden (bei
uns sind das Projekt und Container) über einen beforefilter im
applicationController verwaltet, darunter wird es dann so spezifisch,
dass die Controller selber dafür sorgen, dass alle Objekte im Pfad
richtig geladen sind.
Nur wegen dieser Pfad-Geschichte das Model zu verdrehen halte ich für
keine so gute Idee: Zumindest bei uns ist es so, dass wir an die
obersten beiden Ebenen sehr viele verschiedene Sachen im Laufe des
Projekts drangehängt haben - zumindest bei uns hätte das also nicht
funktioniert, das in eins der unteren Modelle zu stecken.
Den Artikel mit den drei Ebenen fand ich auch nicht sooo plausibel:
Wenn es die Ressourcen logisch nur genestet gibt, dann gibt's
eigentlich auch keinen Grund (abgesehen von der Zeichenbegrenzung der
URL) warum die Route das nicht wiedergeben sollte. Ich entscheide das
jetzt eher von der Benutzung des Modells her: Ist es eine Containment-
Beziehung, das heißt wählt man z.B. erst einen Container aus, um dann
viele verschiedene Ressourcen dranzuhängen, dann wird genestet. Wenn
man von der Ressource kommt und diese Ressource dann am Ende nur noch
eine Referenz braucht, dann kommt die Ressource ganz oben in die
route und die Referenz wird nur über ein Drop-Down gemacht. (Legt man
ein neues Kino an und gibt dann da eine Stadt an oder geht man in ein
Land, wählt eine Stadt aus und legt dann in dieser Stadt ein neues
Kino an? Das klingt für mich eher ein bisschen danach Land und Stadt
zu nesten und die Kinos nach oben zu schieben....)
Böse Stolperfalle fand ich dann aber auch die Pfade: Da sollte man
frühzeitig dafür sorgen, dass man Pfade wie
question_path(@project, @container, @question.quiz, @question)
in helper auslagert, weil man ansonsten damit die hierarchie festlegt.
Was das XML angeht: Hier bin ich nicht so sicher, ob die Struktur des
XML, das man haben will so ein guter Ratgeber für das Design der
Routes ist. Ich hatte eigentlich auch gedacht, dass ich das meinen
ressourcen dann einfach to_xml sage und dann produzieren die schon
das richtige, bin dann aber am Ende doch bei einem eigenen Controller
für spezielle Ansichten gelandet: Die ziehen jetzt builder-templates,
in denen ich das xml von Hand schreibe, so wie es die Clients
brauchen....
Na, soviel erstmal zu meinen Erfahrungen mit nested resources - würd
mich brennend interessieren, wie der Rest der Welt das handhabt!
Viele Grüße
Stefan
PS: Schönes Thema sind auch nested ressources zusammen mit
acts_as_tree :)
Am 14.08.2007 um 00:50 schrieb Philipp Rosenkranz:
Hallo
Ich frage mich was besser ist bei folgender Problematik:
(Ist kein echtes Projekt nur eine Übung bzw. ein Experiment)
Es müssen Kinos (inkl. der dort laufenden Filme) nach Ländern (und
Städten) geordnet angezeigt werden.
Außerdem soll eine Übersicht über alle Daten möglich sein
(hierarchisch).
(inkl. XML Export aller Daten oder nur nach country bzw. city oder
cinema )
Da das alles eine verschachtelte Struktur ist dachte ich sofort an
nested resources im sinne von:
map.resources :countries do |country|
country.resources :cities do |city|
city.resources :cinemas do |cinema|
cinema.resources :movies
end
end
end
Nun muss man aber bei so tief verschachtelten resourcen ( eventuell
wirds noch tiefer :-( )
sehr viel von hand schreiben ( path's anpassen, finds anpassen,
before_filter um die übergeordnete(n) model id('s) zu finden,
usw ... )
Daher frage ich mich ob ich country und city als eigene resource (bzw.
model) behandeln soll oder ob ich diese nicht einfach in das cinema
model verfrachten soll.
(country und city haben jeweils nur ein "richtiges" Attribut:
"name:string" )
Aber dann frage ich mich was ich machen soll
wenn z.B.: etwas wie: "country has_many :notes" dazukommt ...
Die Übersicht würde ich dadurch gewährleisten ,dass jede resource
im view ihre child resources anzeigt.
(So würde man auf /countries Eine Übersicht mit allen Ländern, den
darin
enthaltenden Städten und den wiederum in den Städten zu finden Kinos
usw. angezeigt bekommen)
Ist das der rails way oder geht das auch einfacher bzw. etwas mehr
DRY?
P.S.: Mein erster Post hier daher nen paar Infos über mich:
Wohne in Berlin und komme aus dem Network bzw. System Administrations
Bereich (bin CCNA u. LPIC-2). Beschäftige mich aber auch seit einigen
Jahren mit Web Programmierung ( hauptsächlich PHP ).
P.P.S.: Ich hab mir schon einige Tutorial's zu dem Thema nested
resources angesehen (natürlich auch DAS Buch gelesen) jedoch nie
Beispiele gefunden die So tief verschachtelte resourcen gezeigt haben.
In einem Blog wurde sogar davor gewarnt tiefer als drei Ebenen zu
gehen
(leider ohne Angabe warum)...
Grüße
Philipp
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://
messenger.yahoo.de
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
