Ik ben een redelijk ervaren PHP developer en nu bezig mezelf ruby on rails te leren. So far so good, ben best wel enthousiast en snap het MVC principe. Wat ik niet snap is hoe ik 2 controllers kan combineren in 1 view/pagina. Stel ik heb een blogpost en users kunnen daar commentaar op geven. Dan heb ik een Blog en een Comment controller en ook een Blog view en een Comment view. Maar ik wil een pagina die de blogpost laat zien en de bijbehorende comments. Hoe doe ik dit?
Ik zou zeggen dat het geven van commentaar gewoon hoort bij je Blog controller. Voor het weergeven van comments heb je toch gewoon een functie die je aanroept in je model die in je view de berichten weergeeft? Das bij elkaar echt een paar regels code, diezelfde code kun je gewoon ook in een andere controller gebruiken weer mocht je dat willen.
edit: In Zend_Framework kun je met de forward() functie andere actions (of actions in controllers) uitvoeren, misschien zoek je zoiets? Of RoR dit ook heeft weet ik alleen niet
edit: In Zend_Framework kun je met de forward() functie andere actions (of actions in controllers) uitvoeren, misschien zoek je zoiets? Of RoR dit ook heeft weet ik alleen niet
[ Voor 21% gewijzigd door Cartman! op 01-08-2008 16:28 ]
Verwijderd
Zo dacht ik er ook over. Je linkt je twee models al bij het opstellen van je models. Vervolgens heb je in je controller een functie die de event van het plaatsen van een comment afvangt.
Je hebt een view en een controller voor het weergeven van dit type pagina
Je hebt een view en een controller voor het weergeven van dit type pagina
[ Voor 6% gewijzigd door Verwijderd op 01-08-2008 17:11 ]
maar blog en comments is een 1 op m relatie, dus ook 2 aparte tabellen, dus dan kan het toch geen onderdeel zijn van de Blog controller
Verwijderd
Ik heb zelf geen ervaring met Ruby on Rails maar het lijkt me dat je de 1 op m relatie aangeeft in de model en niet in de controller? De controller hoort alleen events af te handelen.CAFC1905 schreef op vrijdag 01 augustus 2008 @ 16:30:
maar blog en comments is een 1 op m relatie, dus ook 2 aparte tabellen, dus dan kan het toch geen onderdeel zijn van de Blog controller
Je kunt toch meerdere models aanspreken in 1 controller... en ik weet zeker dat je met ActiveRecord ook in 1 query de blogpost+comments kunt terugkrijgen.
OK, dus geen Comment controller, maar wel een Comment model en dan alles afhandelen in de Blog controller. Ik ga het eens proberen, thanksCartman! schreef op vrijdag 01 augustus 2008 @ 16:53:
Je kunt toch meerdere models aanspreken in 1 controller... en ik weet zeker dat je met ActiveRecord ook in 1 query de blogpost+comments kunt terugkrijgen.
Zeker wel, een controller is geen model. In je controller roep je in je model aan 'Geef mij die-en-die posts + hun commentaar', en die stuur je door naar je view. Je view laag kijkt vervolgens naar de gegevens en rendert die.CAFC1905 schreef op vrijdag 01 augustus 2008 @ 16:30:
maar blog en comments is een 1 op m relatie, dus ook 2 aparte tabellen, dus dan kan het toch geen onderdeel zijn van de Blog controller
De enige echte reden om een aparte Comments controller te hebben is voor het submitten van nieuwe commentaren (waarbij het een controller is die de gebruiker eigenlijk niet gebruikt - een in-only controller, om het maar een naam te geven), en voor beheersfuncties van die commentaren.
Het antwoord is al in zekere zin gegeven door JopY, maar daarbij wil ik nog aan toevoegen dat zo'n dergelijke controller wel degelijk door de gebruiker gebruikt wordt. Het gaat hier om een RESTFUL controller waarbij je je spreekt van resources waar je CRUD operaties op toe kan passen. Het is zeker dus niet alleen voor het posten van comments, maar misschien ook het updaten en deleten van deze.
Ik raad TS aan om zich hier in te verdiepen aangezien het je controller code ook goed overzichtelijk houdt: je denkt nu meer vanuit het oogpunt van "denken dat duizend en een acties die misschien niet bijster veel met elkaar te maken hebben toevoegen aan een controller een goed idee is" ipv resources en de CRUD operaties die je erop toe kan passen.
Tot slot: laat het merendeel dat je van PHP hebt geleerd maar bij de deur als je met RoR begint. Verdiep je eerst in de Ruby idiomen (het is echt een veel dynamischere taal dan PHP) en verdiep je ook in de design patterns en paradigms die toegepast worden in rails. Filter chains b.v. die men geleend heeft van AOP om er maar even een te noemen. Zonder MVC kennis (en dan bedoel ik kennis kennis) kom je al gauw beroerd uit in Rails. M.a.w. ik zou het iig niet proberen te leren vanuit een oogpunt van 'so far so good' wat op mij overkomt als een trial & error approach. RoR is gebouwd op good practices die je alleen goed kan benutten als je ook weet hoe je ze moet gebruiken.
Ik raad TS aan om zich hier in te verdiepen aangezien het je controller code ook goed overzichtelijk houdt: je denkt nu meer vanuit het oogpunt van "denken dat duizend en een acties die misschien niet bijster veel met elkaar te maken hebben toevoegen aan een controller een goed idee is" ipv resources en de CRUD operaties die je erop toe kan passen.
Tot slot: laat het merendeel dat je van PHP hebt geleerd maar bij de deur als je met RoR begint. Verdiep je eerst in de Ruby idiomen (het is echt een veel dynamischere taal dan PHP) en verdiep je ook in de design patterns en paradigms die toegepast worden in rails. Filter chains b.v. die men geleend heeft van AOP om er maar even een te noemen. Zonder MVC kennis (en dan bedoel ik kennis kennis) kom je al gauw beroerd uit in Rails. M.a.w. ik zou het iig niet proberen te leren vanuit een oogpunt van 'so far so good' wat op mij overkomt als een trial & error approach. RoR is gebouwd op good practices die je alleen goed kan benutten als je ook weet hoe je ze moet gebruiken.
[ Voor 47% gewijzigd door prototype op 02-08-2008 05:36 ]
Pagina: 1