[CI] Utrata obiektu w momencie załączenia pliku.

[CI] Utrata obiektu w momencie załączenia pliku., Include/require gubi obiekt, ale tylko jako metoda...

markonix Zobacz profil	27.07.2012, 19:10:26 Post #1
Grupa: Zarejestrowani Postów: 2 707 Pomógł: 290 Dołączył: 16.12.2008 Skąd: Śląsk Ostrzeżenie: (0%)	W moim CI mam małą klasę template i się sprawdza ale chce podzielić szablon dodatkowo na moduły ponieważ mimo, że są różne templatki to np. nagłówek jest zawsze ten sam (albo się powtarza w wielu templatkach). Przykładowy kod templatki: [PHP] pobierz, plaintext <?php include('application/views/elements/header.php'); ?> Jakiś HTML <?= $content; ?> <?php include('application/views/elements/footer.php'); ?> [PHP] pobierz, plaintext Działa bez zarzutu. Ale chciałbym to zrobić ładnie i zrobić metodę, która by sprawdzała czy element istnieje jednakże gdy wywołam taką metodę: [PHP] pobierz, plaintext $this->template->add_element('header'); [PHP] pobierz, plaintext w której dla uproszczenia problemu dodam tylko sam include to gubi obiekt tank_auth, który jest w $autoload['libraries']. Obiekt ten przestaje działać także po wykonaniu funkcji poza includowanym plikiem. Obiekt ten potrzebuje aby troszkę zmienić wygląd nagłówka w przypadku gdy user jest zalogowany. Nie umiem pojąć dlaczego surowy include nie sprawia problemów, a już include w metodzie tak... Nie wiem czy to w ogóle kwestia CI czy PHP. Ten post edytował markonix 27.07.2012, 19:11:30

Odpowiedzi

thek Zobacz profil	27.07.2012, 21:17:43 Post #2
Grupa: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D	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 (IMG:style_emoticons/default/wink.gif) 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 (IMG:style_emoticons/default/wink.gif) Masz więc wtedy, idąc ścieżką działań, coś w deseń: [PHP] pobierz, plaintext $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(); [PHP] pobierz, plaintext A jak mógłby wyglądać widok ukryty pod ścieżką "jakiś_path_do_bazowego" ? [HTML] pobierz, plaintext <html> <head> <?php echo $header; ?> </head> <body> <?php echo $content; ?> <?php echo $footer; ?> </body> </html> [HTML] pobierz, plaintext 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.

Posty w temacie

markonix [CI] Utrata obiektu w momencie załączenia pliku. 27.07.2012, 19:10:26

thek A ja bym się zastanawiał czy taki sposób w jaki ch... 27.07.2012, 21:17:43

markonix CI to mój pierwszy framework, ma tylko standardowe... 28.07.2012, 15:04:29

thek Nie do końca to, ale można też wykorzystać by jako... 29.07.2012, 15:15:53

mieszkos eh.. markonix, poczytaj dużoooooo o CI, chociażby ... 9.08.2012, 00:03:07

markonix Cytat(mieszkos @ 9.08.2012, 01:03:07 ... 9.08.2012, 08:15:30

« Następny starszy · Frameworki · Następny nowszy »

2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)

0 Zarejestrowanych:

Forum PHP.pl