Rozszerzenie HMVC

Tworząc większe aplikacje za pomocą CodeIgnitera, możemy dojść do wniosku, że obecna struktura dla projektów nie do końca się sprawdza. Dziesiątki kontrolerów, widoków i modeli w zaledwie trzech katalogach to naprawdę sporo. Na szczęście jest na to sposób. Rozszerzenie HMVC, którego autorem jest wiredesignz.

Jeśli chciałbyś:

  • znaleźć sposób na podzielenie funkcjonalności swojej aplikacji pod względem struktury, tak aby łatwiejsze stało się zarządzanie kodem i ponowne jego użycie w innych projektach
  • mieć możliwość odwoływania się z poziomu kontrolera/widoku do innego modułu (kontrolera)

to rozszerzenie HMVC jest właśnie dla Ciebie.

Rozszerzenie HMVC pozwala na reorganizację struktury dla naszego projektu i wykorzystanie modułów. Każdy moduł może zawierać te same pliki co standardowa aplikacja, czyli: pliki kontrolerów, modeli, widoków, bibliotek itd. Zamiast standardowej struktury:

controllers/
models/
views/

możemy korzystać z następującej:

modules/modul_1/controllers/
modules/modul_1/models/
modules/modul_1/views/
modules/modul_2/controllers/
modules/modul_2/models/
modules/modul_2/views/

Stosując HMVC otrzymujemy wiele modułów o budowie MVC. Jeżeli chcemy, możemy również tworzyć odwołania z poziomu kontrolera do innych kontrolerów (za pomocą jednego żądania HTTP).

No dobrze, spróbujmy więc zainstalować to rozszerzenie. Zakładam, że masz ściągniętą świerzą, stabilną wersję CodeIgnitera 2.1.2.

  • Na początek ściągamy rozszerzenie HMVC i rozpakowujemy je w głównym katalogu naszego projektu;
  • następnie kopiujemy otrzymane po rozpakowaniu foldery core i third_party do katalogu application;
  • teraz w katalogu application, tworzymy katalog modules, gdzie znajdować się będą nasze moduły;
  • w katalogu modules, który przed chwilą stworzyliśmy, tworzymy katalog welcome (który jest nazwą dla naszego pierwszego modułu) i kopiujemy do niego kolejno katalogi application/controllers, application/models i application/views. W ten sposób stworzyliśmy nasz pierwszy moduł, który będzie wyświetlał standardową stronę powitania. Dodatkowo, możemy jeszcze edytować plik application/modules/welcome/views/welcome_message.php i dopisać do niego w znaczniku H1 „Welcome to CodeIgniter HMVC!”;
  • jeśli przejdziemy pod adres URL: http://adres_aplikacji/index.php/welcome, to naszym oczom powinna ukazać się strona startowa CodeIgnitera, ze zmienionym znacznikiem H1. Oznacza to, że rozszerzenie HMVC zostało poprawnie zainstalowane i działa.

To tyle. Pamiętaj, że w modułach mogą znajdować się nie tylko kontrolery, widoki i modele, ale również pliki konfiguracyjne, biblioteki, helpery, czy pliki językowe.

Jeśli chcemy w naszym module użyć jakiejś biblioteki/modelu/helpera itp. z innego modułu – wystarczy wykorzystać standardowe wywołanie jakie zwykle stosujemy w CI, czyli:

Zachęcam do zapoznania się ze szczegółowymi ustawieniami i zasadami działania tego rozszerzenia. Do dyspozycji mamy naprawdę kilka ciekawych opcji.

Podsumowując, profity ze stosowania rozszerzenia HMVC są następujące:

  • każdy moduł może zawierać własne pliki kontrolerów, widoków, modeli itd, co poprawia organizację kodu w projekcie;
  • dzięki modularności, Twoje aplikacje mogą być w łatwiejszy sposób rozszerzane (wystarczy przenieść odpowiedni moduł do nowego projektu);
  • moduły mogą być wywoływane przez inne moduły, co sprzyja ponownemu wykorzystaniu kodu.

16 thoughts on “Rozszerzenie HMVC

  1. Cześć, fajny art! Dobrze, że o tym piszesz, bo mało osób w Polsce tego używa. Osobiście współpracowałem już z kilkoma firmami jako programista php/codeigniter i żadna tego nie używała.

    Ja w swoich projektach stosuję, lecz nie do corowych elementów aplikacji tylko do komponentów(jak zwał tak zwał). Tak więc w application/controllers mam podział na frontend i backend a w nich katalogi modules. To w znaczynm stopniu (wg. mnie) ułatwia rozszerzania aplikacji i utrzymanie wstecznej kompatybilności pomiędzy wersjami aplikacji a wersjami komponentów.

    Moja konfiguracja wygląda tak:

    $url = str_replace(basename($_SERVER[‚SCRIPT_NAME’]),”,$_SERVER[‚SCRIPT_NAME’]);
    $tmp = explode(‚/’, $url == ‚/’ ? ltrim($_SERVER[‚REQUEST_URI’], ‚/’) : preg_replace(‚/’.preg_quote($url, ‚/’).’/’, ”, $_SERVER[‚REQUEST_URI’], 1));

    $space = $tmp[0]==’admin’ ? ‚backend’ : ‚frontend’ ;

    // Jeśli segment poprzedzajacy jest kontroler to ‚module’,
    // (np. // http://site.pl/backend/module/nazwa_kontrolera),
    // zmienna posłuży do ustawienia odpowiednich scieżek dla
    // szablonów.
    $is_module = @$tmp[1] == ‚module’ ? true : false;

    // begine:
    // for extension from https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/
    // @space w tym przypadku służy do lokalizacji
    $config[‚modules_locations’] = array(
    APPPATH.’controllers/’.$space.’/modules/’ =>
    ‚/’.$space.’/modules/’
    );

    • Ciekawe podejście. Ja stosuję bardziej „standardowe”, czyli trzymam wszystko w katalogu „modules”, czasami też „code_modules”, a każdy moduł (jeśli tego potrzebuje) posiada dodatkowo katalog „admin” (do wiadomych celów).

  2. ps. co nie znaczy że nie można użyć jako modułu, większego komponentu. Nawet jest to wskazane w przypadku gdy jest on kompletnie nie związany z corowom częścią aplikacji np. w przypadku cms-a może to być edytor widoków – zawiera duża ilość bibliotek które nie wchodzą w skład corowej części. Tak jest moja logika używania HMVC. Wiem, że każdy może mieć inną.

  3. Trafiłem na to jakiś czas temu, ale jakoś nie mogłem „uwierzyć”, zwłaszcza po moich pozytywnych doświadczeniach z Kohana jeśli chodzi o ogarnianie HMVC bez zabawy w rozszerzenia. Po przeczytaniu tego posta widzę, że nie taki diabeł straszny…

    Pozdrawiam

    • Dokładnie – nie jest to może rozwiązanie idealne (bo to ciągle tylko rozszerzenie), ale jak się nie ma co się lubi… ;) Całe szczęście, to rozszerzenie jest stale rozwijane – korzystają z niego też dziesiątki projektów, tak więc można na nim polegać.

  4. Witam,
    mam pytanko co i jak ustawić żeby działał moduł w module. Dokładnie chodzi mi o to że w module themes chce dać moduł admin – czyli templatki admina i default- czyli te dla każdego usera. Jak ustawić tą tablicę w configu by to działało? I jak się do tego podmodułu odwołać w przeglądarce?

    • Witaj.

      Nie jestem pewien, czy do końca rozumiem Twoje pytanie, ale postaram się odpowiedzieć.
      Jeśli w danym module chcesz mieć część administracyjną i publiczną, możesz po prostu utworzyć pliki o nazwie np. themes.php i admin.php z odpowiednimi kontrolerami w środku (czyli Themes i Admin). Dostać się do nich możesz wywołując adres: http://adres_projektu/moduł/kontroler/metoda
      Nie ma potrzeby dodatkowego definiowania jakichkolwiek ścieżek.

  5. A ja mam problem z własnym kontrolerem error 404…

    Tak jakby ignorowane jest w ogóle $route[‚404_override’] = „error404”;
    i wyświetla się standardowy error 404 codeignitera.

    Gdzies znalazłem na forach odpowiedzi „beacause you use HVMC” ale zupełnie nie zrozumiałem co zrobić, żeby działało.

    Jakieś pomysły?

    error404 moze byc w modules lub controllers, dla mnie bez różnicy, potrzebuję tylko zaczepienia :)

    • Witaj. Sugeruję sprawdzić z jakiej wersji rozszerzenia HMVC korzystasz. Na chwilę obecną nie ma problemów z ustawieniem własnego kontrolera do obsługi błędów. Może robisz to w niewłaściwy sposób? Jeśli podajesz „error404”, to musisz mieć np. kontroler o tej nazwie z metodą „index”.

  6. Odnośnie tego, to myślalem, ze problem zażegnałem, ale jednak nie.
    Ale mam wspólny mianownik.
    Na lokalu, WAMP, apache, PHP 5.3 dziala to rozszerzenie,
    a na kazdym innym hostingu, którego używam krzyczy na mnie

    Unable to load your default controller. Please make sure the controller specified in your Routes.php file is valid.

    Oczywiście jest „valid”, bo na lokalu działa.
    Pytanie, czy jest jakieś ustawienie PHP, które musi być włączone/wyłączone, by to śmigało?

  7. Co ciekawsze, nie wiem czy to ma znaczenie.

    Jeśli default controller dam do /application/controllers/main.php

    to reszta moze byc w modules/main/controllers/main.php

    I wtedy dziala na tych hostingach…

    Nie wiem czy to ma jakieś znaczenie dla dalszego toku pracy, jak jeden kontroler bedzie tam gdzie powinien byc w standardowej instalacji, a reszta w modułach?

  8. Przepraszam za spam, ale jeszcze jedno spostrzeżenie.

    Wszystko bedzie dzialac jak zostawie katalog /application/controllers i tutaj index.html wystarczy a reszta w /modules… łącznie z default controller…

    Prawidłowo? Czy to coś u mnie?

    • Generalna zasada – nie usuwamy plików i katalogów, które dostarcza CI. Katalogi typu: „controllers”, „models” itp. zawsze powinny zostać – nawet jeśli nie będziemy z nich korzystać.
      Pojawienie się błędu w tym przypadku jest właśnie tym spowodowane. Błąd nie pojawia się lokalnie, ponieważ system windows inaczej radzi sobie z obsługą takiej sytuacji.

  9. A jak się ma to rozszerzenie do CI w wersji 3.0? Wiem, że to dopiero wersja dev, ale próbuję swoich sił.

    moduły które są wywoływane http://www.strona.pl/test działają, ale jeśli ustawiam default_controller na „test” to jest error404…

    W wersji CI 2.2.0 konfiguracja wyglądała właśnie tak i nie było z tym problemu. Jakieś pomysły?

    Oczywiście mogę default controller zrobić poza modules, ale to też nie o to chodzi :)

    • Witaj.

      Osobiście dawno już nie korzystałem z tego rozszerzenia. Ludzie zgłaszali jakieś błędy w połączeniu z CI3, więc możesz spróbować pobrać wersję, o której mowa w tym temacie. Klasa Loader jest tam zmodyfikowana, więc może to rozwiąże problem.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.