Jest ktoś chętny aby przybliżyć teorie i o co dokładnie chodzi w zasobach . Bawiłem się już nimi w sumie ale nie miałęm skąd zaczaic jakie to ma podstawy teoretyczne w Frameworku. No i do czego innego niz fajnego obudowywania linków może to służyć
Moze jeszcze sluzyc do tego aby zajebiscie skomplikowac kod tych linkow (np zajebisty samowysylajacy sie formularz w javascript do tego aby zrobic POST /moj_fajny_zasob/69/delete) Ciekawe ile to by bylo terabajtow dziennie gdyby tak google przepisala gmail na rest, albo yahoo swoja strone. Bzzzzzzzzzduuuuuuuura Wesolych Swiat
Dzięki za rzeczową odpowiedz. Wesołych świąt.
Znalazłem jeszcze jedeną prezentację o REST
@PaK http://code.google.com/apis/opensocial/docs/dataapis.html
Witam,
PaK: chyba trochę przesadzasz Sam mam mieszane uczucia co do RESTa, ale idea zaczyna mi się powoli podobać. Spójrz na to w inny sposób - generowanie tej formy jest tak samo kiepskim pomysłem jak generowanie kodu do requestów ajaxowych (no… może trochę bardziej kiepskim, bo kodu jest więcej). Napisałem o tym dzisiaj na blogu: http://blog.drogomir.com/articles/2007/12/25/nieinwazyjny-javascript-razem-z-ruby-on-rails . Psiocząc na takie generowanie powinieneś też psioczyć na resztę helperów W obecnie pisanej aplikacji używam jQuery, co implikuje nieużywanie helperów javascriptowych i moim zdaniem kod jest dużo bardziej przejrzysty.
Pozostaje jeszcze kwestia konieczności załadowania javascriptu, żeby link do destroy działał. Jest to pewne utrudnienie, ale moim zdaniem request o skasowanie czegokolwiek powinien być wysyłany POSTem i mieć jakiegoś rodzaju potwierdzenie. Na railscastach był kiedyś filmik o destroy bez javascriptu: http://railscasts.com/episodes/77 . Imho rozwiązanie takie ma więcej plusów niż minusów, a jeżeli zastosujemy nieinwazyjny javascript wystarczy napisać jedną funkcję, która będzie się aplikowała do każdego linka z klasą na przykład “destroy” i voilla - proste szybkie i przyjemne.
Pozdrawiam
[quote=drogus]Witam,
PaK: chyba trochę przesadzasz Sam mam mieszane uczucia co do RESTa, ale idea zaczyna mi się powoli podobać. Spójrz na to w inny sposób - generowanie tej formy jest tak samo kiepskim pomysłem jak generowanie kodu do requestów ajaxowych (no… może trochę bardziej kiepskim, bo kodu jest więcej). Napisałem o tym dzisiaj na blogu: http://blog.drogomir.com/articles/2007/12/25/nieinwazyjny-javascript-razem-z-ruby-on-rails . Psiocząc na takie generowanie powinieneś też psioczyć na resztę helperów W obecnie pisanej aplikacji używam jQuery, co implikuje nieużywanie helperów javascriptowych i moim zdaniem kod jest dużo bardziej przejrzysty.[/quote]
Tyle tylko ze ajaxowych helperow uzywasz wtedy gdy ich potrzebujesz, emulacji PUT i DELETE uzywasz WSZEDZIE, gdy tylko przechozisz na rails 2.0 i REST. Wiem ze narzekam Wesolych Swiat
Ale przecież PUT i tak jest przy edycji tylko, więc jest to kwestia dodania jednego dodatkowego pola - nieduża zmiana
A DELETE tak jak pisałem - moim zdaniem i tak powinno się request o skasowanie wysyłać POSTem.
Co do narzekania. Oczywiście zgadzam się z tym, że emulowanie DELETE i PUT nie jest najładniejszym rozwiązaniem, ale nic przecież nie jest idealne Jestem w stanie wybaczyć tą drobnostkę i używając “unobtrusive javascript” nie komplikuje to wcale kodu.
Wesołych Świąt
(mam nadzieję, że nie doczekam czasów kiedy w polszy będę musiał mówić wesołych wakacji )