Sposoby zapisywania danych modelu Backbone.js?

Question

Jestem bardziej zaawansowanym programistą i zacząłem ostatnio odkrywać Backbone.js w mojej aplikacji. Chcę utrwalić dane modelu na serwerze.

Proszę wyjaśnić mi różne sposoby zapisywania danych modelu (przy użyciu formatu json). Używam Java po stronie serwera. Również widziałem głównie REST używane do zapisywania danych. Jako, że jestem bardziej do przodu dev, nie jestem świadomy REST i innych podobnych rzeczy.

Byłoby świetnie, gdyby ktoś mógł wyjaśnić mi proces za pomocą prostego przykładu.

Answer 1

Zasadniczo modele mają właściwość o nazwie atrybuty, które są różnymi wartościami, jakie może posiadać określony model. Backbone używa obiektów JSON jako prostego sposobu wypełniania tych wartości przy użyciu różnych metod, które pobierają obiekty JSON. Przykład:

Donuts = Backbone.Model.extend({ 
    defaults: { 
     flavor: 'Boston Cream', // Some string 
     price: '0.50' // Dollars 
    } 
}); 

Aby zapełnić model, można to zrobić na kilka sposobów. Na przykład można skonfigurować instancję modelu, przekazując metodę JSON OR o nazwie set(), która przyjmuje obiekt JSON atrybutów.

myDonut = new Donut({'flavor':'lemon', 'price':'0.75'}); 
mySecondHelping = new Donut(); 
mySecondHelping.set({'flavor':'plain', 'price':'0.25'}); 

console.log(myDonut.toJSON()); 
// {'flavor':'lemon', 'price':'0.75'} 
console.log(mySecondHelping.toJSON()); 
// {'flavor':'plain', 'price':'0.25'} 

To prowadzi nas do zapisywania modeli i utrzymywania ich na serwerze. Istnieje cała masa szczegółów dotyczących "Co to jest REST/RESTful?" I trudno to wyjaśnić tutaj w krótkim blurbie. W szczególności w odniesieniu do REST i oszczędzania szkieletu, rzeczą, którą należy objąć, jest semantyka żądań HTTP i to, co robisz z danymi.

Prawdopodobnie przywykłeś do dwóch rodzajów żądań HTTP. GET i POST. W środowisku RESTful czasowniki te mają specjalne znaczenie dla konkretnych zastosowań, które zakłada szkielet. Aby uzyskać określony zasób z serwera (np. Ostatnio zapisany model pączka, wpis na blogu, specyfikację komputera) i ten zasób istnieje, należy wykonać żądanie GET. I odwrotnie, gdy chcesz utworzyć nowy zasób, używaj POST.

Zanim dostałem się do kręgosłupa, nigdy nawet nie dotknąłem dwóch metod żądania HTTP. PUT i DELETE. Te dwa czasowniki mają również specyficzne znaczenie dla kręgosłupa. Aby zaktualizować zasób (np. Zmienić smak cytrynowego pączka na pączek limon, itp.), Należy użyć żądania PUT. Jeśli chcesz usunąć ten model z serwera razem, użyjesz żądania DELETE.

Te podstawy są bardzo ważne, ponieważ w przypadku aplikacji RESTful prawdopodobnie będziesz mieć oznaczenie identyfikatora URI, które wykona odpowiednie zadanie w oparciu o rodzaj czasownika żądania, którego używasz. Na przykład:

// The URI pattern 
http://localhost:8888/donut/:id 

// My URI call 
http://localhost:8888/donut/17 

Jeśli zrobię dostać się do tego URI, byłoby uzyskać modelu pączek z identyfikatorze 17. id zależy od sposobu zapisywania stronie serwera. Może to być po prostu identyfikator twojego zasobu pączków w tabeli bazy danych.

Jeśli wykonam PUT do tego identyfikatora URI z nowymi danymi, będę go aktualizować, oszczędzając nad nim. A jeśli DELETE do tego URI, to oczyści go z mojego systemu.

Z POST, ponieważ nie utworzyłeś jeszcze zasobu, nie będzie on miał ustalonego identyfikatora zasobu. Być może docelowy URI, który chcę utworzyć zasoby, jest po prostu następujący:

http://localhost:8888/donut 

Brak fragmentu identyfikatora w URI. Wszystkie te projekty URI zależą od Ciebie i Twojego sposobu myślenia o zasobach.Ale jeśli chodzi o RESTful design, rozumiem, że chcesz zachować czasowniki swoich działań na żądanie HTTP i zasoby jako rzeczowniki, które sprawiają, że identyfikatory URI są czytelne i przyjazne dla ludzi.

Nadal jesteś ze mną? :-)

Wróćmy więc do myślenia o Kręgosłupie. Szkielet jest cudowny, ponieważ ma dla ciebie dużo pracy. Aby zapisać nasz pączek i sekundowanie, robimy to po prostu:

myDonut.save(); 
mySecondHelping.save(); 

Szkielet jest inteligentny. Jeśli właśnie utworzono zasób pączków, nie będzie on miał identyfikatora z serwera. Ma coś, co nazywa się cID, który jest wykorzystywany przez Backbone wewnętrznie, ale ponieważ nie ma oficjalnego identyfikatora, wie, że powinien utworzyć nowy zasób i wysyła żądanie POST. Jeśli masz model z serwera, prawdopodobnie będzie miał identyfikator, jeśli wszystko jest w porządku. W takim przypadku, gdy zapiszesz() Backbone zakłada, że ​​chcesz zaktualizować serwer, a on wyśle ​​PUT. Aby uzyskać określony zasób, należy użyć metody Backbone .fetch() i wysyła żądanie GET. Po wywołaniu .destroy() na modelu wyśle ​​polecenie DELETE.

W poprzednich przykładach nigdy nie powiedziałem wyraźnie, gdzie jest URI. Zróbmy to w następnym przykładzie.

thirdHelping = Backbone.Model.extend({ 
    url: 'donut' 
}); 
thirdHelping.set({id:15}); // Set the id attribute of model to 15 
thirdHelping.fetch(); // Backbone assumes this model exists on server as ID 15 

Backbone dostanie thirdHelping w http://localhost:8888/donut/15 Będzie po prostu dodać/pączka macierzystych katalogu głównym witryny.

Jeśli nadal jesteś ze mną, dobrze. Myślę. Chyba że jesteś zdezorientowany. Ale i tak będziemy brnąć. Druga część to strona SERVER. Rozmawialiśmy o różnych czasownikach HTTP i semantycznych znaczeniach tych czasowników. Znaczenia, które Ty, Szkielet i Twój serwer muszą udostępniać.

Twój serwer musi zrozumieć różnicę między żądaniem GET, POST, PUT i DELETE. Jak widzieliście w powyższych przykładach, GET, PUT i DELETE mogą wskazywać na ten sam identyfikator URI http://localhost:8888/donut/07 Jeśli twój serwer nie rozróżnia tych żądań HTTP, będzie to bardzo mylące co do tego, co zrobić z tym zasobem.

To jest, gdy zaczynasz myśleć o swoim kodzie zakończenia serwera RESTful. Niektórzy ludzie lubią Ruby, niektórzy lubią .net, lubię PHP. Szczególnie lubię mikro-framework SLIM PHP. SLIM PHP to mikro-framework, który ma bardzo elegancki i prosty zestaw narzędzi do radzenia sobie z działaniami RESTful. Możesz definiować trasy (URI), jak w przykładach powyżej iw zależności od tego, czy wywołanie jest GET, POST, PUT, czy DELETE, wykona właściwy kod. Istnieją inne rozwiązania podobne do SLIM jak Recess, Tonic. Wierzę, że większe struktury takie jak Cake i CodeIgniter również robią podobne rzeczy, chociaż lubię minimalne. Czy mówię, że lubię Slim? ;-)

To właśnie może wyglądać fragment kodu na serwerze (czyli specjalnie dotyczące tras.)

$app->get('/donut/:id', function($id) use ($app) { 
    // get donut model with id of $id from database. 
    $donut = ... 

    // Looks something like this maybe: 
    // $donut = array('id'=>7, 'flavor'=>'chocolate', 'price'=>'1.00') 

    $response = $app->response(); 
    $response['Content-Type'] = 'application/json'; 
    $response->body(json_encode($donut)); 
}); 

Tutaj ważne jest, aby pamiętać, że Backbone oczekuje obiekt JSON. Serwer zawsze powinien określać typ zawartości jako "application/json" i kodować go w formacie json, jeśli możesz. Wtedy, gdy Backbone odbierze obiekt JSON, wie, w jaki sposób zapełnić model, który o to poprosił.

Z SLIM PHP, trasy działają dość podobnie do powyższych.

$app->post('/donut', function() use ($app) { 
    // Code to create new donut 
    // Returns a full donut resource with ID 
}); 
$app->put('/donut/:id', function($id) use ($app) { 
    // Code to update donut with id, $id 
    $response = $app->response(); 
    $response->status(200); // OK! 
    // But you can send back other status like 400 which can trigger an error callback. 
}); 
$app->delete('/donut/:id', function($id) use ($app) { 
    // Code to delete donut with id, $id 
    // Bye bye resource 
}); 

Tak, prawie wykonałeś całą podróż w obie strony! Idź po napój gazowany. Lubię Diet Mountain Dew. Zyskaj też dla mnie.

Gdy twój serwer przetworzy żądanie, zrobi coś z bazą danych i zasobem, przygotuje odpowiedź (bez względu na to, czy jest to prosty numer statusu http, czy pełny zasób JSON), dane wracają do szkieletu w celu ostatecznego przetworzenia.

Za pomocą metod save(), fetch(), itp. - możesz dodać opcjonalne callbacki dotyczące sukcesu i błędu. Oto przykład, jak ustawić to konkretne ciasto:

Cake = Backbone.Model.extend({ 
    defaults: { 
     type: 'plain', 
     nuts: false 
    }, 
    url: 'cake' 
}); 

myCake = new Cake(); 
myCake.toJSON() // Shows us that it is a plain cake without nuts 

myCake.save({type:'coconut', nuts:true}, { 
    wait:true, 
    success:function(model, response) { 
     console.log('Successfully saved!'); 
    }, 
    error: function(model, error) { 
     console.log(model.toJSON()); 
     console.log('error.responseText'); 
    } 
}); 

// ASSUME my server is set up to respond with a status(403) 
// ASSUME my server responds with string payload saying 'we don't like nuts' 

Jest kilka różnych rzeczy na ten przykład, że. Zobaczysz to dla mojego ciasta, zamiast ustawiania atrybutów przed zapisaniem, po prostu przekazałem nowe atrybuty do mojego wezwania do zapisania. Backbone to całkiem niezły ninja, który zbiera dane JSON w każdym miejscu i obsługuje je jak mistrz. Więc chcę uratować moje ciasto orzechami kokosowymi i orzechami kokosowymi. (Czy to 2 orzechy?) W każdym razie, przekazałem dwa obiekty do mojego składowania. Atrybut JSON object AND some options. Pierwsze, {wait: true} oznacza, że ​​nie aktualizuje mojego modelu po stronie klienta do momentu pomyślnego zakończenia podróży po stronie serwera. Odwołanie od powodzenia nastąpi, gdy serwer zwróci odpowiedź. Ponieważ jednak ten przykład powoduje błąd (status inny niż 200 będzie wskazywał Backbone, aby użyć wywołania błędu), otrzymamy reprezentację modelu bez zmian. Powinien być nadal prosty i bez orzechów. Mamy również dostęp do obiektu błędu, który odesłał serwer. Wysłaliśmy ciąg znaków, ale może to być obiekt błędu JSON z większą ilością właściwości. Znajduje się w argumencie error.responseText. Tak, "nie lubimy orzechów".

Gratulacje. Zrobiłeś swoją pierwszą, całkiem pełną, okrągłą wycieczkę po skonfigurowaniu modelu, zapisując go po stronie serwera iz powrotem. Mam nadzieję, że ta epicka odpowiedź da ci wyobrażenie o tym, jak to wszystko się łączy. Istnieje oczywiście wiele szczegółów, które przechodzę obok, ale podstawowe pomysły dotyczące Ratowania kręgosłupa, RESTful czasowników, akcji po stronie serwera, odpowiedzi są tutaj. Przechowuj dokumentację Backbone (która jest bardzo łatwa do odczytania w porównaniu z innymi dokumentami), ale pamiętaj, że poświęcenie czasu na to wymaga czasu. Im więcej w nim będziesz, tym bardziej będziesz płynny. Każdego dnia uczę się czegoś nowego z kręgosłupem i robi się naprawdę fajnie, gdy zaczynasz robić skoki i widzisz swoją płynność w tych ramach. :-)

Szczęśliwe kodowanie!

EDIT: zasoby, które mogą być użyteczne:

innych podobnych odpowiedzi na SO: How to generate model IDs with Backbone

na odpoczynek: http://rest.elkstein.org/ http://www.infoq.com/articles/rest-introduction http://www.recessframework.org/page/towards-restful-php-5-basic-tips