Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: singles, dodany: 24.03.2011 18:26, tagi: javascript, php, zend_framework

W dzisiejszym wpisie z serii ZFQT chciałbym przybliżyć temat helperów z rodziny head[type]. Oprę się na przykładzie headScript, ponieważ jest on jednym z najczęściej używanych helperów podczas tworzenia aplikacji ZF. Służy do zarządzania/dołączania skryptów JS w ramach naszej aplikacji.

Niektórzy powiedzą pewnie:

Po co mi jakaś klasa do dołączania skryptów? To przecież takie proste jest.

W przypadku większych projektów zdarza się, że posiadamy jeden/dwa główne skrypty – najczęściej jest to jakiś framework JS + biblioteka UI. Jednak, niektóre ze stron naszej aplikacji wymagają specyficznego dla siebie kodu. A dołączanie wszystkich potrzebnych plików dla każdej strony, nawet jeśli nie są one tam wykorzystywane, ciężko nazwać postępowaniem rozsądnym. Najlepiej byłoby załączać najczęściej używane pliki w głównym layoucie, a specyficzne skrypty tylko w przypadku niektórych akcji.

Jeśli by się głębiej nad tym problemem zastanowić, to fajnie byłoby mieć taki „koszyk”, do którego można by wrzucać potrzebne skrypty – w zależności od potrzeb – podczas wykonywania kodu, a wyświetlać je na samym końcu. W takim właśnie celu powstał helper headScript w ZF (oraz jego „bracia”). Konkretniej mówiąc, powstał helper placeholder, po którym wspomniane helpery head dziedziczą. Ich działanie (w skrócie) polega właśnie na agregowaniu tekstu/kodu/danych. Dobre wyjaśnienie znajdziecie w dokumentacji do ZF – jest tam także lista wszystkich klas dziedziczących po placeholder.

Nieprawidłowa kolejność skryptów w przypadku headScript

Jest jeden konkretny powód, dlaczego napisałem, że oprę się na helperze headScript. Otóż to, w przeciwieństwie do jego „braci”, w jego przypadku ważna jest kolejność, w jakiej skrypty dołączone. Prosty przykład – mamy jQuery, jQueryUI oraz kawałek kodu, który wspominane biblioteki wykorzystuje. Po szybkim przejrzeniu dokumentacji pierwsze podejście będzie wyglądało pewnie tak:

<?php echo $this->doctype(Zend_View_Helper_Doctype::HTML5); ?>
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>SampleApp</title>
</head>
<body>
    <p>[menu] | [menu] | [menu] | [menu] | [menu] | [menu]</p>
    <?php echo $this->layout()->content ?>
 
<!-- scripts -->
<?php echo $this->headScript()->appendFile('http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js')
                              ->appendFile('ttps://ajax.googleapis.com/ajax/libs/jqueryui/1.8.11/jquery-ui.min.js'); ?>
</body>
</html>
 
//application/views/index/index.phtml
<div id="dialog-content" title="Basic dialog">
	<p>This is the default dialog which is useful for displaying information. The dialog window can be moved, resized and closed with the 'x' icon.</p>
</div>
<?php $this->headScript()->appendScript(<<<JS
$(document).ready(function(
    //RB używamy pluginu dialog z jQuery UI.
    $('#dialog-content').dialog();
));
JS
);

Dlaczego dołączyłem skrypty na samym końcu? Ponieważ jest to dobra praktyka prowadząca do powstawania wydajniejszych aplikacji – patrz Yahoo Developer Network.

Po uruchomieniu takiego kodu otrzymamy jednak błąd.

error

Błąd JS przy nieprawidłowej kolejności skryptów

Zend Framework najpierw dołączył kod z widoku, a następnie te zdefiniowane w layoucie. Patrz screen:

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: batman, dodany: 24.03.2011 08:48, tagi: css

Z czym kojarzą się okna modalne? Najczęściej z JavaScript zapakowanym w zgrabną bibliotekę. A co jeśli okna modalne można byłoby tworzyć tylko w CSS? Świat na pewno byłby piękniejszy.

Jak to możliwe, że CSS jest w stanie reagować na akcje użytkownika? Wszystko dzięki pseudo selektorowi :target, właściwości pointer-events oraz transformacjom i efektom przejścia.

Więcej informacji znajdziecie na stronie projektu http://www.paulrhayes.com/2011-03/css-modal/, a działające demo pod adresem http://www.paulrhayes.com/experiments/modal/. Okna modalne zadziałają we wszystkich najnowszych przeglądarkach, za wyjątkiem Opery oraz IE9.

Autor wpisu: batman, dodany: 23.03.2011 21:13, tagi: css

Rosnąca popularność CSS3 spowodowała istny wysyp eksperymentów bazujących na tej technologii. Ostatnim eksperymentem na jaki natrafiłem jest Cezar – narzędzie służące do generowania prostych animacji CSS bazujących na efektach przejścia. Wystarczy, że wybierzemy (lub ustawimy własnoręcznie) rodzaj przejścia oraz czas trwania. Resztą zajmuje się CSS. Możemy nawet obejrzeć kilka różnych animacji działających z ustalonymi przez nas parametrami.

Projekt znajdziecie pod adresem http://matthewlein.com/ceaser/

Autor wpisu: matipl, dodany: 23.03.2011 08:20, tagi: php

php-logoKażdy programista PHP jest bardzo przyzwyczajony do wyglądu głównej strony projektu PHP. Strona nie zmieniała się mimo upływu lat (ostatnie zmiany w 2002), zmianie mody. Ostatnio nawet strona domowa Debiana zrobiła się bardziej trendy.

Nową stronę główną PHP.net możecie zobaczyć dodając do URL-a ?beta=1 albo wchodząc na http://www.php.net/my.php i włączając opcję PHP.net alpha.

php.net - nowa odsłona

Czy to rewolucja? Nie, raczej krok w dobrym kierunku. Strona jest teraz lżejsza wizualnie. Cały nagłówek jest nieznacznie niższy. Na stronie głównej w nowej wersji od razu rzuca się w oczy aktualna wersja PHP oraz tutorial dla początkujących. Mnie najbardziej cieszy zmiana w menu. Z poprzedniego w ogóle nie korzystałem, nawet nie pamiętam jakie tam sam linki, a teraz…

Nowe menu jest zgrabniejsze i zawiera mniej pozycji. Sekcje Documentation, Community oraz Help są rozwijalne dzięki czemu mamy szybki dostęp do najważniejszych haseł. Będziemy mogli od razu ze strony głównej przejść chociażby do działu dot. Garbage Collection. Nowy pasek menu będzie dostępny także w manualu.

php.net - nowy i stary manual

W manualu niewielkie zmiany. Dzięki niższemu nagłówkowi, pozbyciu się submenu z poprzednią i następną pozycją, oraz zmianie paska językowego widzimy teraz więcej na ekranie (o jakieś 100 pikseli,~ 4 linijki tekstu). Niestety nie mogę znaleźć informacji od kiedy trwają prace i kiedy się zakończą.

Dla potomnych zrzut ekranu aktualnej wersji php.net:

php.net - wersja 2002-2010

Autor wpisu: batman, dodany: 23.03.2011 08:00, tagi: php

Przy okazji pisania biblioteki do wysyłania powiadomień z aplikacji opartej o Zend Framework, odświeżyłem (a w zasadzie poznałem na nowo) bibliotekę PHPUnit. Nie obyło się bez zgrzytów, zwłaszcza podczas korzystania z PEAR. Aby w przyszłości nie musieć szukać kolejny raz szukać tego samego postanowiłem przygotować ten oto poradnik instalacji PEAR oraz PHPUnit na serwerze WampServer.

Instalację zaczniemy od PEAR. Wbrew pozorom nie jest to czarna magia i jedyne co trzeba robić, to uważnie czytać komunikaty pojawiające się na ekranie. Zatem do dzieła.

  1. Przed instalacją musimy upewnić się, że mamy zainstalowane i działające rozszerzenie Phar. Warto również w pliku php.ini odkomentować opcję phar.require_hash oraz ustawić jej wartość na Off.
  2. Następnie otwieramy wiersz poleceń (cmd) i przechodzimy do katalogu, w którym zainstalowany jest PHP. W moim przypadku jest to C:\wamp\bin\php\php5.3.5
  3. Znajdując się we wspomnianym wyżej katalogu uruchamiamy skrypt go-pear.bat
  4. Proces instalacji PEAR rozpoczyna się od wyboru rodzaju instalacji. Wpisujemy local i zatwierdzamy enterem.
  5. Postępujemy zgodnie ze wskazówkami pojawiającymi się w kolejnych krokach instalacji. Wszystkie ustawienia pozostawiamy domyślne oraz zezwalamy na dokonanie zmian w php.ini
  6. Podczas instalacji pojawi się najprawdopodobniej błąd ERROR: unable to unpack phar://C:/wamp/bin/php/php5.3.5/PEAR/go-pear.phar/PEAR/go-pear-tarballs/Structures_Graph-1.0.2.tar. Błąd ten oznacza, że jeden z najbardziej potrzebnych komponentów nie zainstalował się i trzeba zrobić to ręcznie. W tym celu ze strony http://pear.php.net/package/Structures_Graph/download pobieramy paczkę, następnie ją rozpakowujemy i kopiujemy katalog Structures wraz z zawartością do głównego katalogu PEAR. W moim przypadku znajduje się on tutaj – C:\wamp\bin\php\php5.3.5\PEAR
  7. Pozostało jeszcze dodać odpowiednie zmienne środowiskowe. Pomoże nam w tym plik PEAR_ENV.reg znajdujący się w katalogu instalacyjnym PHP (u mnie jest to C:\wamp\bin\php\php5.3.5). Zanim go wykonamy musimy upewnić się, że zmienna PHP_PEAR_PHP_BIN poprawnie wskazuje na plik php.exe. Jeśli nie, to musimy poprawić ten wpis.
  8. Na koniec pozostało przetestowanie czy PEAR działa. Doskonale nadaje się do tego próba aktualizacji pear-a. W wierszu poleceń wpisujemy pear upgrade i czekamy na zakończenie aktualizacji. Jeśli po drodze nic niespodziewanego się nie wydarzyło, oznacza to, że pear jest poprawnie zainstalowany. Podczas wykonywania aktualizacji może się okazać, że będziemy musieli włączyć dodatkowe rozszerzenia w PHP. Będą to XML_RPC oraz Curl.

Po przebrnięciu przez instalację PEAR, instalacja PUPUnit będzie formalnością. Wygląda on następująco.

  1. Dodajemy niezbędne kanały: pear channel-discover pear.phpunit.de pear channel-discover components.ez.no pear channel-discover pear.symfony-project.com
  2. Instalujemy PHPUnit pear install phpunit/PHPUnit
  3. Aktualizujemy PHPUnit pear upgrade phpunit/PHPUnit

Na koniec pozostało sprawdzić, czy wszystko działa jak należy. W tym celu w wierszu poleceń wpisujemy phunit. W wyniku powinniśmy otrzymać informację z pomocą.

Autor wpisu: Śpiechu, dodany: 23.03.2011 01:30, tagi: javascript, jquery

We wszystkich swoich projektach WWW mających mieć wodotryski zapewne używacie jakichś bibliotek Javascriptowych. Ja używam jQuery. Do wywołania efektu powiększającego się obrazka na przyciemnionym tle przyjął się powszechnie skrypt Lightbox. Korzysta niestety z bibliotek Prototype i Scriptaculous. W efekcie stworzenie kilku prostych efektów + efekt lightbox generował potrzebę pobrania przez użytkownika trzech sporych bibliotek ze skryptami JS.

Dzisiaj chciałem zareklamować skrypt, który używa wyłącznie jQuery przy tworzeniu lightboksa. Zwie się jQuery lightBox plugin. Sama instrukcja użycia jest dosyć prosta i nie będę o niej pisał. Zamiast tego napiszę jak zrobić żeby nie trzeba było otaczać obrazków linkami, chociażby po to, że nie chcemy oficjalnie chwalić się adresami url do dużych obrazków. Opis do ramki weźmiemy z atrybutu alt="", czyli ostatecznie nie musimy dokonywać żadnych zmian w kodzie HTML strony.

Standardowe przygotowanie kodu HTML wygląda tak: <a href="duzy_obrazek.jpg" rel="lightbox" title="Tytuł obrazka" ><img src="maly_obrazek.jpg"></a<. Wyżej wymienioną przeze mnie bibliotekę da się w miarę łatwo zmusić do współpracy z samymi elementami <img>, a samo wywołanie lightboksa może robić się automagicznie na podstawie rodzica <div> otaczającego obrazki. Potrzeba tylko kilku przeróbek kodu biblioteki.

Bierzemy na warsztat plik jquery.lightbox-0.5.js. Interesują nas okolice 77 linijki kodu (lub 15 w wersji zminiaturyzowanej pliku), a dokładniej trzy miejsca zaczynające się od objClicked.getAttribute('href'). Zamieniamy je na objClicked.getAttribute('src').replace("small", "big"), czyli fragment oryginalnego linka do zdjęcia w locie zamieniany jest z small na big. Jeżeli chcemy żeby opis fotek brany był z atrybutu alt="", to musimy dodatkowo zamienić w dwóch miejscach objClicked.getAttribute('title') na objClicked.getAttribute('alt').

Zakładamy oczywiście, że pliki z małymi obrazkami trzymamy w katalogu images/small/obrazek.jpg, a duże obrazki z taką samą nazwą jak małe mamy w katalogu images/big/obrazek.jpg.

Taką bibliotekę trzeba jeszcze wystartować, czyli podać jej jakie obrazki powinny być powiększane. W sekcji <head> dodajemy sobie taki skrypt:

$(document).ready(function() {
    $('div.ramkanazdjecia > img').lightBox();
});

Cała zawartość „obrazkowa” <div class="ramkanazdjecia"> stanie się lightboksowa.

Autor wpisu: Kamil, dodany: 23.03.2011 00:52, tagi: php, javascript

Każdy kto używał jQuery i tworzył pod niego pluginy to zdążył już zapoznać się z genialną metodą $.extends służącą w głównej mierze do łączenia kilku obiektów z nadpisywaniem istniejących już metod / własności. Najczęstszym wykorzystaniem niniejszej metody jest łączenie dwóch obiektów: z domyślnymi parametrami danego obiektu, z ustawieniami zdefiniowanymi przez użytkownika. Najlepiej i najłatwiej będzie [...]
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.