Nie znam biblioteki, która bardziej podbiłaby serca programistów stron internetowych niż jQuery właśnie. Wielu ją polubiło od pierwszej linijki kodu, wielu nienawidzi, chociaż nie zna. Nie zmienia to jednak faktu, że projekt rozpoczęty przez Johna Resiga okazał się być strzałem w dziesiątkę, rozwiązującym setki problemów związanych z różnicami w implementacji silników JavaScriptu w przeglądarkach internetowych. [...]

Ostatnimi czasy w świecie front-endu dzieje się naprawdę sporo! Przeglądarki coraz śmielej implementują HTML5/CSS3, użytkownicy coraz szybciej aktualizują przeglądarki, powstają nowe frameworki, narzędzia do programowania 2D czy nawet 3D w JavaScript. Wchodzimy w erę mobilności, zwiększamy interakcję w aplikacjach, pojawiają się nowe typy aplikacji, a wraz z nimi nowe problemy. Ten wpis jest poświęcony jednemu [...]

Devmeetings to seria warsztatów dla software developerów, podczas których w ciągu kilkunastu godzin powstaje kilka wersji tej samej (niebanalnej!) aplikacji napisanej przez kilka grup. Każde szkolenie posiada swój temat przewodni i jest prowadzone przez wykwalifikowanego specjalistę. Miałem okazję uczestniczyć już w dwóch takich, dlatego z przyjemnością informuje o następnym evencie z tej serii – mianowicie JavaScript na serwerze: RingoJS, V8CGI i NodeJS.

Szkolenie poprowadzi David de Rossier. Więcej informacji na jego temat znajdziecie na stronie Devmeetings.pl, ja dodam tylko, że miałem okazję posłauchać wykładu przez niego prowadzonego. David zdecydowanie jest pasjonatem – widać to po sposobie w jaki opowiada, czy też w jaki sposób wyjaśnia zagadnienia. Dodatkowo – ma bardzo dobry kontakt ze słuchaczami.

Tak więc od siebie szkolenie to jak najbardziej polecam – same plusy:

• jest darmowe
• ciekawy temat (zwłaszcza dla PHPowców, którzy głownie pracują po stronie backendu)
• świetny klimat
• ogrom wiedzy
• kilka możliwych lokalizacji.
• niespodzianki ;)

Liczba miejsc jest ograniczona! Dokładniejsze informacje znajdziecie na stronie Devmeetings.pl, a mi nie pozostaje nic innego jak zaprosić Was do Poznania 14 maja, gdzie i ja planuje się pojawić. Jestem przekonany, że nie pożałujecie :)

JavaScript to chyba najbardziej dynamicznie rozwijający się język programowania pod względem powstającej bazy kodu i przydatnych narzędzi wspomagających. Przyjrzyjmy się kilku ciekawym bibliotekom, jakie możemy wdrożyć do naszych projektów bez zbędnego wysiłku, a ku uciesze klientów. Linkdump: Zbiór przydatnych bibliotek JavaScript. 1. d3.js Data-Driven Documents. Biblioteka wspomagająca przetwarzanie stron internetowych opartych na dużych zbiorach danych. [...]

Krótka historia dlaczego i jak powstał mały programik, który nie ma żadnego praktycznego zastosowania.Jedyne co mi przychodzi do głowy, to okazja do zapoznania się z HTML5/Canvas.

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.

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...

Zwiń
Czytaj na blogu autora...

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.