Ostatnio musiałem się zmierzyć z pewnym algorytmem, który wymieniał dane z aplikacją kliencką pisaną we Flashu pomiędzy PHP. Niby nic skomplikowanego, przesyłanie znaków z kodami ASCII uzyskiwanych flashowym odpowiednikiem metody urlencode(). Jednak pomimo prawidłowej realizacji algorytmu, nadal uzyskiwałem dziwne wyniki.
Jakież było moje zdziwienie, gdy odkryłem, co było grane.
Podczas pisania aplikacji zbudowanej z modułów, można natknąć się na kilka dosyć poważnych problemów, na rozwiązanie których traci się sporo czasu. Poniżej zebrałem najczęściej powtarzające się problemy związane z modułami i ich rozwiązanie.
resources.modules = ""Następnie należy wskazać ścieżkę, w której moduły się znajdują:
resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"Ważne jest, by linijka ta została dodana po ścieżce do kontrolerów domyślnych (controllerDirectory). Całość będzie wyglądała następująco:
resources.modules = "" resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers" resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"
admin.resources.layout.layout = "layout_admin"W tym przypadku admin oznacza nazwę modułu, a layout_admin nazwę pliku z layoutem.
Kanał ATOM
class Admin_Bootstrap extends Zend_Application_Module_Bootstrap
{
}
Jak widać nazwa klasa musi być poprzedzona prefiksem odpowiadającym nazwie modułu. Bootstrap modułu można wykorzystać do dodania specyficznych ustawień dla danego modułu, np inicjalizacja menu. protected function _initModules()
{
}
Następnie musimy stworzyć plugin, który załaduje aktualny moduł.
class Batman_Controller_Plugin_ModuleLoader extends Zend_Controller_Plugin_Abstract
{
public function dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
{
$module = $request->getModuleName();
// moduł domyślny można ominąć
if($module == 'default') {
return;
}
// ścieżka do pliku Bootstrap
$path = APPLICATION_PATH . '/modules/' . $module . '/Bootstrap.php';
// nazwa klasy Bootstrap
$class = ucfirst($module) . '_Bootstrap';
// inicjalizacja, załadowanie i utworzenia obiektu klasy Bootstrap modułu
$application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/modules/' . $module . '/configs/module.ini'
);
Zend_Loader::loadFile('Bootstrap.php', dirname($path));
$bootstrap = new $class($application);
$bootstrap->bootstrap();
}
}
Nie można zapomnieć o wywołaniu tego plugina, np w głównym pliku bootstrap
protected function _initPlugins()
{
$this->bootstrap('frontController');
$front = $this->getResource('frontController');
$front->registerPlugin(new Batman_Controller_Plugin_ModuleLoader());
}
Ostatnią rzeczą jaka pozostała do zrobienia jest dodanie katalogu configs w folderze modułu, a w nim pliki module.ini. Nazwa pliku konfiguracyjnego jest oczywiście w pełni umowna i można zastosować dowolną. Odwołania do zasobów w pliku konfiguracyjnym tworzy się tak samo jak w punkcie 2 tej listy. 
Nie można kwestionować faktu, że jQuery.animate() jest jednym z najbardziej potężnych narzędzi jQuery. Służy on do animowania atrybutów CSS (czyli zmiany ich wartości w czasie od obecnego stanu A do definiowanego stanu B). Najprostszą implementacją jQuery Animate jest podanie zbioru atrybutów CSS, które mają ulec zmianie oraz czasu, w jakim ta zmiana ma nastąpić. Nie będę się zagłębiał w najprostsze przykłady użycia, są one dostępne w oficjalnej dokumentacji jQuery.
Należy pamiętać, że dzięki jQuery jesteśmy w stanie nie tylko płynnie zmieniać kolory, wielkość czcionki, obramowanie, ale także pozycje elementów, nadając stronie dynamicznego kształtu. Domyślnym sposobem animowania (easing) jest płynne przechodzenie. Istnieje natomiast sposób na zmianę adaptera animowania. Robert Penner – autor pluginu jQuery Easing dostarczył nam niewiarygodnie efektowne i proste w implementacji narzędzie. Na oficjalnej stronie pluginu można znaleźć wiele przykładów animacji, które dostarcza nam dodatek. Efekty widoczne są zwłaszcza przy animowaniu pozycji i wymiarów obiektu, ale następują także w przypadku zmiany koloru – czyli są aplikowane do zmiany stanu każdego z atrybutów CSS.
Dziś postaram się pokazać efekty, jakie można uzyskać za pomocą jQuery Animate rozszerzonego o jQuery Interface oraz Easing.
Pierwszym krokiem jest wygenerowanie własnej biblioteki jQuery Interface. Dzięki generatorowi, jesteśmy w stanie ściągnąć tylko te części Interface, które są nam de facto potrzebne, zmniejszając jednocześnie ilość kodu. Klikamy ‘deselect all components’, a w sekcji Effects wybieramy efekty, których będziemy używać. Mnie w tej chwili interesuje Bounce i Slide. W paczce otrzymamy wersję deweloperską (z wcięciami) oraz minified, gotową do publikacji na serwerze.
Do wykorzystania efektu slideowania a’la iPhone (elastyczne odbicie od krawędzi ściany ekranu) sprowadza się drobny kawałek kodu, w którym istotnym jest parametr easing:
$('#example').animate({ left: 500 }, { duration: 1000, easing: 'easeOutElastic' })
Na pewno komuś się przyda.
Kilka razy zdarzyło mi się już, że skrypt nad jakim miałem pracować musiał mieć własną nazwę hosta. W związku z tym, że głównie pracuje na WAMP-ie, ustawienie vhosta dla tego skryptu wiązało się z tym, że traciłem możliwość wejścia na standardową stronę główną. Gdzie są różne przydatne rzeczy typu phpMyAdmin czy phpconfig() etc.
Jednak jest sposób na to żeby wilk był syty i owca cała, mianowicie należy sobie skonfigurować vhosty rozróżniane po nazwie (NameVirtualHost).
Jak to zrobić ?
Należy dopisać do apache-owego configa następujące linie:
NameVirtualHost *:80 <VirtualHost *:80> ServerName moja_aplikacja.local DocumentRoot "D:/www/moja_aplikacja/public" </VirtualHost> <VirtualHost *:80> ServerName localhost DocumentRoot "D:/www/" </VirtualHost>
Należy również dodać w pliku \Windows\System32\drivers\etc\hosts wpisy dla każdego nowego adresu wg wzoru:
127.0.0.1 moja_aplikacja.local
Moim drugim ulubionym (po Proxy) wzorcem projektowym jest strategia. Jako, że w większości jego opisów w internecie jest dość abstrakcyjna, postanowiłem przedstawić żywy przykład.
Pewnie robiąc jakieś PHP-owe aplikacje dla biznesu spotkaliście się z potrzebą tworzenia raportów i wykresów. Zwykle były one stałe i pre definiowane. Pisaliście klasę która miała albo osobną metodę dla każdego raportu albo jedna metodę wejściową typu ‘pobierzRaport($nazwa)’ i tam jeden wielki switch.
Nie trudno wymyślić, że nie jest to zbyt elastyczne rozwiązanie. Objętość klasy bardzo nam rośnie przy każdym dodaniu nowego typu raportu i generalnie kod staje się trudnym do utrzymania.
Jest na to rozwiązanie. Definiujemy sobie interfejs IReport:
interface IReport { public function getReportData(array $params); }
Każdy nowy raport będzie implementował ten interfejs i będzie osobną klasą której plik umieścimy np w katalogu application/reports
Zakładając, że nasza aplikacja będzie pisana w jakimś modnym MVC frameworku, kontroler będzie wyglądał tak:
class IndexController extends Some_Cool_Framework_Controller { public function reportAction(){ if($this->_request->isPost()){ $oModel = new SomeModel(); $this->_view->reportData = $oModel->getReport($this->_request->getPost()); } } }
Natomiast model tak:
class SomeModel { //... jakies rozne ciekawe metody ... public function getReport(array $data){ $oReportObject = new $data['report_name']; return $oReportObject->getReportData($data['params']); } }
W ten sposób nie będziemy dla każdego nowego raportu dokładać do klasy modelu następnej metody czy kolejnego case’a w switchu. Wystarczy stworzyć dowolną klasę która będzie implementować interfejs IReport i dodać ją do wcześniej wspomnianego katalogu.
Oczywiście powyższy przykład jest przykładem naiwnym i należało by dodać do niego filtrowanie danych z post-a.
W oryginalnym rozwiązaniu, lista raportów wraz z nazwami klas raportowych była przechowywana w bazie danych, gdzie przez panel administracyjny można było nimi wygodnie zarządzać.
