Begrijp ik het goed dat Form & Post allebei een model zijn volgens jouw? Aangezien ze in de map 'models' staan..
Op zich is het opslaan en terughalen van berichten ook de taak van je model***, maar minstens zo belangrijk is dat de model beschrijft hoe de data eruit ziet, en hoe er mee omgesprongen moet worden. Je model moet beschrijven hoe een post eruitziet, welke eigenschappen een post heeft. Je model bevat een bouwplaat van een post: een klasse die een post beschrijft :)
<?php
class Post {
protected $_title;
protected $_content;
public function __construct($title, $content) {
$this->_title = $title;
$this->_content = $content;
}
public function title() {
return $this->_title;
}
public function content() {
return $this->_content;
}
}
?>
Iedere post in je gastenboek wordt gerepresenteerd door een instantie van de bovenstaande klasse. De instantie bevat de gegevens van de post. Dat deel had je dus op zich al goed :)
Echter, de Post-klasse beschrijft alleen hoe een Post eruit ziet, niet waar hij vandaan komt en hoe hij wordt opgeslagen. Laten we daar ook weer een onderdeel van je model voor maken. In het echt zou deze bijvoorbeeld naar een webservice, bestand of database schrijven, maar laten we het even simpel houden:
<?php
class Post_Store {
public function find_all() {
$posts = array();
foreach($_SESSION['posts'] as $post_data) {
$posts[] = new Post($post_data[0], $post_data[1]);
}
return $posts;
}
public function insert(Post $post) {
$_SESSION['posts'][] = array($post->title(), $post->content());
}
}
?>
De opslag van al je posts, een instantie van Post_Store, heeft twee methods vandaag: Eentje om alle posts weer terug te halen, en eentje om er een op te slaan. Zoals je ziet geef ik hem voor het opslaan niet de titel en de content, maar werkelijk een post. En ook bij het ophalen geeft hij niet data terug, maar Post-objecten, oftewel posts :) Object georiënteerd immers, we denken hier in objecten, en niet meer in data in arrays. Okee, de objecten zitten in een array, maar hoe wou je anders een lijstje teruggeven. Belangrijk is hier dat het niet de array is die beschrijft welke eigenschappen een post heeft, maar de Post klasse.
Op zich loop je bij deze setup redelijk snel tegen beperkingen op, je wil soms wat rouwere data opslaan in de database dan de data die de "getters" van het Post-object teruggeven. Op zich niet zo'n probleem, dan maak je er een method bij die de interne rauwe data teruggeeft van een Post instantie. Je moet jezelf er dan op behoeden alleen die method in de Post_Store klasse te gebruiken, en nergens anders, want anders is het idee dat de klasse Post je post beschrijft niet meer waterdicht.
Waarom wil je dat je klasse Post je post-gegevens bevat en niet gewoon een multidimensionale array die je terugkrijgt uit een mysql_fetch_assoc aantal keer aanroepen? Omdat de rest van je applicatie, op je Post en Post_Store klasse na, zich nu niet meer druk hoeven te maken over hoe de data wordt opgeslagen en bewaard. Ik kan helaas niet op een goed praktisch voorbeeld komen waarom je niet een array in plaats van een object zou willen gebruiken (alles kan je in theorie ook wel oplossen in de Post_Store klasse, of met wat extra SQL code) maar het voordeel van al je gastenboek-queries op één centrale plek, Post_Store, lijkt mij redelijk simpel: Je hoeft je query maar op één plek aan te passen wanneer je je database verandert.
Nu even naar je form. Dit is geen model, het
representeert immers geen data (het presenteert ze wel :P, wat het deel van je view maakt als je MVC wilt aanhouden)
Nu nog even een compleet voorbeeldje van hoe je je posts als objecten kan beschouwen. Zeg maar MVC, maar dan zonder V en C :)
<?php
error_reporting(E_ALL);
ini_set('display_errors', true);
class Post {
protected $_title;
protected $_content;
public function __construct($title = '', $content = '') {
$this->_title = $title;
$this->_content = $content;
}
public function set_title($title) {
$this->_title = $title;
}
public function title() {
return $this->_title;
}
public function set_content($content) {
$this->_content = $content;
}
public function content() {
return $this->_content;
}
public function is_valid() {
/* Eisen:
* - de titel mag niet leeg zijn
* - de inhoud moet meer dan 3 tekens lang zijn
*/
return strlen($this->_title) > 0 && strlen($this->_content) > 3;
}
}
class Post_Store {
public function __construct() {
// zorg ervoor dat $_SESSION beschikbaar is
@session_start();
if(!isset($_SESSION['posts'])) {
$_SESSION['posts'] = array();
}
}
public function find_all() {
$posts = array();
foreach($_SESSION['posts'] as $post_data) {
$posts[] = new Post($post_data[0], $post_data[1]);
}
return $posts;
}
public function insert(Post $post) {
// klopt de post? We willen geen foute posts in de opslag
if(!$post->is_valid()) {
throw new Exception('Het bericht is incompleet');
}
$_SESSION['posts'][] = array($post->title(), $post->content());
}
}
$action = isset($_GET['action']) ? $_GET['action'] : 'list';
$posts = new Post_Store();
if($action == 'add') {
$new_post = new Post();
if($_SERVER['REQUEST_METHOD'] == 'POST') {
$new_post->set_title($_POST['title']);
$new_post->set_content($_POST['content']);
// voldoet de post?
if($new_post->is_valid()) {
$posts->insert($new_post); // invoegen
header('Location: 58732.php?action=list'); // toon alle berichten weer
} else {
echo 'Je bericht voldoet nog niet helemaal.';
}
}
echo '<form method="post" action="">';
echo 'Titel: <input type="text" name="title" value="' . htmlentities($new_post->title()) . '"><br>';
echo 'Inhoud: <input type="text" name="content" value="' . htmlentities($new_post->content()) . '"><br>';
echo '<button type="submit">Submit</button>';
echo '</form>';
} elseif($action == 'list') {
echo '<a href="58732.php?action=add">Bericht toevoegen</a>';
echo '<ul>';
foreach($posts->find_all() as $post) {
echo '<li>';
echo '<strong>' . htmlentities($post->title()) . '</strong>';
echo htmlentities($post->content());
echo '</li>';
}
echo '</ul>';
} else {
echo '400 Onbekende actie';
}
?>
*** Al je business-logic kan het beste eigenlijk in je model-deel van de applicatie, op zo'n manier dat je je models, en dus je business-logic overal met dezelfde klassen kan implementeren. Op die manier kan je dezelfde bestanden hergebruiken voor je website, je admin-paneel, je interne administratie, en je cron-jobs, etc. Door één centraal setje models te hebben heb je geen verschil in business-logic over de verschillende onderdelen van je onderdelen. Gevolg is wel dat je je models niet afhankelijk kan maken van een framework dat niet op alle plekken waar je de models gaat gebruiken beschikbaar is.
knop om je tekst aan te passen.