Krzysztof Suszyński

Krzysztof Suszyński Chief Programmer
(Java & Puppet)

Temat: Aptana Jaxer

Hej. Mam pytanie. Czy ktoś próbował coś robić testowo z tym serwerem (Jaxer). Z jakim skutkiem?

Ja sam robiłem przymiarki w pierwszej publicznej wersji i wyglądało to całkiem obiecująco.
Paweł Knapik

Paweł Knapik Front-End Developer

Temat: Aptana Jaxer

Chwilę się bawiłem, bo JS po stronie serwera to jeden z moich ulubionych tematów. Fajne jest to, że dzięki oparciu o silnik Mozilli udostępnia wszelkie dobrodziejstwa, które pojawiły się w nowszych wersjach Gecko (m.in. E4X), a także nadaje się do zabawy z HTML DOM. Nie miałem jednak okazji zrobienia czegoś poważniejszego, choć chciałbym mieć (i w końcu znajdę ;)).

Jeśli server-side JavaScript Cię interesjue, to jest kilka innych projektów, umożliwiających takie zabawy: http://en.wikipedia.org/wiki/Server-side_JavaScript (z wymienionych tam próbowałem jedynie frameworku Helma).
Zbigniew Matuszewski

Zbigniew Matuszewski Programista
aplikacji webowych

Temat: Aptana Jaxer

Ja ostatnio się tym bawię.

Ma on kilka wad, między innymi:
- brak wypracowanego do końca sensownego sposobu podziału kodu (a to niezbędne przy dużych aplikacjach), trudno zrealizować standardowe MVC
- brak szablonowania (trzeba się podeprzeć jakąś biblioteką, np. Dojo - Dijit, by to zrealizować)
- wymóg pisania warstwy proxy dla wywołań AJAX, nie można więc napisać sobie zestawu obiektów server side realizujących warstwy modelu i kontrolera, razem z dziedziczeniem (co pozwoliłoby chociażby łatwo zbudować funkcjonalność typu CRUD uogólnioną, a potem jej używać dla różnych klas mapujących tabele z bazy), w ogóle trzeba napisać funkcje proxy dla wywołań AJAX w sposób czysto funkcyjny, bez obiektów. Można zrobić sobie warstwy i dziedziczenie po stronie serwera, ale obiekty nie będą widoczne z poziomu wywołań proxy, nie zostaną cache'owane tak dzieje się to z funkcjami (ale też tylko tym implicite w blokach proxy i server, czyli w rodzaju function x () {...} a nie var x = function () {...} ).

Ma też kilka zalet, między innymi:
- możliwość wykorzystania ulubionych bibliotek JS (np. jQuery, MooTools, Dojo itp.) server side - dosyć potężna rzecz
- mamy całą strukturę DOM serwowanych dokumentów server side jak na dłoni i można z nim robić dowolne rzeczy w prosty sposób
- to co wyżej można też zrobić z pobraną zawartością z zewnątrz przez połączenie HTTP z serwera
- można tego samego kodu użyć server side i client side (np. do walidacji formularza - nie trzeba pisać dwa razy)
- serwer i przeglądarka mówią tym samym językiem (mam na myśli natywne wsparcie dla JSON, w dodatku można funkcje poziomu proxy wywoływać client side, jak normalne funkcje JS, a zostaną wykonane po stronie serwera i zwrócą wynik - w sposób przeźroczysty dla programisty, nie trzeba się bawić w pisanie kodu łączącego)

Obecnie staram się zrobić sobie prostą bazę kodową, która wyeliminuje najważniejsze wady przy pozostawieniu zalet (szczególnie pierwszą oraz ostatnią wadę z wyżej wymienionych - szablonowanie tak mnie nie boli, bo i tak zamierzam tego używać tylko w połączeniu z EXT JS i przy pisaniu całkiem AJAXowych aplikacji, jeśli w ogóle).

Zobaczymy co z tego wyniknie. Pomysł jak to zrobić mam, obawiam się tylko o wydajność - że nie będzie to działało na tyle szybko, by używać tego w naprawdę poważnych i dużych aplikacjach (obecnie piszę na tym aplikację której będzie używało tylko kilka osób, więc nie będzie bardzo obciążana, mogę więc przy okazji poeksperymentować).

Następna dyskusja:

Aptana Pro




Wyślij zaproszenie do