Witam,
mam własny skrypt zintegrowany z forum na phpBB3, postanowiłem przerobić go aby był bardziej przenośny i mógł posłużyć do tworzenia innych serwisów dopiętych do for tego typu.
Wszystko było na funkcjach i strukturalnie, postanowiłem zamknąć ile się da w OOP, przez przypadek wyszło że warto od razu wszystko odseparować.

Skrypt ma przyjazne adresy, lecz nie mam żadnego routera, bo faktycznie zajmuje się tym .htaccess. Nie mam zamiaru puszczać wszystkich żądań (np. takich, które zwracają 404) na jeden plik. Są określone moduły i nie ma problemu aby wypisać je w htaccesie, wszystkie wymienione będą jednak iść przez główny plik.

Wygląda on obecnie tak:

[PHP] pobierz, plaintext 
define('IN_PHPBB', true);
 
require_once 'core.php';
 
$module = request_var('module', '');
if (!array_key_exists($module, $modules))
{
  $module = 'news';
}
 
$view = loader::view($modules[$module]['view']);
$view->model = loader::model($modules[$module]['model']);
$view->model->db = $db; // obsluga bazy danych z phpbb3
$view->urls = new urls(true); // Osobna klasa sluzaca do budowy linkow przyjaznych lub zwyklych
 
 
include DIR_MODULES . $module . '.php';
[PHP] pobierz, plaintext 

W pliku core.php są wykonywane takie operacje:
- includowanie głównych plików phpBB3
- start sesji (obiekt $user)
- dołączenie podstawowych stałych i klas


Jest to pierwsza moja zabawa w OOP+MVC i to chyba niestety widać.
Tworzony widok rozszerza klasę bazową, podobnie jest z modelem (klasy te posiadają metody, które są potrzebne we wszystkich modułach).
Sięgnąłem do odpowiedniej lektury i wynika z niej, że to widok ma odwoływać się do modelu. Uznałem więc, że najlepiej będzie zrobić właśnie tak - obiekt modelu jako część widoku.
Includowany na sam koniec moduł można by uznać za "pseudo-kontrolery", które mają np. taką zawartość:

[PHP] pobierz, plaintext 
$id = request_var('id', 0);
 
if (!$id) 
{
  $view->urls->zeroDuplicate('index');
 
  $countNews = $view->model->countNews();
  $news = $view->model->getNewsByPage();
 
	while ($row = $db->sql_fetchrow($news)) //#1
  {
		$view->renderNews($row);
	}
	$db->sql_freeresult($news);
 
  $view->urls->generatePagination($page, $config['portal_news_display'], $countNews, 3, '', 'index');                                                   
} 
else 
{ 
	$news = $view->model->getNewsById($id);
 
	if (!$news) die();		
	$view->urls->zeroDuplicate('news', $news);
  $view->model->updateNewsReadsById($id);
 
	$view->renderNews($news);
} 
 
$view->renderPage();
[PHP] pobierz, plaintext 

Jak widać, tak naprawdę w nich z modelu do widoku trafiają dane, które są potrzebne. Wg. tego co czytałem, kontroler nie powinien zachowywać się jako taki pośrednik, więc coś tu nie gra. Poza tym fragment który zaznaczyłem jako #1 - czy to ma sens leżeć w takim miejscu? Nawet gdyby to było w widoku, jakoś nie pasuje. Wydaje mi się, że powinienem poprzez model zwrócić tutaj gotową tablicę z danymi a nie uchwyt do wyniku zapytania, no ale pewności nie mam.

Kolejna rzecz, w bazowej klasie modelu mam metodę getPanels, która ma za zadanie pobrać zawartość sidebara na stronie na potrzeby metody renderPage klasy bazowej widoku. Najlepiej aby pobrane dane od razu zostały zawartością widoku. Niestety przy takiej konstrukcji dostęp do jego właściwości mam dopiero po użyciu słowa kluczowego global, a to już jest chyba zupełnie bez sensu. Nie mam natomiast pojęcia jak metoda modelu mogłaby się odwołać do właściwości widoku (o ile to nie jest równie bez sensu, bo chyba powinien zwracać wyniki zamiast modyfikować widok, z tym że zastanawiam się nad tym po co 2 razy te same dane trzymać). Tak samo wygląda zresztą sprawa z obiektami które daje mi do dyspozycji phpBB3 - muszę używać global. No chyba że by je przypisać do tych moich obiektów, bo o ile dobrze rozumiem, bez użycia słowa clone nie będę tutaj niczego marnotrawił (tak z głównym pliku wygląda sprawa z $db).

Nie wiem również, czy zamykać i to i to w obiekcie kontrolera (tworzony z modułu + bazowy) czyli np.:

[PHP] pobierz, plaintext 
$controller->view = loader::view($modules[$module]['view']);
$controller->model = loader::model($modules[$module]['model']);
[PHP] pobierz, plaintext 

Z tym, że jeżeli przeniosę zapytania z modelu do widoków, to albo używam global, albo będą one wyglądać raczej tak:

[PHP] pobierz, plaintext 
$news = parent::model->getNewsById($id);
[PHP] pobierz, plaintext 

Czyli znowu kontroler robi się pośrednikiem pomiędzy widokiem a modelem...

Masz rację, zwracanie uchwytu do zapytania to nienajlepszy pomysł. Treść if ... else powinna być właśnie częścią widoku, aczkolwiek nie cała. W drugim bloku masz przecież:



Czy jest to w jakikolwiek sposób związane z wyświetlaniem? Nie, zatem zostawiamy w kontrolerze. Ja to wszystko implementuję w ten sposób, że szablony itd. daję pod widok, czyli dopiero widok decyduje o tym, czy w ogóle korzystać z szablonów, a jeśli tak, to jakich i jak wstawić do nich dane.

Nawiasem mówiąc MVC to nie alfa i omega. Jest jeszcze mnóstwo innych wzorców .

No tak, ale wstyd byłoby go nie znać, a bez praktyki nie da rady


Wczoraj cały wieczór to męczyłem. Z tym parent to się wygłupiłem bo przecież gdy mam np. $view->model->costam(), to rodzicem modelu jest jego klasa bazowa a nie widok... Problem globalnych obiektów z phpBB3 rozwiązałem w taki sposób:

main/view.php

[PHP] pobierz, plaintext 
  (...)
  public function __construct()
  {
    global $auth, $user;
 
    $this->user = $user;
    $this->auth = $auth;
  (...) 
[PHP] pobierz, plaintext 

Zamieniłem też moduł na kontroler i przykładowy wygląda tak:

controllers/controllerNews.php

[PHP] pobierz, plaintext 
class controllerNews extends controller
{
  public function baseAction()
  {
    $this->index();
  }
 
 
  public function index()
  {
    $this->page = (isset($_GET['page']) && $_GET['page'] > 0) ? $_GET['page'] : 1;
 
    $this->view = loader::view('News');
    $this->view->urls = new urls(true);
    $this->view->urls->zeroDuplicate('index');
 
    $this->view->model = loader::model('News');
 
    $this->view->renderNewsList($this->page);
    $this->view->renderPage();
  }
 
 
  public function view()
  {
    $this->id = request_var('id', 0);
 
    $this->view = loader::view('News');
    $this->view->urls = new urls(true);
    $this->view->model = loader::model('News');
 
    $this->view->renderNews($this->id);
    $this->view->model->updateNewsReadsById($this->id);
    $this->view->renderPage();		
  } 
} 
[PHP] pobierz, plaintext 

Tutaj mam pytanko, jak widać obie metody ładują ten sam widok i ten sam model - warto to wrzucać do konstruktora tego kontrolera?
Nie wykluczam oczywiście, że w wypadku innych kontrolerów coś takiego nie będzie możliwe, więc nie wiem czy to minimalizacja, czy robienie bałaganu.

Jak widać, w wypadku akcji index (czyli strona główna, lista newsów) jest z url'i wywoływana metoda zeroDuplicate - sprawdza ona, czy adres jest poprawny i jeżeli nie, robi redirecta.
To samo zachodzi również w drugiej akcji, ale obecnie jest zaszyte w view->renderNews() bo... aby sprawdzić czy adres newsa jest prawidłowy, muszę mieć jego dane, a one są pobierane przez widok właśnie w tej metodzie:

views/viewNews.php

[PHP] pobierz, plaintext 
  public function renderNews($id) 
  {
    $content = $this->model->getNewsById($id);
    if ($content)
    {
      $this->urls->zeroDuplicate('news', $content);
[PHP] pobierz, plaintext 

No i teraz mam dylemat... w sumie myślę, że powinienem to jednak przenieść do kontrolera i dzięki if'owi wybierać, jeżeli znaleziono news:
- sprawdzam adres
- wyświetlam newsa
- aktualizacja licznika czytań
Jeżeli nie ma to z głównej klasy widoku wywołuję metodę np. renderError (której de facto nie ma jeszcze, ale właśnie uznałem że tak by można zrobić).
Czyli mniej więcej tak by to wyglądało:

[PHP] pobierz, plaintext 
  public function view()
  {
    $this->id = request_var('id', 0);
 
    $this->view = loader::view('News');
    $this->view->urls = new urls(true);
    $this->view->model = loader::model('News');
 
    $this->content = $this->view->model->getNewsById($this->id); #1
    if ($this->content)
    {
      $this->view->urls->zeroDuplicate('news', $content); #2
      $this->view->renderNews($this->id);
      $this->view->model->updateNewsReadsById($this->id); #1
    }
    else
    {
      $this->view->renderError('notFound');
    }
    $this->view->renderPage();		
  } 
[PHP] pobierz, plaintext 

Tutaj pojawia się pytanie o sam styl - zaznaczone jako #1 - dane te są potrzebne widokowi i pobierane z niego, ale jak widać dzieje się to w kontrolerze. Oczywiście to działa, ale czy nie kłóci się z żadną zasadą? Czy nie powinienem tego pobierać / aktualizować (aktualizacja licznika czytań) poprzez kontroler? Obecnie jak widać nie ma on innego dostępu do modelu, jak przez widok, chyba lepszym rozwiązaniem będzie zrobić jednak tak:

[PHP] pobierz, plaintext 
    $this->model = loader::model('News'); 
    $this->view->model = $this->model;
[PHP] pobierz, plaintext 

Podobnie ma się sprawa z url'ami oznaczonymi w kodzie jako #2 - widok musi korzystać z jego metod, tego jestem pewien. Czy jednak sprawdzanie adresu przez kontroler powinno się odbywać właśnie za pośrednictwem widoku, czy lepiej zrobić tak samo jak w powyższym kodzie, czyli dać url'e najpierw do kontrolera, a potem do widoku? Tutaj nie wiem jak wygląda sprawa wydajności, czy nie tracę na takim rozwiązaniu? W sumie jeżeli tak zrobię, to chyba mam jakieć MVCU

Ogólnie rzecz biorąc, są obiekty które potrzebne mogą być w modelu, widoku, kontrolerze. Nie wiem czy umieszczać je w jednej z tych części i przez nią używać, czy wrzucać do każdej w której są potrzebne, acz to drugie rozwiązanie wydaje mi sie strasznie bałaganiarskie.