Forum PHP.pl

Ja to rozwiązałem tak, że każdy moduł ma swoje kontrollery, modele, widoki itp. Moduł dodaje wpis do bazy danych "o sobie" w stylu:

tabel: sections
- section a
- section b
- section c

i potem tylko ustalasz kolejność it. i w pętli ładuje renderuje controllery ;P co prawda prosty cms typu onepage, ale moge pisać nowe moduły jako "bundle" i te potem po prostu instalować. Rozwiązań jest masa, moje pewnie jest jedno z gorszych.

co takiego fajnego jest w c# ? nie lepiej java? języki podobne, a java wieloplatformowa (chociaż... jak zna się c# to w javie też się szybko da radę odnaleźć)

A jakież to powody? Piszę w Javie i jakoś nie dostrzegam oczywistych powodów, dla których miałbym ją porzucać na rzecz C#

Tak mi się napisało, poza tym helpery nie muszą być klasami statycznymi w Zend nie są.

Pod względem teoretycznym zgadzam z Zyx'em. Wystarczy spojrzeć na diagram MVC na Wikipedii i wyraźnie widać, że Widok także może mieć bezpośredni dostęp do modelu.

Stąd doszedłem do wniosku, że w praktyce zamiast MVC lepiej zrobić MVTC, czyli Model View Template Controller. W ten sposób mamy Kontroler, który odpala model i odpowiedni widok, widok odpala sobie w razie potrzeby model, a na koniec zbiera to co chce do kupy i przekazuje do Szablonu. W ten sposób wilk syty i owca cała, tzn Graficy bawią się jedynie na Szablonie, a jednocześnie Widok nie jest tylko Szablonem, ale zawiera także logikę Widoku w postaci paginatora, itp.

Choć na razie to czysta teoria, bo takiego podejścia nie wypróbowałem i nie widziałem


EDIT:
W mojej wizji kontrolerów byłoby wiele.
Przykład oklepany - blog

• Kontroler (router) główny rozpoznaje, że użytkownik chce wyświetlić wpis na blogu. Odpala Widok zajmujący się wyświetlaniem wpisu.
• Widok wyświetlania wpisu odpala sobie Kontroler budowania menu. On rozpoznaje jakie menu chcemy wyświetlić (może być kilka rodzajów menu, kilka sposobów jego budowy) i odpala odpowiedni Widok.
• Widok ten pobiera dane z Modelu opisującego wybrany rodzaj menu i go wyświetla.
• Wracamy do Widoku wyświetlania wpisu. Zbudował on sobie i wyświetlił menu, więc pobiera sobie dane z Modelu zawierającego wpisy i wyświetla główną treść.
• Oprócz tego Widok wyświetlający wpis może chcieć wyświetlić reklamy, więc odpala sobie Kontroler reklam. Ten działa podobnie do Kontrolera menu.

Jak widać generalnie działałoby to tak, że Kontroler nadrzędny odpala Widok, który korzysta z podrzędnych Kontrolerów i odpowiedniego Modelu, by zbudować sobie dynamiczną zawartość. Taka jakby hierarchia. Co dziwne, w ten sposób Kontrolerzy nie korzystają z Modelów, bo... nie potrzebują? Nie wiem po co miałyby to robić.

Zalety tego rozwiązania (oprócz samego oddzielenia warstwy prezentacji od treści) widzę dwie:

• aplikację można podzielić na moduły/pluginy. Każdy moduł zbudowany byłby jako MVC. Inne moduły i moduł główny odpalałyby Kontroler modułu, mówiąc mu czego oczekują, a ten by to realizował;
• tak jak pisałem wcześniej, Widoki korzystałyby z Szablonów, więc graficy nie bawią się logiką Widoku, a jedynie dizajnem Szablonu, a co więcej jeden Szablon mógłby być wykorzystany w różnych Widokach.

Returns TRUE on success or FALSE on failure. However, if the CURLOPT_RETURNTRANSFER option is set, it will return the result on success, FALSE on failure.