W dużym skrócie, jeśli używasz setlocale() to rzutowanie typów danych może działać nieprzewidywalnie. Polecam wpis Marka. Jednak grzebiąc nieco po php.net okazało się, że jest jeden sposób na zmianę typu, która bierze pod uwagę locale:

$pi = 3.141593;
echo (float)(string)$pi ."\n";
var_dump(setlocale(LC_NUMERIC, 'pl_PL.utf8'));
$polishPi = 3.141593;
// poniżej "problematyczne" rzutowanie
echo "string: " . (string)$polishPi ."\n";
echo "float: " . (float)(string)$polishPi ."\n";
echo "floatval(): " . floatval((string)$polishPi) ."\n";
echo "double: " . (double)(string)$polishPi ."\n";
echo "real: " . (real)(string)$polishPi ."\n";

//settype wydaje się działać dobrze z setlocale
var_dump(settype($polishPi, "double")); // można użyć "float"
echo "settype(): " . $polishPi ."\n";
var_dump(gettype($polishPi));
var_dump($polishPi*2);
var_dump(gettype($polishPi*2));

out:

3.141593
string 'pl_PL.utf8' (length=10)

string:		3,141593

float:		3

floatval():	3

double:		3

real:		3
boolean true

settype():	3,141593
string 'double' (length=6)

float 6,283186

string 'double' (length=6)

Tak czy siak, podzielę się z Wami moimi pomysłami.

Zacznijmy od początków. Przeciwieństwem leniwego ładowania jest ładowanie gorliwe (lub zachłanne), to znaczy ładowanie na zapas wszystkiego co może okazać się potrzebne. Warstwa modelu w cake’u mogła by wyglądać tak (duże uproszeczenie, jedyna możliwa relacja to belongsTo).

Eager Loading

class Model {
	function find(){

		$r = new ReflectionClass($this);
		print "calling ".$r->getName()."::find($conditions)";

		$query = "Select * from `".strtolower($r->getName())."s` ".
					"as `".$r->getName()."`";

		var_dump($query);

		//return query result
	}

	function __construct(){
		$r = new ReflectionClass($this);
		print("creating ".$r->getName()."
");
		if(isset($this->belongsTo) && is_array($this->belongsTo)){
			foreach($this->belongsTo as $related){
					$this->{$related} = new $related();
			}
		}
	}
}

class User extends Model{
	protected $belongsTo = array("Group");
}

class Group extends Model{
}

$user =  new User();

$user->find();
echo "
";
$user->Group->find();

Widzimy, że obiekt Group jest inicjowany długo przed użyciem:

creating User
creating Group
calling User::find()

string 'Select * from `users` as `User`' (length=31)

calling Group::find()

string 'Select * from `groups` as `Group`' (length=33)

Mało tego, ładuje się nawet jeśli nigdy nie wywołamy metody w tym obiekcie (zakomentuj $user->Group->find(); żeby się o tym przekonać).

Lazy Loading

class Model {
	function find(){

		$r = new ReflectionClass($this);
		print "calling ".$r->getName()."::find($conditions)";

		$query = "Select * from `".strtolower($r->getName())."s` ".
					"as `".$r->getName()."`";

		var_dump($query);

		//return query result
	}

	function __construct(){
		$r = new ReflectionClass($this);
		print("creating ".$r->getName()."
");
	}

	function __get($property){
		if(!isset($this->{$property})) {
			$this->{$property} = new $property();
		}
		if(in_array($property, $this->belongsTo)){
			return $this->{$property};
		}else{
			$r = new ReflectionClass($this);
			throw new Exception(
				"$property not related with {$r->getName()}"
			);
		}
	}
}

class User extends Model{
	protected $belongsTo = array("Group");
}

class Group extends Model{
}

$user =  new User();

$user->find();
echo "
";
$user->Group->find();

W tym rozwiązaniu obiekt Group nie zostanie stworzony, dopóki nie będziemy go potrzebować. Wykorzystana jest do tego magiczna metoda __get, która jest wywoływana wtedy, gdy próbujemy się odnieść do atrybutu obiektu, który nie istnieje.

ale pozostaje kwestia wyszukiwania w modelu tak, żeby zwrócił powiązane dane
np.: var_dump($user->find());

array
  0 =>
    array
      'User' =>
        array
          'id' => int 1
          'name' => string 'Franek' (length=6)
      'Group' =>
        array
          'id' => int 1
          'name' => string 'Admin' (length=5)
  1 =>
    array
      'User' =>
        array
          'id' => int 2
          'name' => string 'Janek' (length=5)
      'Group' =>
        array
          'id' => int 10
          'name' => string 'User' (length=4)

Wiemy, że belongsTo oznacza, że User powinien mieć pole (group_id), zatem query powinno wyglądać mniej więcej tak:

Select User.id, User.name, Group.id, Group.name from users as User
Inner Join groups as Group on (User.group_id = Group.id)

W tej chwili cakephp zawiera behavior containable, jednak on polega na załadowanych już modelach.

Zostańmy przy terminologii cake’a i przyjmijmy, że będziemy przekazywać informacje na temat powiązanych elementów w zmiennej $contain

function find($contain=null)

Teraz chciałbym powiedzieć: obiekcie $user zwróć mi wszystkich użytkowników z bazy wraz z informacją w jakich są grupach:

$user =  new User();

$user->find(
	array(
		"belongsTo" => array($user->Group)
	)
);

Zatem zaktualizuję metodę find:

	function find($contain=null){

		$r = new ReflectionClass($this);
		print "calling ".$r->getName()."::find($conditions)";

		$query = "Select * from `".strtolower($r->getName())."s` ".
					"as `".$r->getName()."` \n";

		if(!empty($contain) && is_array($contain["belongsTo"])){
			foreach($contain["belongsTo"] as $belongsToModel){
				$query .= $belongsToModel->getBelongsToJoin($this);
			}
		}

		var_dump($query);

		//return query result
	}

która od teraz zakłada, że model posiada metodę, która potrafi utworzyć odpowiedniego joina:

	function getBelongsToJoin($obj){
		$owner_reflection = new ReflectionObject($this);
		$obj_reflection = new ReflectionObject($obj);
		return "INNER JOIN `".strtolower($owner_reflection->getName())."s`
					as `".$owner_reflection->getName()."`
						ON (`".$owner_reflection->getName()."`.`id` = `".$obj_reflection->getName()."`.`".strtolower($owner_reflection->getName())."_id`)
					";
	}

to jest oczywiście bardzo brzydkie ze względu na refleksje. Metodę getName() można jednak zaimplementować w klasie Model.

Tak czy siak, w tym wypadku nawet w find()’zie uwzględniającym relacje można stosować Lazy Loading

Na koniec całość kodu, z większą ilością relacji i przykładem działania (i małym refactoringiem – skoro już mowa o lazy loading to głupio było ładować piętnaście razy ReflectionClass):

class ModelException extends Exception{}

class Model {

	protected $reflection = null;

	function getName(){
		if(is_null($this->reflection)){
			$this->reflection= new ReflectionClass($this);
		}
		return $this->reflection->getName();
	}

	function getTableName(){
		return strtolower( $this->getName() . "s" );
	}

	function getFKName(){
		return strtolower( $this->getName() . "_id");
	}

	function getBelongsToJoin($obj){
		$owner_reflection = new ReflectionObject($this);
		$obj_reflection = new ReflectionObject($obj);
		return "INNER JOIN `".$this->getTableName()."`
					as `".$this->getName()."`
						ON (`".$this->getName()."`.`id` = `".$obj->getName()."`.`".$this->getFKName()."`)
					";
	}

	function find($contain=null){

		$r = new ReflectionClass($this);
		print "calling ".$r->getName()."::find($conditions)";

		$query = "\nSelect * from `".strtolower($r->getName())."s` ".
					"as `".$r->getName()."` \n";

		if(!empty($contain) && is_array($contain["belongsTo"])){
			foreach($contain["belongsTo"] as $belongsToModel){
				$query .= $belongsToModel->getBelongsToJoin($this);
			}
		}

		var_dump($query);

		//return query result
	}

	function __construct(){
		$r = new ReflectionClass($this);
		print("creating ".$r->getName()."
");
	}

	function __get($property){
		if(!isset($this->{$property})) {
			$this->{$property} = new $property();
		}
		if(in_array($property, $this->belongsTo)){
			return $this->{$property};
		}else{
			$r = new ReflectionClass($this);
			throw new ModelException(
				"$property not related with {$r->getName()}"
			);
		}
	}
}

class User extends Model{
	protected $belongsTo = array("Group", "Unit", "Company");
}

class Group extends Model{
}

class Unit extends Model{}
class Company extends Model{}

$user =  new User();

$user->find(
	array(
		"belongsTo" => array($user->Unit, $user->Company)
	)
);

Wiem, że brzmi to może jak banał, ale to nie jest jakaś wytyczna ustalona raz na początku projektu. Zrozumienie tego zajęło mi 4 lata. Nie możesz się umówić, że od teraz, od tego projektu, od tej funkcji będziesz pisał kod wysokiej jakości.

Możesz umówić się, że będziesz pisał kod o jakości najlepszej na jaką Cię w tym momencie stać.

Jednak w międzyczasie nauczysz się czegoś nowego. Wysokiej jakości kodu to taki, którego jakość rośnie ciągle. Nie tylko wraz z dodawaniem nowych linii. Również trafiając na kod z przed roku warto pochylić się nad nim.

Czy masz zespół, który stosuje zasadę skautów?

Chciałbyś być członkiem takiego zespołu?

Jak zawsze – staraj się myśleć, żeby nie popaść w przesadę.

Jak już mogłeś przeczytać na wikipedii, long polling oznacza po prostu zapytania (w naszym przypadku zapytania XHR, czyli ajax), które potrafią czekać bardzo długi czas na odpowiedź serwera. Serwer w ogóle nie odpowiada dopóki coś interesującego (z punktu widzenia zapytania) się nie pojawi.

Istnieją dwa możliwe przypadki:

1. coś się pojawia (w naszym przypadku nowy post w bazie danych), zatem serwer wysyła informacje, zapytanie kończy się sukcesem i robi coś użytecznego z otrzymanymi danymi
2. nic się nie pojawia przez jakiś czas, zapytanie kończy się timeoutem.

Oba kończą się jednak tym samym – wywołaniem kolejnego zapytania, które będzie oczekiwało, aż wydarzy się coś interesującego.

Pewnie masz kilka pomysłów jak to zaimplementować. Jeśli tak – wypróbuj je teraz (oraz jeśli różnią się od mojego rozwiązania – chętnie je obejrzę, więc wrzuć je w komentarzu.)

Po drodze można się natknąć na kilka problemów. Mam nadzieję, ze uda mi się pokazać je wszystkie.=

założenia

Warto pamiętać, że będziemy intensywnie odpytywać serwer. Zatem nie jest dobrym pomysłem wysyłanie html’a tam i z powrotem. Zapytania XHttpRequest powinny oczekiwać odpowiedzi w formacie JSON.
Kolejną kwestią jest to, że jeśli nie ma nic istotnego do wysłania z serwera, lepiej żeby zapytanie skończyło się timeoutem, niż otrzymało odpowiedź “nic nowego”. Nawet jeśli nie jest to super eleganckim rozwiązaniem (timeout jednak jest pewnego rodzaju awarią).

Powinniśmy też zdecydować jak wiele informacji wysyłać do serwera, aby otrzymać nowe wiadomości dla wątku. Minimum to id “korzenia” wątku oraz id ostatniej wyświetlonej wiadomości. Te informacje wystarczą, żeby zdobyć wszystkie wiadomości, które znajdują się w wątku, oraz ich id jest więcej niż najstarsza wiadomość w wątku. Jednak w tym wypadku musimy wykonać przynajmniej dwa zapytania: jedno, aby zdobyć wartości “lft” i “rght” korzenia oraz drugie, aby pobrać nowe wątki.

Drugim podejściem jest wysłanie listy identyfikatorów wszystkich postów w wątku i zwrócenie wszystkich wiadomości, których wartości parent_id zawierają się w tym zestawie.

Jest jeszcze trzeci pomysł, na który wpadłem już podczas redagowania tego tutoriala. Otóż można wysyłać wartości “lft” i “rght” korzenia zamiast jego id, wtedy oszczędzimy jedno z zapytań (w porównaniu do pierwszego przedstawionego podejścia). To rozwiązanie sprawia, że przy pierwotnym generowaniu find musi zwracać też te pola. Nie wiem, które z rozwiązań okazało by się szybsze – trzeba by to sprawdzić empirycznie.

Ja wybrałem podejście pierwsze dlatego, że jest rozwiązaniem czystszym. Nie mam wystarczająco dużo informacji, które z rozwiązań będzie szybsze.

Utwórz zatem akcje, która przyjmuje dwa parametry (id korzenia i ostatniej wiadomości w wątku) i wysyła w odpowiedzi nowe wiadomości (jeśli są) lub nie robi nic (nawet nie wysyła pustej odpowiedzi).

//controllers/posts_controller.php
	function get_new($rootId, $lastMessageId){
		$root = $this->Post->read(null, $rootId);

		$posts = array();

		while(empty($posts)){
			$posts = $this->Post->find(
				"all",
				array(
					"conditions"=>array(
						"and"=> array(
							"Post.lft > " => $root["Post"]["lft"],
							"Post.lft < " => $root["Post"]["rght"],
							"Post.id >" => $lastMessageId
						)
					)
				)
			);
			if(empty($posts)){
				sleep(2); // sleep for two seconds
			}
		}
		$this->set("posts", $posts);
		$this->render("get_new", false);
	}

i widok:

// views/posts/get_new.ctp
echo json_encode($posts);

Możesz wypróbować teraz tą akcję w przeglądarce. Jednak jeśli wybierzesz /posts/get_new/1/8, gdzie 8 to id ostatniej odpowiedzi – Twój serwer dostanie czkawki. Dla testów wybierz takie dane, żeby serwer zwrócił jakieś “nowe” wiadomości (na przykład /posts/get_new/1/7).

Problem z serwerem

Zapchanie serwera ma jakiś związek z sesjami. Apache czeka do końca wykonywanego skryptu zanim zapisze dane sesji, na końcu którego niejawnie zapisuje sesję. Z jakiegoś powodu Apache nie może zwolnić wątku dla danego zapytania jeśli sesja nie jest zamknięta (nawet jeśli wciśniesz “anuluj” w przeglądarce, co zazwyczaj powinno skutkować zakończeniem wykonania skryptu). Co należy zrobić do wywołać funkcję session_commit(); na samym początku akcji, które są pobierane techniką long polling. (jeśli w danej akcji musisz zachować jakieś dane w sesji, zrób to przed session_commit() i przed pętlą while).

//controllers/posts_controller.php
	function get_new($rootId, $lastMessageId){
		session_commit();
		$root = $this->Post->read(null, $rootId);
		//...

Mamy teraz gotową akcję, która zwraca łańcuch w formacie JSON z nowymi wiadomościami. Załadujmy je teraz do naszego wątku.

Na początku trzeba zadbać o to, żeby id korzenia i ostatniego postu były zapamiętane w obiekcie Thread. Id korzenia jest w polu parent_id pierwszego elementu (zmienna $thread w widoku PostsController::view()), id ostatniego postu znajdziemy podczas generowania drzewa dyskusji.
Dodaj te właściwości do klasy Thread:

//webroot/js/thread.js
(function(window, document, udefined){
	window.Thread = function(_posts) {
		this.posts = _posts;
		this.rootId = false; //<==
		this.lastId = false; //<==
		this.extendJQuery();
		return this;
	};

})(window, document);

Zachowaj id korzenia i ostatniej wiadomości w metodzie createThread():

//webroot/js/thread.js
Thread.prototype.createThread = function(){
	if(this.posts.length <1){
		return this;
	}
	this.rootId = this.lastId = posts[0].Post.parent_id; //<==
	var _this = this; //musimy zapamiętać this, gdyż w metodzie each this oznacza aktualny element w danym kroku iteracji
	$(this.posts).each(function(k, v){
		if($("#"+v.Post.parent_id).find("ul").length == 0){
			if($("#"+v.Post.parent_id).find("div.reply").length == 0){
				_this.createReplyDiv().appendTo("#"+v.Post.parent_id);
			}
	        $("
", {class: "posts children"}).appendTo("#"+v.Post.parent_id);
		}
	     $("
", {
	    	  id: v.Post.id,
	    	  innerHTML: "
"+v.Post.message+"

"
	    	  ,
	    	  class: "post child"
	     }).
	     append(_this.createReplyDiv()).
	     appendTo("#"+v.Post.parent_id+">ul");
	     if(v.Post.id>_this.lastId){ //<==
	    	 _this.lastId = v.Post.id;
	     }
	});
	return this;
};

Teraz chcielibyśmy, aby były pobierane dane z akcji get_new, jednak obiekt thread nie ma pojęcia, że tam się one znajdują. Umożliwmy przekazanie docelowego adresu (endpoint) url w konstruktorze.

//webroot/js/thread.js
(function(window, document, udefined){
	window.Thread = function(_posts, _updateEndpoint) {//<==
		this.posts = _posts;
		this.rootId = false;
		this.lastId = false;
		this.updateEndpoint = _updateEndpoint; //<==
		this.extendJQuery();
		return this;
	};

})(window, document);

i zaktualizuj inicjowanie obiektu klasy Thread:

//views/layouts/default.ctp
		$(document).ready(function(){
			if(!window.posts) return false;
			window.thread = new Thread(
				posts,
				"<?php echo $html->url(
							array(
							'controller'=>'posts',
							'action'=>'get_new')
				);?>"
			).createThread();
			console.log(thread);
		});

teraz stwórz metodę update(). Powinna pobierać JSON z nowymi postami i w wypadku timeoutu czy sukcesu wywołać siebie samą ponownie:

//webroot/js/thread.js
Thread.prototype.update = function(){
	if(!this.updateEndpoint || !this.rootId || !this.lastId){
		alert("Thread corrupted");
		return false;
	}
	_this = this;
	$.ajax({
		url: this.updateEndpoint +"/"+ this.rootId+ "/" + this.lastId,
		dataType: 'json',
		timeout: 5000,
		success: function(){
			_this.update();
		},
		error: function(){
			_this.update();
		}
	});
	return true;
}

bug #1

Przy okazji natknąłem się na błąd wprowadzony przez moją nieuwagę. Możesz go zauważyć, kiedy w bazie pojawi się element o id równym 10 i większym. Okazuje się, że obiekt Thread zachowuje największe id, ale porównuje je w kolejności słownikowej (sprawdź w konsoli firebug: "10">"9" zwraca false). Proszę, popraw instrukcję "if" na samym końcu w ten sposób:

//...
		if(parseInt(v.Post.id)>_this.lastId){
			_this.lastId = parseInt(v.Post.id);
		}
}

Wywołaj teraz nowo utworzoną metodę w Thread.createThread():

Thread.prototype.createThread = function(){
	var _this = this;
	if(this.posts.length <1){
		return this;
	}
	this.rootId = this.lastId = posts[0].Post.parent_id;
	$(this.posts).each(function(k, v){
		if($("#"+v.Post.parent_id).find("ul").length == 0){
			if($("#"+v.Post.parent_id).find("div.reply").length == 0){
				_this.createReplyDiv().appendTo("#"+v.Post.parent_id);
			}
        	$("
", {class: "posts children"}).appendTo("#"+v.Post.parent_id);
		}

		$("
", {
			id: v.Post.id,
			innerHTML: "
"+v.Post.message+"

",
			class: "post child"
		}).
		append(_this.createReplyDiv()).
		appendTo("#"+v.Post.parent_id+">ul");
		if(parseInt(v.Post.id)>_this.lastId){
		 _this.lastId = parseInt(v.Post.id);
		}
	});
	this.update(); //<==
	return this;
}

Możesz teraz sprawdzić w konsoli, czy raz za razem próbuje pobrać nowe dane z serwera. Dodaj post w wątku przy pomocy innej przeglądarki i sprawdź co dzieje się z zapytaniem...
Jak widzisz mamy pozytywną odpowiedź, ale od tego momentu każdy kolejny request dostaje tą samą odpowiedź a drzewo wątku nie jest aktualizowane. Poprawimy to teraz. Po pierwsze wyodrębnij jako metodę fragment kodu (z metody createThread), która tworzy kolejne elementy z wypowiedziami - możemy ją ponownie użyć...

Thread.createThread should look like that:

Thread.prototype.createThread = function(){
	if(this.posts.length <1){
		return this;
	}
	this.rootId = this.lastId = posts[0].Post.parent_id;
	var _this = this;
	$(this.posts).each(function(k, v){
		_this.addPost(v.Post.id, v.Post.parent_id, v.Post.message); //<==
	});
	this.update();
	return this;
};

oraz nasza nowa metoda Thread.addPost:

Thread.prototype.addPost = function(id, parentId, message){
	if($("#"+parentId).find("ul").length == 0){
		if($("#"+parentId).find("div.reply").length == 0){
			this.createReplyDiv().appendTo("#"+parentId);
		}
        $("
", {class: "posts children"}).appendTo("#"+parentId);
	}
     $("
", {
    	  id: id,
    	  innerHTML: "
"+message+"

"
    	  ,
    	  class: "post child"
     }).
     append(this.createReplyDiv()).
     appendTo("#"+parentId+">ul");
     if(id>this.lastId){
    	 this.lastId = id;
     }
}

bug #2

Trafiłem na jeszcze bardziej zakamuflowany błąd - skrypt powoduje wyciek pamięci na serwerze (wystarczy poczekać odpowiednio długo, gdy "lecą" kolejne requesty) - po timoucie xhr'a skrypt po stronie serwera najwyraźniej się nie kończy.
Dodałem prosty licznik do metody get_new:

//controllers/posts.php
	function get_new($rootId, $lastMessageId){
		//...
		$counter = 2; //<==
		while(empty($posts)){
			$posts = $this->Post->find(
				"all",
				array(/*...*/)
			);
			if($counter>5){ //<==
				break; //<==
			}else{ //<==
				$counter += 2; //<==
			} //<==
			if(empty($posts)){
				sleep(2); // sleep for two seconds
			}
		}
		$this->set("posts", $posts);
		$this->render("get_new", '');
	}

Dlaczego inkrementuję o 2? Dlatego, że w pętli jest 2 sekundowy sleep(), zatem sprawdzam, czy skrypt "przespał" przynajmniej 5 sekund (co ma związek z 5 sekundowym timeoutem w żądaniu ajax).

Aby zamknąć sprawę - wywołaj wyodrębnioną metodę w zdarzeniu success:

//webroot/js/thread.js
Thread.prototype.update = function(){
	if(!this.updateEndpoint || !this.rootId || !this.lastId){
		alert("Thread corrupted");
		return false;
	}
	_this = this;
	$.ajax({
		url: this.updateEndpoint +"/"+ this.rootId+ "/" + this.lastId,
		dataType: 'json',
		timeout: 5000,
		success: function(data){ //<==
			$(data).each(function(k,v){
				_this.addPost(v.Post.id, v.Post.parent_id, v.Post.message); //<==
			});
			_this.update();
		},
		error: function(){
			_this.update();
		}
	});
	return true;
}

To tyle. Oczywiście przy pomocy long polling (i niedługo web sockets) możesz zaimplementować więcej fajnych funkcjonalności. Możesz naprzykład wyświetlać informację, że ktoś zaczął odpowiadać na konkretną wypowiedź w wątku.

Jest jeszcze kilka usprawnień, które warto w takim systemie dodać, jak choćby podświetlenie nowo dodanych odpowiedzi, ale wykracza to już poza tematykę tego tutoriala.

Mam nadzieję, że ten tutorial się wam spodobał, nie wahajcie się mi napisać o tym co o nim myślicie.

Dlatego pod każdym elementem li.post utwórzmy div’a, którym będzie konterem dla formularza odpowiedzi. Znajdź w thread.js linie odpowiedzialne za tworzenie elementów li zawierających posty i dodaj html z div’em do parametru innerHTML:

//app/webroot/js/thread.js
$("
", {
	    	  id: v.Post.id,
	    	  innerHTML: "
"+v.Post.message+"

" +
	    	  			 "
" //<---
	    	  ,
	 class: "post child"
	 }).
	 appendto("#"+v.post.parent_id+">ul");

Przyda się teraz nieco css’ów. Kontener powinien zajmować nieco więcej miejsca (żeby łatwiej było w niego kliknąć) oraz po najechaniu na niego myszką powinien zmienić kolor, sugerując użytkownikowi, że może tam kliknąć. Podlinkuj nowy plik css do layoutu:

//app/views/layouts/default.ctp
echo $this->Html->css('cake.generic');
echo $this->Html->css('thread'); //<-add this
echo $this->Javascript->link(array("thread"));

a następnie stwórz plik thread.css z taką zawartością:

/* app/webroot/css/thread.css */
div.reply {
	height: 5px;
	cursor: text;
}
div.reply:hover{
	background-color: #8EAFEB;
}

Tak to powinno wyglądać teraz:

Bardziej spostrzegawczy zauważyli od razu, że miejsce pod pierwszą wypowiedzią w wątku nie zachowuje się tak jak powinno, poprawmy nieco thread.js:

if($("#"+v.Post.parent_id).find("ul").length == 0){
	if($("#"+v.Post.parent_id).find("div.reply").length == 0){
		$("
", {class: "reply"}).appendTo("#"+v.Post.parent_id);
	}
	$("
", {class: "posts children"}).appendTo("#"+v.Post.parent_id);
}

Teraz pojawiło nam się odrobinę redundancji w kodzie – dwa miejsca, gdzie jest tworzony element div.reply. Naprawmy to. Usuniemy dodawanie stringa

<div class='reply'/>

i zastąpimy go tworzeniem elementu DOM przy pomocy jQuery, a następnie wyekstrahujemy motodę, która to robi. Ostatecznie kod powinien wyglądać tak:

(function(window, document, udefined){
	window.Thread = function(_posts) {
		this.posts = _posts;
		return this;
	};
})(window, document);

Thread.prototype.createReplyDiv = function(){
	return $("
", {class: "reply"});
}

Thread.prototype.createThread = function(){
	if(this.posts.length <1){
		return this;
	}
	var _this = this; //* patrz poniżej
	$(this.posts).each(function(k, v){
		if($("#"+v.Post.parent_id).find("ul").length == 0){
			if($("#"+v.Post.parent_id).find("div.reply").length == 0){
				_this.createReplyDiv().appendTo("#"+v.Post.parent_id);
			}
	        $("
", {class: "posts children"}).appendTo("#"+v.Post.parent_id);
		}
	     $("
", {
	    	  id: v.Post.id,
	    	  innerHTML: "
"+v.Post.message+"

"
	    	  ,
	    	  class: "post child"
	     }).
	     append(_this.createReplyDiv()).
	     appendTo("#"+v.Post.parent_id+">ul");
	});
	return this;
}

(*)Jeśli zastanawiasz się po co zapamiętujemy `this` w zmiennej `_this` śpieszę z wyjaśnieniem. W kodzie chcemy wywołać, wyodrębnioną dopiero co, metodę createReplyDiv. Niestety w anonimowej funkcji, która jest przekazana do metody each(), `this` wskazuje już na konkretny element z kolekcji po której ów each() iteruje. Musimy zapamiętać “starą” referencję `this` (czyli obiekt klasy Thread).

Zachęcony dobrym odbiorem mojego pierwszego turoriala zacząłem pracę nad kolejnym. Niestety nie udało mi się skończyć przed urlopem i straciłem nieco wątek. Dlatego zdecydowałem się dostarczyć go Wam w częściach, dzięki temu wykonując kolejne (gotowe już) części będę mógł się odnaleźć i jednocześnie mam nadzieję na wyłapanie drobnych błędów. Mam nadzieję, że Wam się spodoba.

Czym jest long pooling

Long polling jest metodą, która przy pomocy bezstanowego protokołu HTTP (opartego na zasadzie “żądań wysyłanych do serwera” ), symuluje sytuację, w której serwer wysyła zaktualizowaną informację klientowi w momencie jej aktualizacji (“server push“. W prawdzie dużymi krokami zbliżają się do nas web sockets zaimplementowane w firefozie, ale wydaje mi się, że fajnie jest zapoznać się z tą techniką (i przy okazji “podostrzyć piłę”).

Zajmiemy się dość prostym pomysłem. Kombinacja czatu i forum, w którym możemy umieszczać swoje posty i w czasie rzeczywistym, bez przeładowania strony, widzieć pojawiające się posty innych uczestników dyskusji (możesz myśleć o tym jak o okrojonym Google Wave).

Po stronie serwera wykorzystamy cakePHP, a po stronie klienta wesprze nas cudowne jQuery. Zakładam, że jesteś nieco zaznajomiony z tymi narzędziami – nie będę tutaj zamieszczał instrukcji jak skonfigurować połączenie z bazą w cakePHP itp.

Funkcjonalności w tworzonym systemie:

• dodawanie nowego wątku
• odpowiadanie w wątku bez przeładowania strony
• otrzymywanie odpowiedzi innych użytkowników bez przeładowania strony

dodatkowo pamiętamy, że jako pasjonaci zaczynamy z niewielką ilością funduszy, więc chcemy aby nasza aplikacja była tak lekka dla serwera jak to możliwe (czyli przeniesiemy tyle pracy na stronę klienta ile się da).

Przygotowanie projektu

Pobierz najnowszą wersję cake’a:

$ git clone http://github.com/cakephp/cakephp.git longPolling

I stwórz bazę danych, która przechowa nasze dyskusje

CREATE TABLE `posts` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `parent_id` int(11) DEFAULT NULL,
  `user_id` int(11) DEFAULT NULL,
  `lft` int(11) DEFAULT NULL,
  `rght` int(11) DEFAULT NULL,
  `message` text COLLATE utf8_unicode_ci NOT NULL,
  `modified` datetime NOT NULL,
  UNIQUE KEY `id` (`id`),
  KEY `parent_id` (`parent_id`),
  KEY `lft` (`lft`),
  KEY `rght` (`rght`),
  KEY `user_id` (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

Jak łatwo zauważyć będziemy wykorzystywali technikę zwaną “Nested set model“, którą implementuje Treebehavior. Dla maksymalnej prostoty wątki nie mają tytułów itd, zawiązanie wątku odbywa się po prostu przed dodanie postu, który nie jest odpowiedzią na żaden inny post.

Teraz przy pomocy narzędzia bake stwórz model, kontroler i widoki dla CRUD – będzie to podstawą dla dalszej pracy. Nie zawracaj sobie głowy walidacją czy akcjami admina – nie jest to ważne w tym ćwiczeniu. Dodaj behavior Tree do modelu Post.

Porządki

Już mamy trochę bałaganu w naszym kodzie. Widoki `add` i `edit` nawzajem się duplikują, więc usuniemy widok `add.ctp` oraz zmusimy PostsController::add() do korzystania z widoku `edit`:

//posts_controller.php
	function add() {
		if (!empty($this->data)) {
			$this->Post->create();
			if ($this->Post->save($this->data)) {
				$this->Session->setFlash(__('The post has been saved', true));
				$this->redirect(array('action' => 'index'));
			} else {
				$this->Session->setFlash(__('The post could not be saved. Please, try again.', true));
			}
		}
		$this->render("edit");
	}

oraz, żeby zachować nieco estetyki, otoczmy kod wyświetlający link “delete” instrukcją if, żeby nie pokazywał się w przypadku dodawania nowego postu:

		<?php if(!empty($this->data["Post"]["id"])): ?>
			<li>Html->link(__('Delete', true), array('action' => 'delete', $this->Form->value('Post.id')), null, sprintf(__('Are you sure you want to delete # %s?', true), $this->Form->value('Post.id'))); ?>

		<?php endif; ?>

i jeszcze kosmetyka – usuńmy pola user_id, lft, rght, modified z formularza (są one wypełniane automatycznie).

I jeszcze jedno: na początku będziemy wybierać w formularzu posty z listy select, żeby wskazać wiadomość na którą odpowiadamy, dodaj w kontrolerze poniższą metodę i wywołaj ją w akcjach `add` oraz `edit`:

//posts_controller.php
function _getParentPosts(){
	$this->set('parents', $this->Post->find("list"));
}

Teraz możesz ręcznie dodać dyskusję… chyba, że jesteś bardzo wygodny – możesz odpalić poniższe instrukcje sql:

INSERT INTO `posts` VALUES (1,NULL,NULL,1,8,'first message in the topic.','0000-00-00 00:00:00'),
(2,1,NULL,2,5,'my very first reply to the very first message!','0000-00-00 00:00:00'),
(3,1,NULL,6,7,'I just have some opinion about first message, and will share it with you... soon.','0000-00-00 00:00:00'),
(4,2,NULL,3,4,'I think you shouldn\'t make off-topics here','0000-00-00 00:00:00');

Teraz jesteśmy gotowi do zabawy.

Jego działanie można opisać z grubsza tak:
Na przykład jeśli chcę, żeby moja lista kosztów (Cost) mogła być wyszukiwana po nazwach – dodaję formularz z Cost.name i w akcji kontrolera wywołuję jedynie

$conditions = $this->Search->getConditions($this->params);
$this->paginate("conditions"=>$conditions);
$this->set('costs', $this->paginate('Cost'));

Największy bajer polegał na tym, że jeżeli moje koszty były powiązane z samochodami (Car) to chcą wyszukiwać po nazwie samochodu wystarczyło, że dodałem do formularza pole Car.name. Mój komponent potrafił zorientować się, że to jest powiązany model, wyszukać elementy spełniające warunek, a następnie zwrócić w conditions coś takiego:

Array
(
    [and] => Array
        (
            [Cost.id] => Array
                (
                    [0] => 1
                    [1] => 2
                    [2] => 5
                    [3] => 9
                    [4] => 10
                    [5] => 13
                    [6] => 17
                    [7] => 18
                )

        )

)

Gdzie cake ładnie sobie to przerabiał na zapytanie (w przybliżeniu)

Select * from costs as Cost where Cost.id IN (1, 2, 5, 9, 10, 13, 17, 18)

Byłem bardzo zadowolony z komponentu. Służył nam dzielnie przez przynajmniej dwie ostatnie iteracje. Każdą wyszukiwarkę/filtr dodawaliśmy w 5 minut na żądanie klienta (wewnętrznego ;)).

Mało tego, dość dużym wyzwaniem było sporządzenie testów dla tego komponentu (kilka MockObjects nawet się tam pojawiło) – pewnie dlatego tak sumiennie je wykonałem – 91% (z hakiem!) pokrycia kodu przez testy.

Przyszedł jednak dzień, gdy podczas prezentacji iteracji szef (klient wewnętrzny) powiedział (cytat nie dosłowny):
“Chcę jeszcze filtrować koszty wg numerów faktur (Invoice.number) z którymi te koszty są powiązane”

Problem w tym, że koszty są powiązane z fakturami poprzez elementy faktur (InvoiceElement), a konkretniej

Cost habtm InvoiceElement belongsTo Invoice

Zatem przyszło mi poprawić komponent, przy czym szczęśliwie zdążyłem zapomnieć wszystkich niuansów, foreachów i innych takich, które harcowały wewnątrz search_component.php. Myślę sobie – ok, tak jak poprzednio – dużo testów. Ale nie wiedziałem jak się do nich zabrać. Wiedziałem jedynie, że nazwa pola dla nowego przypadku powinna zawierać ścieżkę powiązań (np. InvoiceElement.Invoice.number).

Mając jednak w głowie dość przydatną radę na temat unit testów, która brzmi:

Najlepsze są testy napisane przed kodem. Jednocześnie napisanie najpierw kodu, a potem testów jest o niebo lepsze od braku jakichkolwiek testów.

Dlatego postanowiłem od razu przejść do próby implementacji nowych elementów dbając jedynie o kondycję dotychczasowych testów.

To co się wydarzyło można nazwać chyba “uprzężą testową”. Mogłem odważnie śmigać po dotychczasowo napisanym kodzie, bo w tym samym czasie zielone pole w rezultatach testów mówiło mi “śmiało dalej! niczego do tej pory nie popsułeś!”. Wspaniałe uczucie.

Wprawdzie po skończeniu pokrycie kodu spadło do 80% (nota bene i tak świetny wynik, 70% uznaje się za przyzwoite pokrycie), ale zaraz po napisaniu tego postu zabieram się za sporządzenie przynajmniej kilku testów. Trzeba zdążyć przed urlopem ;)

(*) Ta miłość jest nieodwzajemniona, gdy temat rozmowy schodzi na Fixture’y. Pewnie dlatego ten komponent testuje się tak ładnie i szybko – nie korzysta z bazy, tylko z Mock’owanych obiektów.

controllers/module/module_things_controller.php
class ModuleThingsController extends AppController {
}
models/module/module_thing.php
class ModuleThing extends AppModel{
}

(Moduły uznałbym za coś pośredniego między kupą kontrolerów, a pluginami. Nie wymagają mocniejszego rozdzielenia zależności między kontrolerami w przeciwieństwie do pluginów, dla których jest to dobrą praktyką. Z drugiej strony wprowadzają nieco porządku w plikach źródłowych)

Od razu rzuca się w oczy fakt powtarzania nazwy modułu w katalogu i nazwie pliku (oraz w definicji klasy). Wynika to po pierwsze z konieczności jednoznacznego nazywania klas w ramach jednego projektu. Po drugie, jeśli istnieją dwa pliki od tej samej nazwie i definicji klasy (ale jeden w podkatalogu) to domyślnie będzie używany ten z katalogu głównego.

Tak czy siak warto wprowadzić nieco porządku do swoich projektów. Można to zrobić nawet z marszu – po prostu przenieść pliki do podkatalogów (jednak należy pamiętać o tym co może się wydarzać, gdy przez przypadek zdefiniujemy dwa kontrolery o takiej samej nazwie w różnych podkatalogach.)

Niestety w widokach nie udało mi się jeszcze w ten sposób wykorzystać podkatalogów. Dlatego w naszym przykładzie widoki należy umieścić w

/views/module_things/

Jednak już w ramach tego katalogu można zadbać o większy porządek:
/views/module_things/forms/add_edit_form.ctp
i explicite wywoływać dany widok:

class ModuleThingsController extends AppController {
 //...
 function add(){
   //...
   $this->render("forms/add_edit_form");
 }
}

mam pewna zagwozdke – stworzylem mala platforme blogowa w Cake – cos a`la WordPress.com. przymierzam sie do implementacji protokolu Pingback. jest kwestia wysylania pingow – chyba raczej z punktu widzenia wydajnosci nie mozna tego robic przy zapisywaniu posta tylko uzyc taska shellowego, ktory co pewien czas bedzie to robil? jak sadzisz ?

Myślę, że tak jak sugerujesz, wysłanie pinga nie jest dobrym pomysłem. Sam pisząc posty czasem zapisuję je kilka razy zanim staną się one publicznie dostępne. Gdyby już przy pierwszym zapisie wysłać ping to byłby on wadliwy – prowadziłby do nieistniejącej strony.

Z drugiej strony wspomniany przez Ciebie task shellowy (rozumiem, że chodzi na przykład o crona) jest zadaniem dość kłopotliwym. Moim zdaniem komplikuje on architekturę aplikacji. Oczywiście zależy jak dużo do tego taska chcesz upchnąć? Jeśli parsowanie wpisu w poszukiwaniu linków etc. to moim zdaniem jest to zbyt wiele.

Moim pierwszym pomysłem było wysłanie pinga przy publikacji wpisu. Jednak gdyby w tekście znalazło się 20 różnych linków i wysyłać pingi przy publikacji – mogłoby to zbyt długo trwać i być niewygodne dla autora bloga (wyobrażam sobie sytuację, że przy 18 pingu następuje timeout wykonania skryptu i nie wiadomo czy post się opublikował i czy pingi się udały?).

Dlatego wybrałbym rozwiązanie kombinowane. Tzn. podczas publikowania wpisu (i update’u już opublikowanego) parsowałbym sobie tekst i znalezione linki umieszczałbym w tabeli pingbacks, która mogłaby wyglądać mniej więcej tak:

|----------------------------------------
| pingbacks
|----------------------------------------
| id: INT
| post_id: INT (albo permalink jeśli wolisz)
| uri : varchar (pingowany link)
| sent: tinyint(1) DEFAULT 0
|----------------------------------------

oczywiście przed zapisem sprawdzamy, czy już go nie ma w bazie ;). Przy takim rozwiązaniu świetnie powinien sprawdzić się Post::afterSave(). Wystarczy sprawdzić, czy zapisany model został z opublikowany i odpalić metodę Post::findAndSavePingbacks($postId).

Mam problem z tym, gdzie umieścić logikę wysyłania pingów. Myślę, że to też należałoby do warstwy Modelu (Pingback::send($limit)). Metoda taka pobrałaby kilka elementów z tabeli `pingbacks`, które nie zostały jeszcze wysłane i po udanym wysłaniu aktualizował pole `sent` (ustawiając 1).

Na koniec w kontrolerze zdefiniowałbym akcję, która miałaby za zadanie jedynie odpalić metodę Pingbacks::send()

class PingbacksController extends AppController{
  function send($limit=10){
     $this->autoRender = false;
     $this->Pingback->send($limit);
  }
}

I teraz jeśli mamy dostęp do crona to możemy zdefiniować na przykład akcję wget http://example.com/pingbacks/send
Jeśli nie mamy dostępu do takich luksusów – możemy wzbudzać tą akcję np. w AppController::afterFilter().

Co myślicie o tym rozwiązaniu?