[Symfony][Joomla] Co lepsze? Opcje

[Orzeszekk]

Witam. Mam pytanie - czy uzywacie (jako programisci, a nie jako amatorzy nie znający PHP i html) joomli do budowania portali opartych na niej?

Zaczalem sie uczyc tego FW, bo takie zlecenia wpadają, ale jak sie patrze w kod.. kur mnie bierze momentalnie. Co za syf. Kupa globalnych zmiennych, jakies smieszne nieudokumentowane requiry, słynne defined() or die('restricted access');, widoki modele i kontrolery w ktorych kupa kodu sie powtarza...

Chocby ten pomysl by komponowac samemu menu poprzez baze danych jest idiotyczny.. nie moge wyslac zmian na serwer z localhosta w paczce bo musialbym jeszcze zuploadowac baze danych..

moje pytanie jest takie czy joomla nadaje sie by stawiac na niej jakies ciekawsze portale opierajac sie o nią, czy to tylko narzędzie dla ludzi ktorzy zbytnio nie znają sie na web? Mam kilka stron do ogarniecia, ktore są zrobione w joomli, jej zaleta jest to ze ma jakis tam edytor artykułów itd, ale grafik klnie na joomle ze wymusza sztywny wyglad strony 2 kolumny + srodek, a ja klne na nalecialosci z PHP4 w kodzie.

Czy lepiej i szybciej byloby uzyc symfony2, wygenerowac backendy zamiast korzystac z joomlowskich gotowych i zrobic takie rzeczy jak menu na sztywno?

[Crozin]

Różne rozwiązania mają swoje plusy i minusy. Jeżeli jedno z nich byłoby bezwzględnie lepsze to innych by się po prostu nie stosowało, czyż nie?
Taki bezmyślny widok jedynie w postaci szablonów (typu Smarty/czyste PHP) też nie jest idealnym rozwiązaniem, bo w kontrolerach trzeba się wielokrotnie powtarzać oraz zajmować logiką widoku (np. decydować o sortowaniu elementów, albo o tym co pokazać a co ukryć). Żeby się nie powtarzać można wydzielić te zadania do osobnego obiektu. Tyle że taki obiekt to już można by zaliczyć pod obiekt z warstwy widoku, więc cały widok nie byłoby już taki bezmyślny. (IMG:style_emoticons/default/wink.gif)
Z drugiej strony bardziej złożony widok (pamiętaj, że szablon to nie synonim warstwy widoku, nawet w najprostszej, "bezmyślnej" implementacji) może czasami sprawiać problemy w momencie gdy chcemy połączyć pewne niestandardowe funkcje logiki widoku. Same testy jednostkowe... może rzeczywiście nieco się komplikują, ale zyskuje się ładne odseparowanie logiki biznesowej od logiki widoku. Tak jak pisałem - każde rozwiązanie ma kilka za i kilka przeciw.

Na Twoim miejscu, o ile masz taką możliwość, przeniósłbym wszystko na Symfony2 - widać, że Joomla! Ci bardzo nie odpowiada, po co się masz nim męczyć i denerwować? No chyba, że mówimy tutaj o jakiś na prawdę obszernych ilościach kodu do przeniesienia.

PS. Bardzo nie lubię dyskusji o tych nieszczęsnych wzorcach architektonicznych, głównie przez to że istnieje tak wiele odmian, nie mających nieraz ze sobą wiele wspólnego a i tak nazywa się to wszystko MVC. Wystarczy spojrzeć na to jak realizowane jest to we większości frameworków PHP (np. Symfony2), jak w takiej Joomla!, a jak w JEE-owskim JSF (w PHP brak odpowiednika, w ASP.NET nie wiem - nie znam). Wszystkie działają w środowisku klient-serwer (HTTP), wszystkie docelowo służą do tego samego, wszystkie mocno różnią się w działaniu i założeniach, a i tak o każdym przeczytasz "MVC framework". A jak doda się do tego dziwne stanowisko większości programistów (przynajmniej na tym forum), że MVC to jakaś świętość, i że "poprawne MVC" to wyznacznik idealnej struktury aplikacji to już całkiem się odechciewa dyskusji. (IMG:style_emoticons/default/wink.gif)

[Orzeszekk]

Różne rozwiązania mają swoje plusy i minusy. Jeżeli jedno z nich byłoby bezwzględnie lepsze to innych by się po prostu nie stosowało, czyż nie?
Taki bezmyślny widok jedynie w postaci szablonów (typu Smarty/czyste PHP) też nie jest idealnym rozwiązaniem, bo w kontrolerach trzeba się wielokrotnie powtarzać oraz zajmować logiką widoku (np. decydować o sortowaniu elementów, albo o tym co pokazać a co ukryć). Żeby się nie powtarzać można wydzielić te zadania do osobnego obiektu. Tyle że taki obiekt to już można by zaliczyć pod obiekt z warstwy widoku, więc cały widok nie byłoby już taki bezmyślny. (IMG:style_emoticons/default/wink.gif)
Z drugiej strony bardziej złożony widok (pamiętaj, że szablon to nie synonim warstwy widoku, nawet w najprostszej, "bezmyślnej" implementacji) może czasami sprawiać problemy w momencie gdy chcemy połączyć pewne niestandardowe funkcje logiki widoku. Same testy jednostkowe... może rzeczywiście nieco się komplikują, ale zyskuje się ładne odseparowanie logiki biznesowej od logiki widoku. Tak jak pisałem - każde rozwiązanie ma kilka za i kilka przeciw.

Na Twoim miejscu, o ile masz taką możliwość, przeniósłbym wszystko na Symfony2 - widać, że Joomla! Ci bardzo nie odpowiada, po co się masz nim męczyć i denerwować? No chyba, że mówimy tutaj o jakiś na prawdę obszernych ilościach kodu do przeniesienia.

PS. Bardzo nie lubię dyskusji o tych nieszczęsnych wzorcach architektonicznych, głównie przez to że istnieje tak wiele odmian, nie mających nieraz ze sobą wiele wspólnego a i tak nazywa się to wszystko MVC. Wystarczy spojrzeć na to jak realizowane jest to we większości frameworków PHP (np. Symfony2), jak w takiej Joomla!, a jak w JEE-owskim JSF (w PHP brak odpowiednika, w ASP.NET nie wiem - nie znam). Wszystkie działają w środowisku klient-serwer (HTTP), wszystkie docelowo służą do tego samego, wszystkie mocno różnią się w działaniu i założeniach, a i tak o każdym przeczytasz "MVC framework". A jak doda się do tego dziwne stanowisko większości programistów (przynajmniej na tym forum), że MVC to jakaś świętość, i że "poprawne MVC" to wyznacznik idealnej struktury aplikacji to już całkiem się odechciewa dyskusji. (IMG:style_emoticons/default/wink.gif)

a czy nie jest tak ze skrot MVC w tym momencie oznacza po prostu kazdy wzorzec w ktorym zadania logiki biznesowej, przetwarzania routingu i sterowania oraz widoku sa oddzielone? A ponizej wszystko dzieli sie na "prawdziwy" mvc, MVVM, MVP i inne?