Mam zamiar uaktualnić sobie nieco aplikację Repo (przy okazji podszlifuję znajomość jednego czy dwóch frameworków), a przy okazji chciałbym zaimplementować jakieś standardowe API blogowe (nie wiem jeszcze jak działają, liczę na coś ze świata webservice, ale tego się dowiem).
No i tutaj mam pytanie techniczne. Pytanie do blogujących. Jakie API warto implementować? Co ma najszersze wsparcie? MovableType? Blogger? Coś innego?
...no i może od razu zmieniłbym look. Na jakiś jaśniejszy. Bardziej kolorowy. I pastelowy. Jak nowy Jogger ;)
Dopiski:
Od: lanrat
Data: 20070508, 14:55
Czyli jednak w stylu web 2.0 :-)
Od: Aniołek
Data: 20070508, 15:21
(jęk) tylko nie jak nowy jogger...
Od: yoshi314
Data: 20070508, 19:22
atom api podobno ma przyszlosc ale jest najbardziej pokrecone (i elastyczne). probowalem je niedawno implementowac w c++ ale chwilowo sie poddalem :D
z kolei moveable type jest jednym z najbardziej rozbudowanych.
a najprostsze, wrecz banalne api mial drupal 4.x, ale jego metody zniknely w 5.x :(
api blogowe dzialaja na mechanizmie xmlrpc, czyli przesylania zapytan xml poprzez transport html.
Od: Hoppke
Data: 20070509, 15:02
Atom wygląda fajnie, bo jeśli dobrze rozumiem, to sensownie używa HTTP. Każdy wpis/komentarz/whatever jest mapowany na jakiś specjalny, unikatowy URL i robi się na nim POST, PUT, GET, DELETE - i to decyduje o czynności. Tak to działa?
No i klient może przez introspekcję wybadać jakie usługi są dostępne. Zastanawiam się, czy można dodać własną usługę i w jakiś sposób przekazać klientowi wszystkie dane potrzebne do jej wykorzystania?
Minus jest taki, że to draft. Nie wiem nawet na ile sensowny, bo jeszcze nie czytałem. I nie wiem co z programami do blogowania - nie wiem czy wspierają Atom API, czy to jest dość popularne.
Od: bies
Data: 20070509, 15:06
Jak już zmieniasz GUI to użyj AJAX-a (w Javie polecam GWT).
A co do popularności -- mój test wyglądał następująco: Google Reader -> Browse -> pierwszy na liście service jest Blogger (tak, znam alfabet ;) ).
Od: Hoppke
Data: 20070509, 17:27
Na razie dla AJAX-a widzę tu tylko jedno zastosowanie - dodawanie komentarzy. Co fajnego by można tu jeszcze na tym oprzeć?
...a od GWT jakoś staram się trzymać z daleka, bo do prostych rzeczy jest chyba zbyt złożone(?)... przynajmniej takie wrażenie mam, może mylne.
Od: bies
Data: 20070509, 23:31
Co do AJAX-a: a ile masz linków na stronie. To wszystko mogłoby działać u klienta wymieniając z serwerem tylko dane. Myślisz jeszcze o aplikacji AJAX jak o webowej. Tymczasem jest to aplikacja standalone która pobiera tylko dane przez jakiś interfejs RPC. Tak naprawdę, to zamiast serwera web mógłbyś dane zaciągać np. wywołaniami CORBA opakowanymi w http. Po prostu do AJAX-a trzeba się przestawić.
Co do GWT: też tak myślałem (23MB archiwum, zanurzona mozilla, własny kompilator, generatory skryptów) ale po przeczytaniu wprowadzenia na stronie projektu i zbudowaniu prostego przykładu uznałem, że to jest świetny projekt. W Javie już nie chce mi się używać niczego innego.
Od: Aniołek
Data: 20070510, 00:34
Bies: CORBA? Z własnej woli i to w tak malutkim projekciku jak własny blog? Ty mówisz poważnie czy sobie tak perfidnie żartujesz i chcesz wpuścić Hoppke w bagienko, a potem patrzeć i się śmiać? ;)
Od: bies
Data: 20070510, 01:29
Nie, ta CORBA to był tylko przykład, na to, że aplikacja AJAX to pełnowartościowy program pracujący u klienta. I, że tak naprawdę to można serwer web zamienić (w mniej lub bardziej prosty sposób) na coś innego. Na pewno nie proponuję mu CORBA do bloga.
Z resztą CORBA święci tryumfy w przypadku łączenia różnych technologii. Akurat zajmuję się teraz aplikacją (pisaną rzeczywiście w GWT) która do servletu gada po googlowym RPC ale już dalej. Tj. do usług Win32 dających np. autoryzację i uwierzytelnianie lub dane, gada po CORBA.
Od: Aniołek
Data: 20070510, 09:36
To, że coś można zrobić (np. serwer web zamienić na corbę) nie zawsze znaczy, że warto to robić ;) Szczególnie w informatyce jest to prawdziwe - najczęściej najprostsze (co nie znaczy: prostackie) rozwiązania są najlepsze, choćby dlatego, że najlepiej utrzymywalne.
I chociaż oczywistym jest CORBA ma swoje miejsce w świecie ;), to im dłużej ja do niego nie trafię, tym bardziej się cieszę ;) Tym bardziej, że w większości przypadków to byłby jednak niezły overkill brać CORBĘ... W ogóle jakoś tak mam duży dystans do wszystkich tych rozwiązań "enterprisey" (CORBA, EJB, jakies sunowskie tzw. standardy). Jasne, są miejsca, gdzie bez nich ani rusz, ale mam wrażenie, że podejrzanie często ludzie stosują je nie dlatego, że sprawdzą się najlepiej, tylko dlatego, że to już umieją i jakoś tak hurtem idzie... Ja zdecydowanie wolę lekkie frameworki (choć naturalnie nie wszędzie da się je zastosować, ale całe szczęście akurat w tym co robię się daje).
Od: Hoppke
Data: 20070510, 20:07
@bies: ale jakie konkretne korzyści dałoby mi zrobienie na Repo treści wkładanej na stronę AJAX-em? I czy równoważyłoby nakład pracy jaki byłby potrzebny żeby zapewnić działanie na większości przeglądarek, zachowanie działania przycisku "back" i permalinków, że wymienię tylko kilka rzeczy?
Oczywiście, że myślę o AJAX-ie tylko jako wspomagaczu dla webu. Repo jest blogiem i nie ma po co oddzielać go na siłę od sieci. Skoro przeglądarki mogą wykonywać przy nawigowaniu po Repo dużą część roboty, to po co je wyręczać i przepisywać to w AJAX-ie? Jaką funkcjonalność bym uzyskał? Serio pytam.
A CORBA... patrzę na nią trochę jak na EJB. Takie bydlę enterprajsowe. Czasem jest niezbędne, ale jeśli możesz zrobić coś lżejszymi technologiami, to nie ma co się zastanawiać. CORBA ma straszny overhead implementacyjny i przy małych problemach po prostu nie opłaca się jej stosować.
Staram się dobierać narzędzia stosownie do zadania i tyle.
Aha, GWT mi się nie przyda, bo przecież mam bloga, a nie Google Spreadsheets :) Gdybym już chciał jakiegoś toolkitu na Repo użyć, to pewnie wziąłbym coś prostszego, np. framework ZK. O niebo ładniej integruje się z kodem Javy, generuje lżejszy kod i nie wymaga kompilowania stron.
Jest takie fajne motto Einsteina, o dążeniu do prostoty (ale bez przeginania :)
Od: bies
Data: 20070510, 21:59
AJAX: mniejsze obciążenie serwera (bo więcej u klienta), mniejsze ssanie pasma (bo JavaScript się świetnie cache'uje u klienta). No i byłbyś bardziej dżezi i Web 2.0. ;) Pewnie masz rację, że nakład pracy w porównaniu do rozwiązania bardzo prostego byłby większy. Ale u licha, takie projekty robi się tak aby optymalizować frajdę a nie minimalizować pracę. ;) (Właśnie zjadłem kolację pałeczkami, pewnie widelcem byłoby szybciej.)
CORBA: wbrew pozorom narzut nie jest taki duży. Ale CORBA do drobiazgów rzeczywiście jest zbędna.
ZK: jak na ,,#1 Ajax project in SourceForge.net'' to zbyt dużo nie działa w ,,Live Demo'' w Kazehakase z najnowszym Gecko. Poza tym w porównaniu do łatwości testowania GWT w Hosted Mode -- nie, dzięki.
Od: Hoppke
Data: 20070511, 11:14
Na Repo AJAX nie zmniejszy obciążenia, bo po stronie serwera nie jest liczone nic, co dałoby się wypchnąć do klienta.
Cachowanie JS pozwala zmniejszyć transfer danych, których bez JS nie trzebaby transferować :)
A treść serwowana AJAX-em nie cachuje się już za dobrze i trzeba się namęczyć żeby np. googiel poprawnie zindeksował całego bloga.
Nawet dla frajdy nie będę robił niczego, co nie ma sensu :) Bo aż tyle czasu nie mam. Jeśli mam coś zoptymalizować, to chcę by to było użyteczne.
GWT odpada, bo wspiera przeglądarki tak samo jak Google (np. GWT w Operze opisują jako "works, mostly"). ZK odpada, bo jest zbyt proste.
Naprawdę nie jestem zainteresowany robieniem demo możliwości AJAX-a. Chcę jedynie wprowadzić w paru miejscach więcej dynamiki, takiej która będzie miała naprawdę sens. Chciałbym np. zrobić AJAX-owe wstawianie komentarzy, bo bez reloadu łatwiej jest zabezpieczyć się przed podwójnym submitem i "user experience" się poprawia. Mógłbym zrobić AJAX-ową przeszukiwarkę Repo. Takie rzeczy mnie interesują, konkretne korzyści, które jakoś zwiększają funkcjonalność albo odporność aplikacji na problemy z przeglądarkami.
Od: lanrat
Data: 20070511, 11:53
Trochę naciągane te pomysły na AJAX IMHO.
W końcu do ostatnich wpisów masz max 13 komentarzy - no teraz 14 :-).
Przeszukiwarka AJAXowa? Ale w przeszukiwarkach zwykle 90% treści jest ładowanych przy każdym wyszukaniu więc gdzie tu korzyść (bo chyba nie to że nie będzie przeładowywać nagłówka i formularza wyszukiwania)? Chyba, żeby przeszukiwarka była gdzieś "z boku" zintegrowana na każdej podstronie ale to kosmiczny pomysł.
Raczej już bym widział np. wyświetlanie na głównej stronie czegoś "przewijanego" automatycznie przez AJAX np. ostatnie zapytanie z googli, które doprowadziło do repo itp.
Od: dl
Data: 20070511, 12:00
> AJAX: mniejsze obciążenie serwera (bo więcej u klienta)
Gratuluję podejścia. Pewnie dlatego coraz częściej się spotyka mułowate strony przeładowane ajaxem...
Od: bies
Data: 20070511, 12:16
@Hoppke: cóż, jak nie to nie. ;D
dl: Pewnie tak. I będzie ich się spotykać coraz więcej. Z drugiej strony postęp w maszynach wirtualnych JavaScriptu w przeglądarkach też będzie (jest) zauważalny. I nie chodzi tylko pełne implementacje standardów ale również o takie rzeczy jak JIT. Biznes od dawna działa za pomocą cienkich klientów -- rozwiązania AJAX-owe to oczywisty, następny krok. To już się dzieje. Prywatne strony -- jest tak jak piszesz -- jest ich coraz więcej.
Od: Aniołek
Data: 20070511, 13:12
Bies: AJAX jest - moim bardzo skromnym zdaniem - mocno przereklamowany i mam nadzieję, że prędzej czy później dotrze do ludzi, że nie jest panaceum na każdą bolączkę. Krokiem w dobrą stronę jest przeniesienie się na przeglądarki zamiast budować aplikacje desktopowe, bo po 1) klient ma do nich dostęp praktycznie wszędzie, a po 2) odchodzi problem aktualizacji i czy pani Kasia w sekretariacie na pewno będzie umiała/pamiętała się zupdejtować jak wyjdzie jakiś bugfix. Tyle, że AJAX to jednak wciąż tylko JS i CSS i te technologie do wyuzdanych zastosowań projektowane nie były - tego się nie przeskoczy. Tym bardziej staje się to wszystko problematyczne, kiedy przypomnisz sobie, że każdy z trójcy IE/FF/Opera ma swoje pomysły, "standard" jest tylko miło brzmiącym słowem, o przeglądarkach jeszcze bardziej niszowych nie wspominając. Cała idea "przenośności" bierze momentalnie w łeb, kiedy chcesz zrobić coś bardziej wyuzdanego - i google jest tu najlepszym przykładem. Owszem, ich gmail chodzi (w miaaarę) praktycznie wszędzie, ale już taki calendar czy "office" to bida z nędzą, jak nie używasz FF albo IE. Że nie wspomnę o tym, że nawet pod FF wciąż widać, że to jest aplikacja webowa i daleko jej z funkcjonalnością do normalnego office'a.
Moim cichym marzeniem jest, żeby z większym zainteresowaniem i popularnością spotkały się *dedykowane* rozwiązania do pisania tego typu rzeczy na web - choćby w postaci Flexa. O ile koszmarnie mnie irytują strony, w których Flash jest wykorzystany do zrobienia bajeranckiego menu (bo to spokojnie własnie można zrobić - o ironio - w AJAXie), o tyle do rzeczywiście coolerskich, bogatych i user friendly, aplikacji, moim zdaniem jest bezkonkurencyjny. Po pierwsze, w AJAXie nigdy nie jesteś w stanie uzyskac w takim samym czasie porównywalnej przenośności między przeglądarkami z zachowaniem *identycznego* zachowania, na dodatek możliwości Flexa są dużo bogatsze, a wreszcie last - but not least - paradoksalnie rozwiązania flashowe mogą być dużo lżejsze, niż przepakowany hackami AJAX.
Oczywiście, AJAX ma swoje miejsce, ale akurat dla mnie niekoniecznie w dziedzinie pisania aplikacji RIA (z dużym naciskiem na R).
Od: bies
Data: 20070512, 16:18
Aniołku, czytujesz może blog Bruce'a Eckela? ;) Prawda, flash dzięki ,,one plugin to rule them all'' zapewnia kompatybilność lepszą niż kilka różnych silników HTML. Ale czy w końcu nie doprowadziłby do ,,and in the darkness bind them''? Nie wiem. Z drugiej strony smutna prawda jest taka, że na razie rynek to MSHTML i Gecko. A Opera i KHTML/WebCore muszą jeszcze o rynek walczyć (o innych silnikach nawet nie wspominam).
Pamiętaj też, że trwa proces łączenia silnika JS z Gecko z silnikiem AS z Flasha (słowa do google: Tamarin, Spidermonkey, AVM2). Co do tego, że JS nie był stworzony do RIA: to normalna kolej rzeczy dla elastycznych technologii -- Java była stworzona do appletów i pralek, Flash do bannerów.
Od: Aniołek
Data: 20070512, 17:24
Nie, nie czytuję Eckela. Znam po prostu jednego ewangelistę Flexowego ;) który pokazał mi, co na tym można zrobić. I chociaż jego zapał i teksty z gatunku "ajax is history" są dla mnie przesadą, to jednak w pewnych bardzo konkretnych zastosowaniach ma rację, że nie ma nic lepszego.
Piszesz o smutnej prawdzie - cóż, z podejściem "smutna prawda jest taka" to nigdy się nie zmieni, a właśnie flashowe rozwiązania dałyby wreszcie rzeczywiście swobodny wybór, a nie wieczne "używam FF chociaż wolałabym operę, bo tylko na tym chodzą strony, których chcę używać".
Różnica między javą i flashem a JS jest taka, że przy javie/flashu jedna organizacja podejmuje decyzję "zmieniamy to i to" i to działa. W JS taką samą decyzję musi podjąć X implementatorów przeglądarek. I dlatego działa to jak działa - java i flash są rzeczywiście elastyczne, a JS i CSS - nie bardzo.
Od: bies
Data: 20070512, 23:16
Nie, między Javą a Flashem jest kolosalna różnica w modelu rozwoju. Znasz odpowiednik JCP/JSR dla Flasha?
JS nie elastyczny, prosty język skryptowy w którym można napisać jakoś działający (Google D&S) arkusz kalkulacyjny?!
Od: Aniołek
Data: 20070513, 10:02
Nie twierdzę, że modele rozwoju javy i flasha są identyczne. Twierdzę tylko, że ich modele rozwoju (jakkolwiek różne od siebie) są dużo elastyczniejsze, a przede wszystkim, bardziej stabilne i przewidywalne, niż model rozwoju (o ile można o jakimkolwiek mówić) JS.
I tak, mimo że w JS google napisał, nazwijmy to szumnie, arkusz kalkulacyjny, to arkusz ten działa, przepraszam za słowo, kompletnie z dupy w przeglądarkach != IE/FF. Z tego powodu - jak dla mnie - tak średnio z tą elastycznością JS jako takiego. Elastyczność, która polega na tym, że muszę zmienić przeglądarkę, nie jest dla mnie żadną elastycznością :]
Poza tym jak ten googlowy arkusz będzie się zachowywał tak, jak sam Excel, to wtedy pogadamy ;))) Bo jak na razie mam wrażenie (może mylne), że oni właśnie uderzyli o ścianę, co się da zrobić w JS/CSS, a czego już nie.