Prototype - oficjalne API i dokumentacja

Posted by Jarosław Zabiełło Fri, 19 Jan 2007 15:53:00 GMT

Znana biblioteka Prototype doczekała się własnej dokumentacji, API oraz bloga: http://prototypejs.org. Prototype zapewnia lekkie, eleganckie API o składni wzorowanej na języku Ruby. Ta składnia jest tak ładna, że niektórzy nawet nie widzą potrzeby tworzenia dodatkowych helperów. W tej chwili to, moim zdaniem, najlepsza biblioteka do JavaScript i AJAX. Rails postawił zdecydowanie na dobrego konia. Pylons – niejako “z rozpędu”, bo skopiowali railsowe helpery – też. :)

Rozmawiałem niedawno na IRC’u (irc.freenode#pylons) z developerami Pylonsów. Mają rozszerzyć swoje helpery o dodatkowe funkcje, ale nie zaimplementują pętli które są w Prototype i railsowych RJS (szablonach generujących JavaScript w jęz. Ruby) Ograniczeniem jest tu składnia Pythona. Tzn. można by się pokusić o taką implementację, ale byłaby mało “pythonic”, tj. zgodna z filozofią i czytelnością języka Python. Więc raczej na RJS dla Pythona nie ma co liczyć.

Wg mnie te wszystkie helpery jakie ma RoR (i RJS w szczególności) to jedna z lepszych cech Railsów której brak u konkurencji. Nie zgodzę się tu z tymi, co uważają że lepiej w ogóle nie używać żadnych helperów i pisać w czystym JavaScript. Mimo ładnej składni Prototype, railsowe helpery i RJS dają znacznie większy komfort pracy. Np. weźmy taką konstrukcję w pliku RJS:

page.replace_html :my_id, :partial => 'podszablon'

Co robi powyższa metoda? Buduje kod JavaScript który podmienia zawartość (innerHTML) dla tagu o id =’my_id’ zawartością szablonu RHTML (oczywiście jego zawartość jest automatycznie “escape’owana”, aby kod JS się nie wysypał). Trzeba się nieźle napracować aby uzyskać podobny efekt poza Railsami.

Trochę się dziwię, że Django myśli o dodaniu Dojo zamiast Prototype. Mamy w pracy raczej złe doświadczenie z Dojo. Jest ciężkie, zamotane, trudne do debugowania, modyfikacji. To po części efekt podejścia nastawionego na używanie złożonych komponentów (naśladują .NET?) Takie podejście (używanie zbyt wysokopoziomowych, złożonych komponentów) generalnie spotyka się z krytyką wielu programistów. Prościej operować elastycznym i przejrzystym kodem (takim jak w Prototype) niż gotowymi, zamkniętymi i trudnymi do debugowania komponentami Dojo.

Tags , , , , ,  | 9 comments

Comments

Leave a response

  1. Avatar Adi said about 1 hour later:

    A ja najbardziej lubię jQuery. Podoba mi się składnia, IMHO najlepsza, w sumie w Dojo podobna.

  2. Avatar Adi said about 1 hour later:

    Pomyłka, źle spojrzałem, Dojo podobnej składni raczej nie ma :) (przyznam szczerze, że nie używałem), ale z jQuery i Prototype wolę to pierwsze.

  3. Avatar Tomasz Bielecki said about 3 hours later:

    Tak, RJS znowu ratuje mi tyłek:) Z innych ciekawych bibliotek lubię jeszcze moo.fx – sporo ciekawych rozwiązań, np. dodawanie zdarzeń poprzez klasy css.

  4. Avatar pawel said about 7 hours later:

    Przedwczoraj trafilem te ich nowa stronke, wreszcie jest gdzies dokumentacja API. jQuery jest swietne zwl. z dodatkami (Interface Elements , Greybox, ThickBox) ale z wygody uzywam Prototype i Aculo (zreszta sa one rownie dobre, mam po prostu takie wrazenie, ze efekty oparte na jQuery sa bardziej plynne i lekkie).

    BTW. wlasnie wyszla nowa wersja aculo 1.7.0 i oczywiscie od razu jest w trunku railsow.

    A myslalem, ze pythonowcy preferuja Mochikit :)

  5. Avatar riklaunim said about 8 hours later:

    jQuery sypie się trochę pod Konquerorem ;)

  6. Avatar tharkang said about 17 hours later:

    Mi osobiście najbardziej podoba się YUI. Działa dobrze, jest przenośne, ma świetną dokumentację i nie udziwnia JavaScriptu próbując uczynić go czymś innym niż jest – bo tego dobrze zrobić się nie da.

    Do Prototype zniechęca mnie na przykład błąd pod Konquerorem (Can’t find variable: HTMLFormElement). Dojo zaś kilkakrotnie przy ładowaniu (strona projektu->dema) zamroziło całą przeglądarkę – i to nie tylko Konquerora ale też Firefoxa.

    YUI działa dobrze wszędzie. I dobrze współpracuje z Django, co można zobaczyć na przykładach w wiki djangowym (a także na Django Book).

    Najlepiej gdyby Django umożliwiło współpracę z różnymi toolkitami AJAXowymi – zrobiło ogólne metody i ich implementacje dla głównych toolkitów.

  7. Avatar riklaunim said about 19 hours later:

    Django nie zrobi czegoś ogólnego na różne biblioteki Ajaxa ;) Django lubi dziwne decyzje i “reinventing the wheel” ;)

  8. Avatar lopex said about 23 hours later:

    mogli by to podpiąć na http://gotapi.com/...

    >
  9. Avatar Marcin Kaszyński said 1 day later:

    Ejże, ten tekst Jacoba to styczeń 2006 :) W międzyczasie plany uległy zmianie i Django, przynajmniej na razie, nie będzie ułatwiać połączenia z żadną konkretną biblioteką JS.

    Tutaj można przeczytać bardziej aktualne wypowiedzi.

RSS feed for this post

(leave url/email »)

   Comment Markup Help Preview comment