Mamy niedzielę, więc warto trochę poprogramować dla sportu (oczywiście zamiast uprawiania „normalnego” sportu ). Z głupoty chciałem rozpracować kilka rzeczy. Przede wszystkim wprawić się trochę w CoffeeScript, a przy okazji sprawdzić w działaniu zapisywanie danych po stronie przeglądarki przy użyciu localStorage.

Moim dzisiejszym zamiarem było stworzenie strony z formularzem, w którym wpisywane wartości zapisywałyby się na bieżąco po stronie przeglądarki wpisującego. Powiedzmy, że jakaś sierotka podczas wypełniania formularza zamknie kartę/przeglądarkę i całe mozolne wpisywanie poszło w las. Dzięki localStorage wpisane dane nie zostaną skasowane, a formularz wypełni się automatycznie. Oczywiście niesie to za sobą szereg niebezpieczeństw, jak np. co w przypadku kogoś korzystającego z publicznego komputera, chcącego zamówić coś w sklepie internetowym i mu się nagle „odwidzi”? Następna osoba dostanie dane osobowe poprzednika na tacy. Minimalnym zabezpieczeniem byłby mechanizm kasujący dane jeśli są sprzed dłużej niż np. 2 minut.

Dodatkowo chciałem zrobić przycisk, który daje jakąś kontrolę nad przechowywanymi danymi. Efekt można sobie oglądać tutaj.

Używana przeze mnie wtyczka do kolorowania składni (WP-Syntax) nie obsługuje CS. Zamiast tego kod umieszczę za pomocą embedded gist z GitHub. Efekt jest bardzo ładny. Poniżej „mózg” formularza: Efektu kompilacji nie pokazuję. Jeśli ktoś bardzo chce to może sobie podejrzeć plik storager.js.

Jeśli szukasz biblioteki backupu danych formularza w czasie rzeczywistym opartego o localStorage to polecam wtyczkę jQuery: Sisyphus.

Wracamy na poważnie. :) Jakiś czas temu miałem problem z usuwaniem „niewidzialnych znaków” ze stringa w PHP. Mam na myśli oczywiście wszystkie te, które normalnie zapisujemy jako „slash-coś” – \n, \r, \t i tak dalej. W dzisiejszym wpisie pokażę Wam … #LINK#

Użytkownicy pracujący w serwisach intranetowych wielokrotnie stoją przed koniecznością wydrukowania jakiegoś dokumentu czy formularza celem zachowania papierowej dokumentacji czy wydania papierowej wersji klientowi. Dotychczas realizowałem to tworząc i otwierając w nowym oknie dokument PDF gdzie użytkownik musiał ręcznie wybrać opcję Drukuj. Teoretycznie to działa, aczkolwiek jest troszkę upierdliwe. Jednakże ostatnio  przypadkowo trafiłem na informację że PDF może zawierać swój kod JS więc postanowiłem troszkę poeksperymentować.

Sytuacja z życia wzięta – pielęgniarka pobiera próbki do badań laboratoryjnych. Na stronie ma listę zleconych testów oraz informacje jakie i ile próbek pobrać. Na każdą próbkę powinna wydrukować naklejkę z unikalnym kodem kreskowym. Problemem jest to drukowanie: naklejki są małe, kod długi i mało czytelny bez czytnika – przy drukowaniu „masowym” po pobraniu wszystkich próbek łatwo o pomyłkę. Drukowanie każdego kodu w miarę dodawania jest znowu bardzo niewygodne – kliknięcie „dodaj próbkę”, czekanie aż otworzy się okienko z plikiem PDF, kliknięcie drukuj, potwierdzenie ustawień drukowania (wybrać drukarkę do etykiet) i druk, zamknięcie okienka z plikiem PDF. Na szczęście jest na to sposób.

Tym sposobem jest właśnie Acrobat JavaScript.

Dla zainteresowanych dokumentacja znajduje się tutaj: http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/javascript/AcroJS.pdf

Co prawda AJS nie daje nam pełnych możliwości w zakresie drukowania dokumentu, ale już to co jest może nam znacznie ułatwić życie. Dzięki temu udało mi się zredukować cały proces do kliknięcia „dodaj próbówkę” i kliknięcia OK w komunikacie że PDF chce coś wydrukować.

Zaczynamy od naszego dokumentu PDF. Jako kreatora używam znakomitej biblioteki TCPDF, w której można znaleźć metodę IncludeJS(). Mój kod JS wygląda następująco:

// Ustawieniadrukowania
var pp = this.getPrintParams();

// Wybieramy drukarkę (Nazwa drukarki widoczna w systemie)
pp.printerName = "DYMO LabelWriter 450 Turbo";

// Ustawiamy automatyczny wybór rozmiaru papieru
pp.flags |= pp.constants.flagValues.setPageSize;

// Dodatkowe skalowanie aby dopasować dokument do papieru
pp.pageHandling = pp.constants.handling.fit;

// Drukujemy tylko treść bez żadnych dodatków
pp.printContent = pp.constants.printContents.doc;

// tryb "cichego" drukowania - pomijamy okno z preferencjami drukowania
pp.interactive = pp.constants.interactionLevel.silent;

// Wymuszenie drukowania
this.print(pp);

Taki JS  należy „zapisać” w dokumencie PDF. W TCPDF jak wspomniałem odpowiada za to metoda IncludeJS

$pdf = $this->_prepareStickerPDF( $stickerData );

if ( $this->getRequest()->getParam('print', 'false') != 'false' ) {
    // KOD Adobe PDF JS do wymuszenia drukowania i ustawienia podstawowych parametrów
    $js = '
        var pp = this.getPrintParams();
        pp.printerName = "DYMO LabelWriter 450 Turbo";
        pp.flags |= pp.constants.flagValues.setPageSize;

        pp.pageHandling = pp.constants.handling.fit;
        pp.printContent = pp.constants.printContents.doc;
    ';

    if ( $this->getRequest()->getParam('print', 'false') == 'silent' ) {
        $js .= 'pp.interactive = pp.constants.interactionLevel.silent;';
    }

    $js .= ' this.print(pp); ';

    $pdf->IncludeJS($js);
}

$pdf->Output('Sticker.pdf', 'I');

Ok. Mamy spreparowany dokument PDF który automatycznie przy otworzeniu chce się drukować na ustawionej drukarce. Teraz trzeba coś zrobić aby pozbyć się popupów z PDF’em. Z pomocą przyjdzie nam możliwość osadzania obiektów PDF w HTML’u. Możemy to zrobić przez znaczniki HTML lub z poziomu JS (więcej info: http://blogs.adobe.com/pdfdevjunkie/web_designers_guide). Z poziomu JS wykorzystuję do tego PDFObject. W pliku HTML mam placeholder o zerowych rozmiarach i do niego wczytuję dokumenty PDF.

 

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

Zwiń
Czytaj na blogu autora...

Podczas realizacji jednego z ostatnich projektów, używałem selektora :contains jak się okazało selektor ten nie jest wrażliwy na wielkość znaków czyli dla niego kot i KOT to to samo niestety nie o to chodziło mojemu klientowi

W internecie natknąłem się na ciekawe rozwiązanie definiujące własny selektor :Contains dzięki czemu mogłem używać standardowego :contains jak i nowego :Contains. Poniżej znalezione rozwiązanie:

jQuery.expr[':'].Contains = function(a,i,m){
    return jQuery(a).text().toUpperCase().indexOf(m[3].toUpperCase())>=0;
};

Facebook to dla developera wieczne utrapienie. Ciągłe zmiany w interfejsie, w API, dodawanie coraz to nowych funkcjonalności czy choćby permanentny redesign zmuszają do bezustannego poprawiania napisanych aplikacji. Pisząc aplikacje na facebook średnio raz na pół roku muszę być przygotowany na to, że połowę rzeczy, które nauczyłem się ostatnio implementować teraz będę musiał zrobić w zupełnie [...]

src: http://http.cdnlayer.com

Ochrona własnego adresu poczty elektronicznej stała się „oczywistą oczywistością”. Niezliczone spam-boty przeczesują Internet w poszukiwaniu adresów email, które później zalewane są falą niechcianej poczty. Niestety często jesteśmy zmuszeni udostępnić swój adres. Wpisany zwykłym tekstem, a tym bardziej dodany do linku z mailto stanie się bardzo szybko łupem spamerów. O ile na formę upublicznienia adresu w obcych serwisach zwykle nie mamy wpływu, o tyle mamy w przypadku własnych. Jako, że potrzeba jest matką wynalazku, postanowiłem stworzyć własne rozwiązanie. Połączenie CSS i JavaScript przyniosło oczekiwany skutek.

Założenia protectEmails

Tworząc założenia starałem się patrzeć na problem możliwie z wielu stron. Najważniejszymi punktami są:

1. Czytelność dla użytkownika końcowego
2. Ochrona przed podstawowymi mechanizmami spam-botów
3. Łatwość modyfikacji wyglądu
4. Prostota w stosowaniu

Czytelność dla użytkownika końcowego

Przede wszystkim chciałem uniknąć rozwiązań typu info [at] example.com, które poza tym, że już dawno nie chronią przed botami, to dodatkowo są męczące dla użytkowników. Wszystkie odmiany tego rozwiązania charakteryzują się tą samą trudnością w pozyskaniu maila przez odwiedzającego stronę – podmiana fragmentów, łatwość pomyłki. Tworząc swoje rozwiązanie, chciałem, aby adres email był widoczny w zwykłej formie, po prostu jako info@example.com.

Dodatkowo, uważam, że ważne jest też zachowanie standardowej funkcjonalności linku, który otwiera domyślny program pocztowy klienta.

Ochrona przed podstawowymi mechanizmami spam-botów

Rozwiązanie musi być w jakiś sposób unikatowe, tak aby standardowe funkcje spamerów nie były w stanie takiego adresu wyłuskać. Oczywiście, nie da się zabezpieczyć w 100%, zawsze znajdzie się ktoś, kto napisze dedykowane rozwiązanie. Jednak dużą część automatów można wyeliminować.

Poszukując gotowych rozwiązań spotkałem się z dużą ilością pseudo-zabezpieczeń. Nie dość, że utrudniają one życie użytkownikom, to dodatkowo wystawiają adresy na pastwę botów, np.:

<a href="mailto:info@example.com">info [ at ] example.com</a>

<a href="mailto:info@example.com">info [ at ] example [dot] com</a>

Lub po prostu utrudniają życie, np.:

<span class="email">info [ at ] example [dot] com</spam>

W przypadku powyższego istnieją rozwiązania oparte na JavaScript, które na podstawie klasy modyfikują znacznik span, przerabiając go na klikalny adres email. Jest to dość dobre rozwiązanie z jednym mankamentem – adres jest czytelny dla botów.

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

Zwiń
Czytaj na blogu autora...

Poznań, 14 stycznia 2012 r – konferencja meet.js summit, choć minął już tydzień od tego wydarzenia, ja wciąż jestem pod wrażeniem. Konferencja była niejako podsumowaniem lokalnych spotkań meet.js. Są to niekomercyjne meetup’y front-endowców, na których prezentowane są prelekcje na tematy webowe (front-endowe), jts HTML, JS, CSS.

Organizacja

Konferencję zorganizowali Damian Wielgosik wraz z GTUG Poznań oraz Startup-It.pl. Obsługa uczestników przebiegała szybko i sprawnie, technicy pod ręką, wszyscy chętni do pomocy. Chylę czoła za jakość organizacji tego darmowego(!) eventu.

Miejsce: Centrum Wykładowe Politechnki Poznańskiej – duży, przestronny, nowoczesny budynek, sale wykładowe, sporo wolnego miejsca na korytarzach. Dzięki temu prezentacje na były łatwiejsze w odbiorze, a duża przestrzeń na korytarzach spokojnie pomieściła te ponad 250 osób. Nawet podczas przerw kawowych czy lunchu.

Gadżety: dużym zaskoczeniem była duża ilość gadżetów i nagród. Sponsorzy spisali się świetnie. Były naklejki meet.js i Front-Trends, smycze od Mozilli oraz Allegro Group, zniżki 10€ na konferencję Front-Trends 2012. Poza tym do zgarnięcia były kubki i koszulki Google, naklejki HTML5, koszulki Mozilli, Nodejitsu i HTML5, pendrive’y i smycze Nokii. Każdy dostał koszulkę, przy tym wartym wspomnienia jest, że można było zaprojektować własną lub zaproponować tekst do chmurki z komiksu. Wykazując się taką inwencją brało się udział w konkursie, w którym główną nagrodą był iPod!

To nie koniec, były ciastka, a do nich kawa i/lub herbata (woda dla unikających używek ). Był też lunch (3 dania do wyboru), tak jak reszta – darmowy. Po całodniowej konferencji nastąpiło zasłużone afterparty (dzięki Cognifide), na którym każdy z uczestników otrzymał kupony do wykorzystania w barze.

Przebieg i prezentacje

Całość rozpoczęła się od 10 rano (rejestracja od 9) a zakończyła następnego dnia w godzinach porannych w Alcatraz Club. Prezentacje były przeplatane z przerwami kawowymi oraz lunch’em. Był zatem czas na zmianę sali oraz przygotowanie dawki kofeiny.

Z racji dużej liczby prezentacji (18) całość została podzielona na 2 ścieżki. Osobiście nie przepadam za takimi rozwiązaniami bo czasem jest bardzo trudno się zdecydować, którą prelekcję wybrać. Z tego względu nie uczestniczyłem we wszystkich w których bym chciał. Na szczęście całość wystąpień była nagrywana, zatem jest szansa, że zobaczę te, które niestety ominąłem.

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

Zwiń
Czytaj na blogu autora...