Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Zarządzanie wieloma aplikacjami w jednym FW
Forum PHP.pl > Forum > PHP
uncuncunc
Większość FW (framework) wygląda tak:

Kod
/public_html
- app1
- framework
- index.php


I wszystko przechodzi przez index.php, odpalany jest router, wczytywana aplikacja w folderu app1 i wszystko gra. Jednak jak stworzyć swego rodzaju ekosystem dla kilku aplikacji? Każda aplikacja to osoby folder z index.php? Czy FW w routerze powinien przekierować na inną aplikacje? Czyli gdy mamy uruchomioną aplikacje app1, i w niej router wykryje np. reglog => 'app3' to zostanie wczytana aplikacja app3? Czy router, powinien mieć swój router wszytkich aplikacji i na jego podstawie wczytywać konkretną, czy robić to inaczej?

Jak rozwiązujecie tego typu sprawy?
marcio
Kurde wlasnie wczoraj przegladalem source jakiegos fw i maja tam wlasnie to o czym ty mowisz.
Django tez posiada takie cos, poprostu do aplikacji mozesz includowac routing jakiegos modulu by wspolpracowal z twoja aplikacja.

Ogolnie to zalezy jesli wszystkie projekty masz na jednym serwerze i pod jedna domena to moze i tak to dzialac jak mowisz w przeciwnym wypadku mysle ze osobny server dla kazdej aplikacji bylby lepszy rozwiazaniem...

P.S tak jak napisal @Vokiel pomylilo mi sie gdzie subdomena inna a server ten sam
vokiel
Zależy co chcesz osiągnąć. Przykładowo, możesz mieć taką strukturę:
Kod
/domains
    - core_frameworka
    - domena1.com
        - public_html
            - index.php
            - assets (css, js, img)
    - domena2.com
        - public_html
            - index.php
            - assets (css, js, img)

Korzystasz z tych samych plików frameworka w każdej aplikacji. Takie podejście jest ok w projektach, gdzie każda domena (aplikacja) jest inna ale opiera się na tym samym frameworku (w tej samej wersji).
uncuncunc
Tak, tylko jak to ma wyglądać od strony routingu? Kombinuje napisać własny (tak dla testu) i wykombinowałem coś takiego:

Kod
/core_fw
/app1
- /config/routing.php

/app2
- /config/routing.php

index.php


Wszytko idzie przez index.php, obie apliakcje korzystają z jednego FW. W index.php odpalam klasę router, która odczytuje plik routing.php z katalogu /app1/config bo załóżmy że ta aplikacja jest pierwsza(domyślna) i uruchamia się jako główna. To w niej mam zdefiniować to kiedy ma się odpalić app2? np. po URI czy domenie?

Edycja: bo myślę jescze nad czymś takim, że w katalogu FW byłby plik app_route.php który byłby sprawdzany przez klasę router jako pierwszy, w nim byłaby tablica np. sprawdzająca czy domena się zgadza, albo uri i wtedy byłaby wczytywana odpowiednia aplikacja.
vokiel
A jaki framework?
Taka np Kohana, współdzieli moduły i core, natomiast każda aplikacja ma swoje własne pliki. Tak też, jak widać w podanym przeze mnie przykładzie, każda domena ma swój własny plik index.php, własne pliki aplikacji, współ-korzysta z plików core frameworka i modułów.
uncuncunc
Nie wybrałem FW, bo eksperymentuje z trzema, ZF, CI i własnym. I bardziej przychylam się właśnie do czegoś w stylu app_route, dla "FW", byłby zawsze wczytywany jako pierwszy i to w nim aplikacje były deklarowane kiedy mają zostać uruchomione, oczywiście osobny routing dla nich samych.
lobopol
Symfony 2 ma tak zwane bundle, które w zasadzie mają własną konfiguracje i są w praktyce oddzielnymi aplikacjami.
lukaskolista
nie prosciej zrobic to tak, jak zrobione sa panele administracyjne?

Frontend:
http://example.com/kontroler/akcja

Backend:
http://example.com/admin/kontroler/akcja

Przy czym struktura plikow wyglada tak:
application/classes/controller/ a w nim katalogi: frontend i backend.
Przekierowanie do odpowiedniego katalogu uzyskuje sie wlasnie za pomoca routingu. (jezeli routing wykryje admin w 1 czlonie sciezki to korzysta z kontrolera w katalogu backend, jezeli nie to z katalogu frontend.
Nie znam Twojego frameworka, wiec musisz pokombinowac sam.
Struktura plikow jest oczywiscie schematyczna zeby mi ktos nie napisal, ze on robi inaczej i moje jest ble.

Vokiel wspomnial o kohanie:
faktycznie ma ona dosyc dobry system routingu, nie znalazlem problemu, ktorego nie moznaby za pomoca tego systemu routingu rozwiazac (moze kiedys sie znajdzie)
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.