Mikro-frameworki mają to do siebie, że są… proste 🙂
Slim Framework pozwala zbudować stronę używając w zasadzie jednego pliku index.php i kilku routerów.
W przypadku bardziej skomplikowanych serwisów wygodniej jest podzielić podstrony na kontrolery.
Jeśli kojarzysz takie wzorce architektoniczne jak MVC i MVP, pojęcie kontrolera aplikacji nie powinno być Ci obce.
Można zadać sobie pytanie, po co rozbudowywać mikro-frameworki, jeśli istnieją ich pełne funkcjonalnie odpowiedniki?
Cóż… W przypadku Slim Framework nie ma takiego odpowiednika, tak jak to jest w przypadku Silex i Symphony.
Instalacja
Ściągamy autorską bibliotekę SlimController:
https://github.com/fu-hsi/slim-controller
Na obecną chwilę nie istnieje inna metoda instalacji niż ściągnięcie archiwum ZIP (w planie Composer).
Rozpakowaną bibliotekę umieszczamy w folderze vendor aplikacji Slim.
Przykładowy kontroler HomeController
Standardowo klasy kontrolerów umieszczamy w głównym folderze controllers (należy go utworzyć).
<?php
/**
* Filename: HomeController.php
*/
use SlimController\epController;
class HomeController extends epController
{
/**
* Called after constructor.
*/
public function initialize()
{
echo sprintf('%s()<br>', __METHOD__);
}
/**
* Called for URI:
* /home
* /home/index
* /home/index/5
*/
public function indexAction($id = null)
{
echo sprintf('%s(%s)<br>', __METHOD__, $id);
}
/**
* Called for URI:
* /home/delete
* /home/delete/5
*/
public function deleteAction($id = null)
{
echo sprintf('%s(%s)<br>', __METHOD__, $id);
}
/**
* Called if no action found.
*/
public function _default()
{
echo sprintf('%s()<br>', __METHOD__);
}
}
?>
Każdy kontroler posiada referencję $app do aplikacji Slim.
<?php
use SlimController\epController;
class HomeController extends epController
{
public function indexAction()
{
$this->app->flashNow('info', 'I am an indexAction() method.');
}
}
?>
Przykładowa aplikacja Slim
<?php
use SlimController\epController;
use SlimController\epDispatcher;
use SlimController\Exception;
use Slim\Route;
$loader = require 'vendor/autoload.php';
$loader->add('SlimController', __DIR__ . DIRECTORY_SEPARATOR . 'vendor');
$epConfig = array(
'ep.controller.path' => __DIR__ . DIRECTORY_SEPARATOR . 'controllers',
'ep.controller.default' => 'Home',
'ep.action.default' => 'index'
);
$app = new \Slim\Slim($epConfig);
$app->map('/(:controller(/:action(/:id)))', function () use($app)
{
$dispatcher = new epDispatcher($app);
$currentRoute = $app->router()->getCurrentRoute();
try {
$dispatcher->dispatch($currentRoute);
echo "Uri: " . $app->router()
->urlFor('epRoute', $currentRoute->getParams()) . '<br>';
} catch (epFileNotFoundException $e) {
echo "Exception: " . $e->getMessage();
} catch (epClassNotFoundException $e) {
echo "Exception: " . $e->getMessage();
} catch (\Exception $e) {
echo "Exception: " . $e->getMessage();
}
})
->via('GET', 'POST')
->conditions(array('id' => '\d+'))
->name('epRoute');
$app->run();
?>
Wynik działania
Uruchomienie strony:
/home/index
powinno wyświetlić poniższy wynik:
HomeController::initialize() HomeController::indexAction() Uri: /home/index
Mało się pisze w Polsce o Slim, a szkoda. Fajnie, że powstał ten wpis.
Trochę mało napisałeś o wykorzystaniu tego rozszerzenia. Puki co, jeszcze go nie analizowałem.
Czy jest w nim możliwość budowy modułowej aplikacji? Pisze akurat projekt na Slimie, gdzie kontrolery i moduły implementuje we własnym zakresie, ale może niepotrzebnie? 🙂
Czy niepotrzebnie to nie wiem, natywnie tego nie ma. Czy stworzysz sam, czy wykorzystasz gotowe rozwiązanie (np. moją bibliotekę), to już od Ciebie zależy.
Wcześniej pisałem własny framework, więc tą cześć wykorzystałem w Slim, wyodrębniłem i stworzyłem bibliotekę.
Jakbym miał pisać większą aplikację, to nie wiem czy nie zrobiłbym jej np. w Symfony, czy Phalconie, który zresztą ostatnio dość intensywnie męczę.
Z tym, że ten ostatni będę stawiał na serwerze VPS, więc mam pełną kontrolę nad tym, jakie rozszerzenia do PHP sobie dodam.
Slim jest szybki, jeśli chodzi o mikroframeworki, ale Phalcon jest super szybki, jeśli chodzi o w pełni funkcjonalne frameworki (już z obsługą modułów i kontrolerów).
Ten wykres jest akurat ze strony YAF, więc siłą rzeczy dali siebie na 1. miejscu 🙂
Próbowałem się go nauczyć przed Phalconem, ale skromna dokumentacja, dużo chińskich tekstów (w każdym bądź razie jakimś azjatyckim), słaby ekosystem, narzędzia wspomagające budowę aplikacji i mała społeczność, więc sobie go darowałem.
Wszystko kwestia projektu, do czego to ma być.
Też mam swój framework, na którym stawiam wszystko co potrzebuje. Pisze się w nim szybko i dość wygodnie, ale ma już archaiczne elementy, choćby brak RESTFul. Przepisanie od nowa, to kupa roboty, dlatego rozglądałem się za czymś gotowym, co mnie nie będzie ograniczać. Wybór padł na Slim, oraz Laravel, ze względu na to, że wiele elementów ma gotowych. Główny warunek, taki, że ma działać na większości serwerów. Dlatego Phalcon odpadł w przedbiegach. Puki co projekt powstaje w zmodyfikowanej przeze mnie wersji Slim i jest ok. Musiałem dodać obsługę kontrolerów, ale w Slimie, dodanie takiej funkcjonalności, jest banalne 🙂
Dodasz kontrolery do Slim, to zaraz będziesz chciał dodać modele, a na końcu będzie tyle zmian, że stworzysz kombajn… 🙂
A gotowe rozwiązania są na wyciągniecie ręki…
W Phalconie mi się podoba dev-tools. Wywołując jedną instrukcję z linii komend mam tworzony scaffolding, czyli modele, kontrolery i widoki.
I tak trzeba to potem poprawiać, ale szkielet jest już gotowy.
Mój framework powstawał w czasach, jak jeszcze DI, DiC były mi obce.
Zresztą, to za duże słowo, bo dalej jest to zwykły zbiór klas, projekt nigdy niedokończony (za często zmieniam koncepcję), ale coś tam działa i trochę się przy tym nauczyłem.
No właśnie myślę teraz o modelach, więc coś w tym jest :), ale za to mam pełna kontrole, nad tym co robię, oczywiście kosztem czasu na początku. Podoba mi się jego koncepcja i minimalizm. Dodam do niego system cache i będzie wydajnościowo zjadać Zenda czy Symfony na śniadanie.
Tak na marginesie, framework to zbiór klas/bibliotek, więc Twój zbiór, można spokojnie frameworkiem nazwać 🙂
No właśnie z Zenda kiedyś (a może i dalej) się śmieli, że to po prostu zbiór (kupa) klas bez ładu, składu i pomysłu, dlatego nie mam dobrego zdania na jego temat i zawracać głowy sobie nim nie mam zamiaru.
Myślałem jak Ty, zrobię wszystko sam, bo będzie zoptymalizowane itp. itd… Stworzyć swój framework nie jest prostą sprawą, aby było to zgodne z aktualnymi, nowoczesnymi wzorcami projektowymi.
Trzeba przetestować przynajmniej kilka obecnych rozwiązań, żeby wiedzieć, co można zrobić lepiej i czy warto…
A propos cache, no w Slim jest cache, ale nie o taki zapewne Ci chodzi, a o cachowanie wyników z bazy danych, czyli modeli, no i tutaj znowu przewaga pełnych frameworków, jak Phalcon 🙂
Nie uciekniesz od tego. Widać Slim nie jest rozwiązaniem, którego obecnie potrzebujesz.
Możliwe, że nie jest tym co potrzebuje, ale ma to co potrzebuje. Prostota, waga i szybkość działania. Zostaje jeszcze Laravel, jako druga opcja, jakby co 🙂
Skuteczne. Laravel zawsze awaryjnie…