MVC własna implementacja - widok

Odpowiedz Nowy wątek
2014-12-19 10:30
0

W końcu postanowiłem się przekonać do mvc, wychodzi na to, że nie jest taki zły, a moja zła opinia wynikała z przykrego doświadczenia w jednym z projektów przy którym współpracowałem. Fakt trochę wydajności to straci ale nie jest źle + nic nie stoi na przeszkodzie by we własnym frameworku zachować możliwość pisania strony w oparciu o modułu co jest według mnie wygodniejsze niż wrzucenie wszystkich widoków do jednego folderu, kontrolerów do innego folderu, a modeli do jeszcze innego. Ale dochodząc do sedna sprawy, po przestudiowaniu wielu artykułów na temat zastosowania mvc w php okazuje się, że to takie mvc to do końca nie jest a bardziej mamy do czynienia z mvp. No i w związku z tym według mnie najwygodniejszym sposobem ładowania widoków nie jest tworzenie dla każdego widoku obiektu tylko, rozwiązałem to w ten sposób, że w klasie po której dziedziczą wszystkie kontrolery jest metoda load_view() przyjmująca jako argument nazwę templatki i tablicę asocjacyjną z argumentami. Ta metoda zmienia tablicę na poszczególne zmienne, i następnie includuje templatkę, która w tym momencie się wykona. I o co mi ogólnie chodzi? O to czy idea tej metody umieszczonej jako część klasy bazowej kontrolerów jest jakaś zła.

Pozostało 580 znaków

2014-12-19 10:55

W ASP.NET MVC jest taka koncepcja, ze akcja kontrolera zwraca obiekt typu ActionResult lub jakiegos pochodnego (np. RedirectResult, ViewResult, itp.). Sama klasa bazowa kontrolera dostarcza metody pomocnicze, np. metode View(), ktora przyjmuje nazwe widoku (opcjonalna, bo domyslnie jest taka sama jak nazwa akcji) i model dla widoku. Wydaje sie to dosc normalna, ze bazowy kontroler dostarcza jakies metody pomocnicze do tworzenia rezultatow.

edytowany 1x, ostatnio: n0name_l, 2014-12-19 11:08

Pozostało 580 znaków

2014-12-19 12:20
0

Ok, dzięki

Pozostało 580 znaków

2014-12-19 17:34
0
mr_jaro napisał(a):

No i w związku z tym według mnie najwygodniejszym sposobem ładowania widoków nie jest tworzenie dla każdego widoku obiektu tylko, rozwiązałem to w ten sposób, że w klasie po której dziedziczą wszystkie kontrolery jest metoda load_view() przyjmująca jako argument nazwę templatki i tablicę asocjacyjną z argumentami. Ta metoda zmienia tablicę na poszczególne zmienne, i następnie includuje templatkę, która w tym momencie się wykona. I o co mi ogólnie chodzi? O to czy idea tej metody umieszczonej jako część klasy bazowej kontrolerów jest jakaś zła.

Raczej nie jest to zła metoda. Tak działa przekazywanie danych do widoków w Symfony 2.x. To samo dotyczy modułów. Projekt w Symfony 2.x składa się z pewnych logicznych modułów (bundle). Nie ma tam pojedynczych folderów na kontrolery, widoki czy modele. Każdy bundle ma swoją określoną strukturę. Myślę, że zaglądnięcie w kod tego frameworka może Ci wiele wyjaśnić, tym bardziej, że aspiruje do najlepiej zaprojektowanego dla PHP.

edytowany 1x, ostatnio: gaUa69, 2014-12-19 17:39

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0