Witam.
Od jakiegoś czasu bawię się w MVC i powiem, że spodobało mi się. Dochodząc do pewnego etapu dręczy mnie kilka pytań.
1. Czy model powinien być bezpośrednio klasą do obsługi bazy danych (liczę tylko na te źródło danych) ? Czy może czymś pośrednim ?
2. Chcę zastosować możliwość implementacji przyjaznych url'i za pomocą RewriteRule. Wszystko dobrze działa. Pomyślałem, że trzeba by dodać coś na wypadek gdyby jakiś serwer nie obsługiwał htaccess. Ok. To dodam w pliku konfiguracyjnym zmienną odpowiadającą za to czy użyć htaccess czy nie.
Gdzie powinienem generować format linków ? W widoku czy w modelu ? A i jak wykryć w php czy można korzystać z htaccess i RewriteRule ?
3. Jeśli chodzi o pojedyncze zmienne w szablonach to nie ma problem. Wczytam sobie plik, przerobię i gotowe. A co z blokami danych takimi jak newsy ? Trzeba zrobić osobny szablon bloku newsa i w pętli (w widoku) go przetwarzać oraz dodawać do reszty strony ? Czy może jest na to inny, lepszy sposób ?

Z góry dzięki za pomoc.

Model powinien tylko trzymac obiekt danego sterownika tdo obslugi baz danych gdzie np typ sterownika trzymasz w konfiguracji wtedy latwo go zmienic:

[PHP] pobierz, plaintext 
<?php
 
require_once('interfaces/IModel.php');
require_once('libraries/Db.php');
 
abstract class Model extends Imports {
 
 
 public $db;
 
 
 public function __construct() {
 
 
  $cfg = Loader::load('Cfg');
  $this -> db = Db::Factory($cfg -> DbType);
 
 
 }
 
}
 
?>
[PHP] pobierz, plaintext 

U mnie tak to wyglada po czym kazdy komponent/plugin ma wlasny model ktory dziedziczy po tym i wywoluje constrcut parenta w klasie modelu komponentu/pluginu.


Zalezy co masz na mysl poprzez szablon cos a'la smarty czy html+podstawowa skladnia php?
Jesli szablon za pomoca wyrazen regularnych musisz aim implementowac if/for/foreach/else/elseif lub robisz wszystko na poziomie kontrolera gdy ustawisz dane widoku co nie jest polecane.
Jak masz html+podstawowa skladnia php to juz jest prosciej za pomoca extract() wczytujesz tablice a w widoku robisz sobie foreach() na tablice i wszystko hula

Ad. 1 - nie. Model ma być skrzynką, która jest odpytywana na zasadzie "daj mi wszystkie newsy" bez przejmowania się, skąd te newsy pochodzą czy jak są pobierane.
Ad. 2 - widok.
Ad. 3 - szablon z pętlami. Właściwie widok powinien się składać ze skryptu, którego zadaniem jest pobranie danych z modelu, ew. zainicjowanie stronicowania i temu podobnych rzeczy oraz szablonu, który pobrane dane osadza w HTML-u. Natomiast wbrew temu co pisze marcio, szablon to szablon bez względu na to, czy jest napisany w PHP czy w innym języku i wcale wyrażeń regularnych nie potrzebujesz, by go parsować (chyba że piszesz własny system szablonów).

A czasem za generowanie linków nie odpowiada Router? (element kontrolera) Chyba że autorowi tematu chodziło o uruchomienie procedury tworzącej link, jeśli tak to powinno to zachodzić w widoku a nie w modelu, ale sam proces budowy linku odbywa się w routerze.

1. Rozumiem, że w takim razie powinienem mieć klasę, która będzie łącznikiem między modelem a klasą bazy ?
Coś jak:
- model wysyła żądanie do tego "łącznika" (np. pobierz('news', 'all') )
- "łącznik" uruchamia odpowiednią funkcję wywołującą (w moim przypadku) zapytanie sql i kieruje je do klasy bazy

2. Dokładnie chodzi mi o to, że przy tworzeniu strony podajemy "parametry" linku i zostaje z tego utworzony odpowiedni link.
Np. polecenie :
$link->set('galeria', 'pokaz', '3');
da:
strona.pl/galeria/pokaz/3
lub:
strona.pl?controller=galeria&action=pokaz&id=3
i wyśle ten link w swoje miejsce w szablonie

3. Jako szablon rozumiem w miarę czysty plik html gdzie mam tylko elementy takie jak {ZMIENNA}, za które podstawiam odpowiednie wartości. W tej sytuacji wolałbym nie umieszczać w tych plikach pętli (o ile to możliwe).

Ad.1 Źle rozumiesz. Model powinien być pisany pod konkretny typ źródła danych. Więc w modelu powinieneś bezpośrednio odwoływać się do PDO. Jeśli chcesz korzystać z innego źródła danych, powinieneś dla niego utworzyć oddzielny model i w zależności od ustawień w konfiguracji ładować tylko ten który potrzebujesz (wynika to z faktu, że PDO się zapewne będą różniły między sobą). Warstwa kontrolera i widoku nie powinna być świadoma z jakiego źródła danych korzysta aplikacja natomiast model już tak.