A ja bym się zastanawiał czy taki sposób w jaki chcesz to robić jest dobry. Może to już naleciałość z Kohaną związana, ale ja bym rozbijał te "moduły" inaczej. Nie wiem czy wiesz jak to wygląda w Kohanie bowiem. Jednym z popularniejszych sposobów jest utworzenie kontrolera szablonowego, który ma swój widok bazowy. Bazowy to goły html z kilkoma miejscami przewidzianymi do wypełnienia. Wszystkie zależne kontrolery dziedziczą po nim i tylko uzupełniają luki. Ty masz dość podobnie.
Weź więc sobie stwórz szablonowy widok, gdzie zamiast używać include będzie wypisanie zmiennej $header, $content i $footer. Zmienne te możesz mieć domyślnie w bootstrapie ustawione, ale w razie czego możesz wywołać sobie metodę zmieniającą tymczasowo określoną z nich.
Całość widoku to moim zdaniem powinien być jeden obiekt, przy czym właśnie własności tego obiektu i ich wzajemne zagnieżdżenie dały by Ci to czego chcesz. Czemu? Bo obiekt widoku miałby metodę __toString(), która ładnie by Ci z obiektu klasy tworzyła ciąg znakowy.... który mógłby być w nieskończoność zagnieżdżany. Co to daje? Ano pomyśl... Masz obiekt widoku, który renderujesz, czyli sprowadzasz do stringa. Jako że pierwszy jest jakiś bazowy to leci jego html i w pewnym momencie napotyka obiekt podwidoku... który też się do stringa konwertuje i dokleja gdzie trzeba
Jeśli czegoś braknie to oczywiście leci wyjątek, że podwidok taki i taki nie może być prawidłowo skonwertowany, bo jakaś tam zmienna jest pusta/nie istnieje/nie jest zainicjalizowana. Oczywiście na czym to polega? Klasa View czy jak ją nazwać ma w konstruktorze ścieżkę (lub jej część) do pliku html "z dziurami". My tylko te dziury uzupełniamy, ale śmiało jako dziurę możemy wstawić kolejny obiekt klasy View, który też ma jakieś tam swoje zmienne, jest czystym html lub jest na pałę stringiem. Summa sumarum i tak będzie to jedno wielkie konwertowanie obiektu z użyciem __toString() do ciągu znakowego
Masz więc wtedy, idąc ścieżką działań, coś w deseń:
$base = new View('jakiś_path_do_bazowego');
$base->header = new View('jakiś_nagłówkowy');
$base->content = new View('strona_główna');
$base->content->sidebar = new View('menu_boczne');
$base->content->main = new View('zawartość_główna');
$base->footer = '<div id="footer">A co? Nie wolno mi tak? Wolno.</div>';
$base->render();
A jak mógłby wyglądać widok ukryty pod ścieżką "jakiś_path_do_bazowego" ?
<?php echo $header; ?>
<?php echo $content; ?>
<?php echo $footer; ?>
przy czym część z tych rzeczy możesz zrobić "z automatu" przy głównym pliku aplikacji i w razie czego "podmienić" w razie potrzeby w kontrolerach potomnych. Bo kto Ci zabroni choćby tak napisać widok header, by pliki css, js czy znaczniki meta nie mogły być dodawane dynamicznie z użyciem jakiejś klasy do wstrzykiwania tego tam?
Oczywiście to jest tylko pomysł jak zrobić sobie dość elastyczne rozwiązanie widoków i implementację już zostawiam Tobie, ale myślę, że to elastyczniejsze rozwiązanie niż walenie na pałę include do widoku, bo grzebać się potem z tym by w określonych wypadkach zamiast include domyślnego nagłówka dać coś innego.... masakra się robi. A tak masz jedną klasę dla które piszesz konwersję z obiektu do stringa i łapiesz wyjątki jeśli zmienne php zaszyte w podanym przez ścieżkę pliku nie są podczas konwersji ustawiane.
