O co dokładnie chodzi w Zasobach

Jest ktoś chętny aby przybliżyć teorie i o co dokładnie chodzi w zasobach :slight_smile: . 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 :wink: Wesolych Swiat

Dzięki za rzeczową odpowiedz. Wesołych świąt.

W celu zapoznania się z ideą REST w RoR polecam prezentację DHH z RailsConf 2006

Znalazłem jeszcze jedeną prezentację o REST

@PaK http://code.google.com/apis/opensocial/docs/dataapis.html

Witam,

PaK: chyba trochę przesadzasz :wink: 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 :wink: 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 :wink: 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 :wink: 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 :slight_smile: Wesolych Swiat :slight_smile:

Ale przecież PUT i tak jest przy edycji tylko, więc jest to kwestia dodania jednego dodatkowego pola - nieduża zmiana :wink:

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 :wink: Jestem w stanie wybaczyć tą drobnostkę i używając “unobtrusive javascript” nie komplikuje to wcale kodu.

Wesołych Świąt :slight_smile:

(mam nadzieję, że nie doczekam czasów kiedy w polszy będę musiał mówić wesołych wakacji :smiley: )