PicoAjax

Końcówka roku to oczywiście czas podsumowań i powrotów do przeszłości. Z racji tego, że podsumowań nie lubię, spróbuję wrócić do przeszłości. A to umożliwi mi… biblioteka PicoAjax, którą ostatnio przez zupełny przypadek odkryłem.

Co ciekawe, nie sądzę, żeby ta biblioteka była zła, raczej całkowicie anachroniczna. Przypomina mi dawne, złote czasy Alladyna. Zanurzmy się zatem w te wspomnienia!

  • Zacznijmy od samej strony. Szkoda, że jest tak niesamowicie nieczytelna, a same przykładowe kody nie są nawet zamknięte w znacznik code. Przydałby się także jakiś highlighter kodu.
  • Na stronie uparcie jest używany termin Ajax jako akronim (zatem zapisywany jest dużymi literami). Problem polega na tym, że… jest nawet odniesienie do artykułu, w którym termin Ajax jest definiowany jako nie-akronim. To po prostu neologizm.
  • Po przeglądnięciu dokumentacji już można wyrobić sobie zdanie o tym, jak stare praktyki są używane wewnątrz picoAjax. Mamy [onclick], mamy walidację formularzy podpiętą przy pomocy atrybutów [rel] (zamiast przy pomocy standardowych atrybutów HTML5 stworzonych w celu walidacji formularzy) czy w końcu wrzucenie ponad setki funkcji do globalnego scope. Patrząc na ten kod, naprawdę odnoszę nieodparte wrażenie, że cofnąłem się do 2005 roku.
  • Jeszcze jedna rzecz zasługuje na zainteresowanie:

    <a href="javascript:picoGo('https://pl.wikipedia.org/wiki/Internet_Explorer_11')" title="Internet Explorer 11">IE11</a>

    To klasyka złego [onclick]a.

  • Liczba funkcji w bibliotece robi wrażenie… ale czy obliczanie całki oznaczonej albo promil zawartości alkoholu we krwki (wg wzór E. Widmarka) (pisownia oryginalna) to są funkcje odpowiednie dla biblioteki typu jQuery?
  • Nazwy poszczególnych funkcji są ręcznie zaciemniane, np. picoC to „ułatwienie” przy używaniu element.style.color. I znów: czuję się jak w 2005, gdy takie praktyki faktycznie się stosowało (bo każdy bajt kodu bolał!) – wystarczy sobie zobaczyć choćby we wspomnianym Alladynie.
  • Ściągnąłem wersję 5.15 biblioteki i zajrzałem do bebechów. Pierwsza funkcja, jaką znalazłem, to loader zasobów, picLoad. I tutaj już zauważyłem kilka problemów:

    • Jeśli nie poda się adresu zasobu do wczytania, użytkownik dowie się o błędzie. Zamiast alert mimo wszystko powinniśmy rzucić błąd do konsoli.
    • Autor wyszedł z założenia, że rozszerzenie może mieć albo 2, albo 3, albo 4 znaki. Błąd. Tak naprawdę nie ma limitu znaków w rozszerzeniu. Bardziej niż samemu rozszerzeniu wierzyłbym typowi MIME.
    • Dziwi mnie także, że nie wczytam obrazka jeśli w adresie znajdzie się fraza php. Zatem loga PHP raczej nie wczytam…
  • Samo formatowanie kodu jest nad wyraz oszczędne. To strasznie utrudnia czytanie kodu.
  • Obsługa XHR mogłaby zostać przeniesiona do osobnej funkcji, bo na chwilę obecną jest niepotrzebnie powtarzana w kilku miejscach.
  • Walidator formularzy nie pozwala zmienić komunikatów o błędach. To trochę dziwne – zwłaszcza, że walidator w ogóle nie powinien zajmować się komunikatami błędów. Walidator – jak sama nazwa wskazuje – waliduje (sprawdza poprawność). Jego zadaniem jest stwierdzenie, czy i co jest źle. A co program z tą informacją zrobi, to już nie sprawa walidatora.
  • function picoGo(url) {window.location.href=url};

    Nie widzę sensu w tej funkcji – a przynajmniej nie w kontekście linków. To nic innego jak próba wynalezienia ich na nowo.

  • Dużą część kodu można obecnie przenieść do CSS-a, np. obsługę rolloverów czy generowanie tabelek-zebr (z naprzemiennym kolorowaniem wierszów).
  • Niektóre z funkcji można przepisać tak, aby pozbyć się w nich ifów, np. picoFullScreen mogłoby najpierw sprawdzać, jaka wersja API jest dostępna, a dopiero później się „przypisać na stałe”.
  • function picoC(e,k)      {eval('e.style.color=k')}
    function picoW(e,w)      {eval('e.style.width=w')}
    function picoH(e,h)      {eval('e.style.height=h')}
    function picoB(e,b)      {eval('e.style.border=b')}
    function picoF(e,f)      {eval('e.style.fontFamily=f')}
    function picoFS(e,r)     {eval('e.style.fontSize=r')}
    function picoBC(e,k)     {eval('e.style.background=k')}
    function picoBS(e,k)     {eval('e.style.boxShadow=k')}
    function picoTS(e,k)     {eval('e.style.textShadow=k')}
    function picoTA(e,k)     {eval('e.style.textAlign=k')}
    function picoBR(e,k)     {eval('e.style.borderRadius=k')}

    Tak szczerze to bym się tego pozbył. Jest to naprawdę nieczytelne.

  • function picoTxtContent(el) {return el.textContent}
    function picoTXT(id,txt) {picoId(id).innerHTML=txt}

    A tę niespójność chyba łatwo dostrzec. No i przede wszystkim: tekst to tekst! Jeśli chcę nadać wartość tekstową elementowi, to nie życzę sobie, żeby HTML był parsowany, bo np. chcę wyświetlić encje, np. &nbsp; zamiast niełamliwej spacji.

Mam to dziwne uczucie, że to nie jest nowa biblioteka. Naprawdę przywodzi na myśl stare, dobre czasy sprzed jQuery. Nie umiem powiedzieć, że jest zła – raczej zagubiona w czasie.

Tyle na dzisiaj… i w 2016 roku. Szczęśliwego Nowego Roku i do przeczytania!

8 myśli na temat “PicoAjax”

  1. picoAjax to zbiór różnych funkcji, które mogę wykorzystać podczas prowadzenia zajęć z uczniami – po prostu wyjąć odpowiedni fragment kodu omówić i tyle. Co do starych funkcji i praktyk – to kiedyś 9 czy 10 lat temu to było 2kB aby wykonać ajaxowe żądanie, a później powrzucałem wszystko co może się przydać. Myślałem aby zrobić coś nowego już w ES6 ze stricte klasami i jego nowościami (http://exploringjs.com/) ale mam już swoje lata i czasu coraz mniej.

  2. Czyli w gruncie rzeczy dobrze wyczułem, że to po prostu stary projekt. Jak na tamte czasy muszę stwierdzić, że wygląda na solidny.

    Prawdę mówiąc chodził mi po głowie pomysł przepisania tego na ES6 i bardziej modułowe podejście w ramach ciekawostki/przykładu, ale jakoś to zarzuciłem. Niemniej jeśli takie plany faktycznie istnieją, mógłbym pomóc w takim przedsięwzięciu.

  3. Panowie, przydała by się wielu osobom „biblioteczka” przydatnych funkcji napisanych w czytelny sposób 🙂 Obsługa DOM, Ajax i parę innych najczęściej wykorzystywanych umożliwiłaby wielu osobom zastąpić kobyłę zwaną jQuery 😉
    Sama sobie zrobiłam mini niezbędnik funkcji ale jako samouk nie znam standardów, z wydajnością miewam problemy, coś się umie czegoś nie, dziury w wiedzy oj dziury… Stwórzcie od siebie „niezbędnik funkcji” a zyskacie wdzięczność wielu osób szukających łatwych i czytelnych rozwiązań które posłużą i do nauki i do zastąpienia innych zbyt dużych skryptów.
    Sama potrafię już zastąpić swoim rozwiązaniem zapis operowania na DOMie z jQuery: $(‚#cos’) ale już nie potrafię dopinać do tego swoich funkcji w sposób: $(‚cos’).jakasFunkcja(‚przekazuj’)… 🙁

    1. Tak po prawdzie napisałem całą książkę o tworzeniu fundamentów biblioteki typu jQuery. Co prawda nie jest dla bardzo początkujących, ale opisuje najważniejsze rzeczy. Bibliotekę, w mocno początkowej fazie rozwoju (ach, ten permanentny brak czasu…), można znaleźć na GitHubie.

      Co do problemu z dodawaniem metod jak w jQuery: tutaj trzeba zwrócić obiekt, który będzie „opakowywał” elementy DOM. Inaczej to nie zadziała.

  4. Dziękuję za linki 🙂 Nawet nie wiedziałam mimo że często Pana wypowiedzi spotykam w sieci o książce Pana autorstwa.
    Co do opakowywania i DOM – czyli jak myślałam to trochę bardziej skomplikowane niż się by wydawało :-/ Nic będzie trzeba się z tym zmierzyć podglądając przykłady innych rozwiązań 🙂

  5. Bardzo przydatna biblioteka podczas prowadzenia lekcji. Funkcje które się znajdują w PicoAjax w czasie zajęć bardzo pomogły nam uzmysłowić zasadę działania tego typu projektów. Wiadomo nie jest on bez wad lecz dla uczniów Zespołu Szkół Techniczno-Informatycznych w Busku-Zdroju jest przydatny w celu nauki JS.

  6. Biblioteka jest bardzo rozbudowana oczywiście napewno mogła by być napisana trochę lepiej jak niektórzy wspomnieli ale do tego potrzeba czasu i wsparcia nieożna oczekiwać odpowiednika jQuery za którą stoi sztab ludzi. Sam używam jej już pewien czas jedyne co bym zmienił to stworzyłbym jakieś sortowanie tych funkcji po czasie dodania owszem można zauważyc że jest nowa funkcja ale teraz trzeba przeanalizować całą listę aby znaleźć tą nową

  7. @Ewa

    Nie takie trudne, pod warunkiem, że się rozumie koncept obiektowości? Jeśli rozumiesz, to wtedy wystarczy zrozumieć, że każdy wybrany poprzez funkcję $(‚selektor’) element DOM tworzy swojego rodzaju obiekt jQuery. Na tym obiekcie następnie można wykonywać wszystkie metody (funkcje), jakie oferuje ogólnie jQuery. Po wykonaniu każdej funkcji musisz na jej wyjście zwrócić (return) obiekt „this” – dzięki czemu będzie można od razu podpiąć poprzez kropkę kolejne funkcje i je w ten sposób „chainować” (łańcuchować).

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *