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?

To jest raczej pytanie retoryczne. Bo joomli do doskonałości dalej niż mogłoby się wydawać.. Jak ogarniesz jakiegoś FW, i przygotujesz sobie jakiś zestaw modeli/widoków do rzeczy które się powtarzają (artykuły, newsy, komentarze etc), to potem zrobienie takiego "portalu" może być równie szybkie co na gotowej joomli. Także jak dla mnie wybór jest oczywisty

W sumie to wolalbym pisac nawet 2 tyle w symfony cieszac sie elegancją kodu, niz 2 razy krocej bluzgac na ten syf.

[PHP] pobierz, plaintext 
class HelloViewHello extends JView
{
	function display($tpl = null)
	{
		$model =& $this->getModel();
		$greeting = $model->getGreeting();
		$this->assignRef( 'greeting',	$greeting );
 
		parent::display($tpl);
	}
}
[PHP] pobierz, plaintext 

Wziete z joomla MVC tutorial.

Nie wiem czy to jest MVC i czy jest prawidlowe, mnie sie ono wydaje gówniane jak nieszczescie.
Po co widokowi zaleznosci miedzy modelem? Czy nie mozna po prostu wyslac danych do wyswietlenia do widoku z kontrolera i moc uzywac tego samego widoku x razy bez przeróbek? Co w PHP5 robi ten "&" ?

ostatnio dostałem zadanie - odnalezc dlaczego w project forku (taki system do zarzadzania projektami GPL) w momencie przydzielenia zadania do okreslonych osob, mail z powiadomieniem jest rozsylany do wszystkich osob na portalu a nie tylko do tych przydzielonych...

kod (pseudokod, jakos tak to wygladalo).
$costam->sendMailsNotification();

w sendMailsNotification:

costam, costam costam
$recipients = $singleton::get()->getRecipients();
Mailer::sendMail($recipients);

metoda sendMailsNotification uzyta w wielu miejscach w kodzie, ustalanie listy adresatów na podstawie wartosci jakiegos niewiadomo skad singletona. A teraz biedny czlowieku sobie badaj w ktorym momencie ktory kod i ktory modul ustawia ten singleton tak ze sa wysylane bonusowe maile.

Chyba ktos lubi bardzo C, i programowanie int zmienna = wskaznik1->wskaznik2->wskaznik3->wskaznik4[wskaznik5->wskaznik6];

[PHP] pobierz, plaintext 
defined( '_JEXEC' ) or die( 'Restricted access' );
[PHP] pobierz, plaintext 

Prawie jak programowanie w winAPI

[PHP] pobierz, plaintext 
require_once( JPATH_COMPONENT.DS.'controller.php' );
[PHP] pobierz, plaintext 

Masa stalych ktore biora sie nie wiadomo skad, czy to taki problem zrobic autoloading?

[PHP] pobierz, plaintext 
// Require specific controller if requested
if($controller = JRequest::getWord('controller')) {
    $path = JPATH_COMPONENT.DS.'controllers'.DS.$controller.'.php';
    if (file_exists($path)) {
        require_once $path;
    } else {
        $controller = '';
    }
}
[PHP] pobierz, plaintext 

Dlaczego jakis engine nie przetwarza routingu tylko mam za kazdym razem kopiowac i wklejac ten kawalek kodu do kazdego entry pointa modułu?

przy okazji zauwazylem takie kwiatki jak
$isRegistered= JFactory::getUser()->register;

mnie uczono ze klasy nie powinny miec publicznych pól, chyba ze to bezmózgie value objecty (Wtedy mozna to zniesc) ale pewnie sie mylili ci co mnie uczyli.
Spoko, sam robiłem takie bledy rok temu, gdy z proceduralnego przerzucilem sie na true obiektowe, i co nie ktore starsze klasy zostaly z takim interfejsem z polami publicznymi, jednak z mojego FW nikt nie korzysta i nie pluje jadem z tego powodu a joomli chyba nie pisali studenci 1 roku tylko jakies wieksze ogary..

sory musialem sie wyzalic Z tej joomli niezle zakrecony kawalek kodu

Co Ty w ogóle próbujesz porównywać? Narzędzie wspomagające tworzenie aplikacji z kompletną aplikacją, poswiadającą swoje API/bibliotekę? To nie ma sensu.

Eeee... bo to jest istota MVC? I to wsłaśnie to pozwala na wielokrotne użycie tego samego modelu/widoku bez potrzeby robienia przeróbek? W MVC kontroler pełni jedynie rolę inicjalizatora połączenia widoku z modelem(ami).

W ogóle nie rozumiem Twojego problemu. Symfony2 spełnia Twoje oczekiwania, Joomla! nie więc nad czym w ogóle się zastanawiasz?

Joomla! Framework



zastanawiam sie bo migracja z joomli na sf2 sie bedzie wiazala z przepisaniem dzialajacego kodu i nie wiadomo czy sie oplaci meczyc z joomla dalej i troche to rozwinac czy zrobic wszystko od nowa w sf

w asp.net mvc widok jest pasywny i w sf2 chyba tez (sam danych z modelu nie pobiera, zostaja wstrzykniete w kontrolerze). jakos tak. mozna zmusic widoki do wspolpracy z roznymi modelami a nie tylko z jednym na sztywno zwiazanym.
W powyzszym przykladzie klasa Model zostala "zahardkodowana" w widoku View wiec rola kontrolera w zainicjalizowaniu polaczenia widoku z modelami zadna. rownie dobrze mogloby go wcale nie byc. Wzialem ten przyklad z tutoriala Joomla for developers wiec zakladam ze takie są w tym FW konwencje i reszta tez tak wyglada. ale darujmy kłótnie o patterny

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.

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.
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.

Z tego co kiedyś na jakimś blogu czytałem, to joomla, jako nieliczne twory php posiada w miarę poprawnie zaimplementowany mvc. Mnie osobiście się to średnio podoba, nie widzę w tym większego sensu, ale to w sumie moje zdanie implementacja wzorca swoją drogą, inną kwestią jest ogólny bałagan jaki w tym cms'ie panuje, który mnie już na samym początku odstraszył i zniechęcił do jakiegoś głębszego zapoznania się z źródłami.. Tam chyba najbardziej odstrasza kompatybilność php4..

BTW widzę spać nie możecie, 3 w nocy a wy posty piszecie :|

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?

Nie. Roddzielenie warstw aplikacji od siebie nazywamy... rozdzieleniem warstw, ang. multitier architecture (architektura wielowarstwowa). MVC to już konkretny przykład takiej architektury z jasno określonymi warstwami i co ważniejsze sposobami komunikowania się tych warstw między sobą. MVP czy MVVM może i historycznie wywodzą się z MVC, ale są to wzorce równoległe do niego. Innymi słowy hierarchia wygląda tak: