<?php
$i = 0;
foreach ($tracks as $track):
	$class = null;
	if ($i++ % 2 == 0) {
		$class = ' class="altrow"';
	}
?>
	<tr<?php echo $class;?>>
		<td>
			<?php echo $track['Track']['id']; ?>
		</td>
		<td>
			<?php echo $track['Track']['name']; ?>
		</td>
		<td>
			<?php echo $track['Car']['name']; ?>
		</td>
		<td>
			<?php echo $track['Track']['begin']; ?>
		</td>
		<td>
			<?php echo $track['Track']['end']; ?>
		</td>
		<td>
			<?php echo $track['Track']['length']; ?>
		</td>
		<td class="actions">
			<?php echo $html->link(
			   __('Edycja', true),
			   array(
			      'action' => 'edit',
			      $track['Track']['id'] ,
			      $track['Car']['id']
			   )
			  );
			?>

		</td>
	</tr>
<?php endforeach; ?>
</table>

Chce Ci się pisać ten kod kilkadziesiąt razy w jednym projekcie? Mnie też nie. Dlatego napisałem prosty element, który to trochę automatyzuje (nazwałem go “list”):

// app/views/elements/list.ctp
<?php
   $i = 0;
   foreach($elements as $key => $element):
   $class = null;
   if ($i++ % 2 == 0) {
      $class = ' class="altrow"';
   }
?>
   <tr <?php echo $class?>>
      <?php foreach($fields as $path): ?>
         <td>
            <?php echo Set::classicExtract($element, $path) ?>
         </td>
      <?php endforeach; ?>
         <?php if(isset($links)): ?>
            <td>
               <?php foreach($links as $name => $url): ?>
                  <?php
                     if(!is_array($url["params"])) {
                        $url["params"] = array($url["params"]);
                     }
                     foreach($url["params"] as $key => $path){
                        $url[$key] = Set::classicExtract(
                           $element,
                           $path
                        );
                     }
                     unset($url["params"]);
                  ?>
                  <?php echo $html->link($name, $url)?>
               <?php endforeach; ?>
            </td>
         <?php endif; ?>
   </tr>
<?php endforeach; ?>

Jego użycie jest dość proste. Dla przykładu wygenerujemy ten sam “output” dla pierwszego listingu z tego postu:

echo $this->renderElement(
         "list",
         array(
            "elements" => $tracks,
            "fields" => array(
               "Track.name", "Car.name", "Track.begin",
               "Track.end", "Track.length"
            ),
            "links"=> array(
               "edycja" => array(
                  "controller"=> "tracks", "action"=> "edit",
                  "params" => array(
                     "Track.id", "Car.id"
                  )
               )
            )
         )
      )

Opiszę poszczególne parametry przekazywane do tego elementu:

• “elements” – kolekcja (w tym wypadku tablica) elementów zwrócona na przykład przez $this->Track->find(“all”)
• “fields” – pola, które mają się pojawić w komórkach tabeli
• “links” – tu definiujemy jakie linki mają się pojawić w ostatniej kolumnie (zazwyczaj tam znajdują się “opcje”). Indeksy kolejnych elementów to nazwy linków (tutaj “edycja”).
  • “controller” i “action” są identycznie używane jak w metodzie HtmlHelper::link()
  • “params” jest dość ciekawy. Jeśli chcemy w wygenerowanym linku mieć jeden parametr (najczęściej id), robimy to tak:

                "edycja" => array(
                   "controller"=> "cars", "action"=> "edit", "params"=>"Car.id"
                ),
    

    gdy parametrów ma być więcej – ścieżki do nich przekazujemy w tablicy (tak jak w przykładzie):

                    "edycja" => array(
                       "controller"=> "tracks", "action"=> "edit",
                       "params" => array(
                          "Track.id", "Car.id"
                       )
                    )
    

    Można także używać parametrów typu “named”, wystarczy podać dodatkowo indeksy:

                    "edycja" => array(
                       "controller"=> "tracks", "action"=> "edit",
                       "params" => array(
                         "parametr_1"=> "Track.id", "parametr_2"=> "Car.id"
                       )
                    )
    

Zachęcam do korzystania z tego elementu i zgłaszania wszelkich niedociągnięć :)

Jednak okazuje się, że cake w nowym wydaniu wychodzi nam na przeciw razem z klasą Schema, oraz z narzędziem konsolowym ./cake schema … po krótce opowiem o co chodzi.

Zabawę z tym narzędziem najlepiej zacząć mając już jakiś zalążek aplikacji (tabele + modele). Jeśli sprawiamy ten podstawowy warunek możemy wpisać w konsoli ./cake schema generate … ot tak, dla jaj.

Następnie możemy się w katalogu app/config/sql/ namierzyć plik schema.php. To właśnie artefakt wygenerowany przez nas przed sekundą. Można w celach samorozwojowych zajrzeć do środka…

Jednak ciekawe rzeczy dzieją się, kiedy ponownie wywołamy to samo polecenie: otóż cake rezolutnie zauważy, że plik schema.php już istnieje i zapyta nas co dalej. Polecam wybór opcji [S]napshot i ponowny rzut oka do wspomnianego wyżej katalogu. Co widzimy? Dokładnie! Nowy plik o nazwie schema_2.php :D Zachęcam do zapoznania się z helpem (./cake schema help).

Wystarczy, że teraz przekonam zespół, aby w sytuacji, gdy nastąpiły zmiany w bazie, przed commitem wywołali to polecenie. Jest jeden problem, którego ewentualnie można się spodziewać – sporadycznych konfliktów. To znaczy sytuacji, w której dwóch programistów:

1. ściąga repozytorium, 
2. dokonuje (nawet różnych) zmian w bazie, 
3. zatwierdza dane: 
1. schema generate, 
2. svn add schema_X.php, 
3. svn commit

Problem w tym, że w takiej sytuacji w punkcie 3.3 jeden z nich dostanie informację

Nie mogę dodać schema_X.php do repozytorium, gdyż takowy  już w repozytorium istnieje.
Z poważaniem Twój
SVN

Nie jest to jakaś wielka tragedia, jak przy każdym konflikcie trzeba będzie go rozwiązać (w tym wypadku przy spotkaniu tych dwóch programistów). Jednak myślę, że takie sytuacje można by zlikwidować wywołując tą sekwencję w jednym ciągu (nie np. commit po dwóch godzinach od schema generate), może nawet napisać prosty skrypt, który załatwi to za nas (taki svncommitwithcakeschemagenerate.sh ;))

Np. metoda podana pod http://bakery.cakephp.org/articles/view/testing-models-with-cakephp-1-2-test-suite dla testu modelu się nie sprawdza. Okazuje się, że tam jest podany stary model tworzenia testów. Poprawna klasa powinna wyglądać mniej więcej tak:


App::import('model', 'Article');
class ArticleTestCase extends CakeTestCase {
var $fixtures = array( 'app.article' );

function testPublished() {
$result = $this->Article->published(array('id', 'title'));
$expected = array(
array('Article' => array( 'id' => 1, 'title' => 'First Article' )),
array('Article' => array( 'id' => 2, 'title' => 'Second Article' )),
array('Article' => array( 'id' => 3, 'title' => 'Third Article' ))
);
$this->assertEqual($result, $expected);
}
}

zamiast podanej:

loadModel('Article');
class ArticleTest extends Article {
var $name = 'ArticleTest';
var $useDbConfig = 'test_suite';
}
class ArticleTestCase extends CakeTestCase {
var $fixtures = array( 'article_test' );
function testPublished() {
$this->ArticleTest =& new ArticleTest();
$result = $this->ArticleTest->published(array('id', 'title'));
$expected = array(
array('ArticleTest' => array( 'id' => 1, 'title' => 'First Article' )),
array('ArticleTest' => array( 'id' => 2, 'title' => 'Second Article' )),
array('ArticleTest' => array( 'id' => 3, 'title' => 'Third Article' ))
);
$this->assertEqual($result, $expected);
}
}


Drugi przypadek generuje następujące problemy:

1. Gdy testy masz ustawione tak, żeby korzystały z tej samej bazy, gdzie masz “normalne” tabele, to testy na zmianę będą wykonywać się poprawnie i zgłaszać błąd z nieistniejącą tabelą (`articles_test`)
2. Gdy masz osobną baze do testów – będą się sypać relacje. Pewnie zdefiniowanie wszystkich fixtures powiązanych z testowanym modelem rozwiązało by problem, ale nie sprawdzałem.

Kolejnym przypadkiem jest zmuszenie CakeTestSuite do wywalenia informacji o procentowym pokryciu kodu testami. Pominę problemy przy instalacji xdebug, założę, że już to masz za sobą.

Prawdopodobnie będziesz dostawał Segmentation Fault po kliknięciu “Analyze Code Coverage”. Jeśli tak, odnajdź poniższą linię w pliku cake/test/lib/code_coverage_manager.php:

xdebug_start_code_coverage(XDEBUG_CC_UNUSED | XDEBUG_CC_DEAD_CODE);

Niestety Xdebug sypie się przy takim wykonaniu xdebug_start_code_coverage. Możesz zmienić tą linię na

xdebug_start_code_coverage(XDEBUG_CC_UNUSED)

lub

xdebug_start_code_coverage(XDEBUG_CC_DEAD_CODE)

O rożnicy możesz poczytać w dokumentacji Xdebug.

Ostatnia sprawa to pokrycie kodu, gdy wykonujesz test całej grupy. Jeśli chcesz dostawać informacje o pokryciu dla poszczególnych testów, nie używaj TestManager::loadTestCasesFromFile, ale raczej ładuj każdy plik osobno za pomocą TestManager::addTestFile.

To na razie tyle. Miłego testowania ;)

Jako, że nowe projekty także służą do eksperymentowania z nowymi rozwiązaniami, dlatego próbujemyz nowymi rozwiązaniami:

1. Po pierwsze komponent: ma dostawać tablicę po uploadzie (chodzi o pola “file”), zwracać nazwę zapisanego pliku (dla standardowego podejścia) lub zawartość gotową do wrzucenia do BLOBa
2. Po drugie Helper, który będzie się zajmował wyświetlaniem takich zdjęć (a w przyszłości także zajmie się cache’owaniem ze wspomnianą w powyższym artykule metodą z nagłówkami expire)

W takim rozwiązaniu niestety pojawia się problem (strzałki oznaczają przepływ danych, uwaga: diagram nie przedstawia dosłownie przebiegu jednego zapytania, ale dwóch zapisu (do kontrolera) i wyświetlenia obrazka (od kontrolera)) :

Chodzi o fragment zaznaczony na czerwono. To jest nadmiarowe zachowanie. Lepiej byłoby, gdyby komponent (poprzez kontroler) przekazał nazwę pliku, Helper sprawdził, czy plik istnieje, a w razie gdyby nie istniał – musiałby ‘poprosić’ komponent o aktualizację pliku. A to jest w konflikcie z tym co napisałem przy okazji Dobrych praktyk #2 – Helper nie może używać kontrolera, ani komponentu.

I tu się wydarzyła rzecz ciekawa, w tym poście chciałem napisac o problemie, na który nie widzę dobrego sposobu. Chciałem przedstawić ideę pierwszego podejścia.
Dla bardziej przejrzystego przekazania idei postanowiłem zbudowac diagram i uświadomiłem sobie jak bardzo wizualizacja pomaga w zrozumieniu problemu.
A od zrozumienia problemu do jego rozwiązania jest raczej niedaleko.

No i w tym momencie wpadłem na pomysł bez komponentu i bez Helpera, ale za to sam Behavior. Myślę sobie, że Behaviors są rozszerzeniem Modeli, które odpowiadają za warstwę przechowywania danych.
Pomysł jest taki, że -pomijając kwestię uploadu i sapisu – behavior w afterRead() sprawdził, czy plik fizycznie jest aktualny, jeśli jest – zwróci jego nazwę. Jeśli nie jest – utworzy go na podstawie danych w bazie (koniecznie z inną nazwą) i zwróci jego nazwę (relatywną do img/) ścieżką.

Sprawdzę to empirycznie i napiszę Wam jak poszło.

FirePHP to rozszerzenie, do Firebug – rozszerzenia do Firefoxa :)
Pozwoli Ci wyświetlać debug z kodu PHP w konsoli firebuga właśnie. Jak go zintegrować z Cake (1.2) jest opisane na http://bakery.cakephp.org/articles/view/baking-cakes-with-firephp.

Poniżej efekt:

Przy wykorzystaniu tych narzędzi twój debug jest widoczny tylko dla Ciebie (no i jeszcze tych co mają zainstalowany ten dodatek… na 99% Twój klient nie ma).

Życzę Wam i sobie więcej takich narzędzi, które pojawiają się zanim uświadomimy sobie ich potrzebę.

ps. Radzę raczej użyć firebuga w wersji beta 7, gdyż w nowszych pojawia się błąd, w którym aby zobaczyć informacje w konsoli – trzeba najpierw przełączyć się na inną zakładkę, a później do niej wrócić. Zatem jeśli nie potrzebujesz poprawek z wersji beta 15 (taka była najnowsza w momencie pisania tego tekstu) – wybierz 7.

Z biblioteki CakePhp1.2 (cake/libs/) do katalogu vendors w Twojej aplikacji (1.1.x) skopiuj pliki
- socket.php
- http_socket.php

W pliku socket.php gdzieś na początku, przed definicją klasy jest linia
uses(‘validation’);
zakomentuj ją (lub usuń) .
Z kolei w pliku http_socket.php linię
uses( ‘socket’, ‘set’);
Zamień na
vendor(‘socket’);
uses(‘set’);

Sposób działający pomiedzy wersją 1.2.0.6311 beta a 1.1.16.5421.
Powodzenia

Uwaga: działa jedynie przy zapytaniach GET. Dla POST brakuje potrzebnych klas i trzeba by nieco pogrzebać w kodzie HttpSocket, żeby można było wywoływać zapytania POST.