[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]

Joomla! to CMS. Każdy tego typu CMS musi u6możliwiać swswoją rozbu6dowsę swtąd konieczność istniena "jądr5a" ogólnego u6żytku6 jak i swamej aplkacji. Ale nieswtoswowsnym jeswt porównywsanie tego do Sf2, który jest stricte frameworkiem. Zresztą mniejsza z tym.

W powyzszym przykladzie klasa Model zostala "zahardkodowana" w widoku View wiec rola kontrolera w zainicjalizowaniu polaczenia widoku z modelami zadna.

Nie, nie została. Szybko spojrzałem w źródla Joomla! (nie korzystałem z tego projektu nigdy) i widzę, że widok otrzymuje dany model z zewnątrz (dependency injection), zapewne z kontrolera. Tak więc dany widok może obsłużyć dowolny model tak długo jak implementuje on odpowiedni interfejs. Innymi słowy Joomla! to jeden z niewielu projektów, gdzie to MVC ma cokolwiek współnego z MVC, tj. widok to nie tylko szablon, a relacje pomiędzy warstwami aplikacji są zrealizowane w spósb zdefiniowany przez MVC. Chociaż muszę przyznać, że na pierwszy rzut oka kod jest rzeczywiście momentami tragiczny.

[Orzeszekk]

Joomla! to CMS. Każdy tego typu CMS musi u6możliwiać swswoją rozbu6dowsę swtąd konieczność istniena "jądr5a" ogólnego u6żytku6 jak i swamej aplkacji. Ale nieswtoswowsnym jeswt porównywsanie tego do Sf2, który jest stricte frameworkiem. Zresztą mniejsza z tym.

Nie, nie została. Szybko spojrzałem w źródla Joomla! (nie korzystałem z tego projektu nigdy) i widzę, że widok otrzymuje dany model z zewnątrz (dependency injection), zapewne z kontrolera. Tak więc dany widok może obsłużyć dowolny model tak długo jak implementuje on odpowiedni interfejs. Innymi słowy Joomla! to jeden z niewielu projektów, gdzie to MVC ma cokolwiek współnego z MVC, tj. widok to nie tylko szablon, a relacje pomiędzy warstwami aplikacji są zrealizowane w spósb zdefiniowany przez MVC. Chociaż muszę przyznać, że na pierwszy rzut oka kod jest rzeczywiście momentami tragiczny.

jesli jest DI to masz racje, nie jest to w takim razie bezwzglednie złe, natomiast ja przerabiajac tutorial a nie patrzac w gotowe zrodla widywalem tylko takie zahardkodowane przyklady.

wg mnie myślący widok (taki jak jest w joomli) ktory przetwarza dane z modelu a nastepnie wypluwa je do szablonu, nie jest zbyt wygodny ani przejrzysty, no i latwiej sie testuje jednostkowo MVC z pasywnym widokiem. W widoku skladajacym sie tylko z szablonu ciezko popelnic blad programistyczny wiec mozna przetestowac tylko wybrany kontroler, a tak trzeba jeszcze napisac testy dla warstwy przetwarzajacej dane w widoku, gdzie zapewne trzeba bedzie uzywac reflection by wydobyc prywatne metody widoku przetwarzajace dane, a nie wszyscy (w tym ja) są zdania ze powinno sie pisac testy pod prywatne metody. A tak robimy pasywny widok, testujemy kontroler w wybranych okolicznosciach, sprawdzamy czy zwraca to co chcemy, testy widoku mozna olac bo są trudne do zrealizowania i przy szablonie raczej dużo nie pomoga.

Mam troche do czynienia z takimi widokami (aktywnymi) w innym projekcie i wydaje mi sie ze pasywne widoki sa wygodniejsze i bardziej przewidywalne. Jezeli jakis widok wymaga tego samego przetworzenia danych zawsze mozna to obudowac w helper/kontroler jako service/user control w asp.

Ten post edytował Orzeszekk 8.03.2012, 02:32:30