Backbone.js model verilerini kaydetmenin yolları?

Ön uç geliştirmeyle daha çok ilgileniyorum ve son zamanlarda Backbone.js'yi uygulamamda keşfetmeye başladım. Model verilerini sunucuda kalıcı hale getirmek istiyorum.

Model verilerini kaydetmenin çeşitli yollarını (json formatını kullanarak) açıklar mısınız? Java'yı sunucu tarafında kullanıyorum. Ayrıca verileri kaydetmek için REST'in kullanıldığını gördüm. Ön uç geliştirmeye daha çok girdiğim için, REST ve diğer benzer şeylerin farkında değilim.

Birisi bana süreci basit bir örnekle açıklayabilirse harika olur.

Temel olarak Modeller, belirli bir modelin sahip olabileceği çeşitli değerler olan nitelikler adı verilen bir özelliğe sahiptir. Backbone, JSON nesnelerini alan çeşitli yöntemler kullanarak bu değerleri doldurmanın basit bir yolu olarak JSON nesnelerini kullanır. Misal:

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

Modeli doldurmak için bunu yapmanın birkaç yolu vardır. Örneğin, bir JSON nesnesini ileterek VEYA JSON öznitelik nesnesini alan set () adlı yöntemi kullanarak model örneğinizi kurabilirsiniz.

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'}

Bu da bizi modelleri kaydetmeye ve onları bir sunucuda sürdürmeye götürüyor. "REST / RESTful nedir?" İle ilgili bir sürü ayrıntı var. Ve tüm bunları burada kısa bir özetle açıklamak biraz zor. Özellikle REST ve Omurga kaydetme ile ilgili olarak, kafanızı sarmanız gereken şey, HTTP isteklerinin anlamsallığı ve verilerinizle ne yaptığınızdır.

Muhtemelen iki tür HTTP isteğine alışkınsınız. GET ve POST. RESTful bir ortamda, bu fiiller Backbone'un varsaydığı belirli kullanımlar için özel anlamlara sahiptir. Sunucudan belirli bir kaynağı (ör. Son kaydettiğim halka modeli, bir blog girişi, bir bilgisayar özelliği) almak istediğinizde ve bu kaynak varsa, bir GET isteği yaparsınız. Tersine, yeni bir kaynak oluşturmak istediğinizde POST kullanırsınız.

Backbone'a girmeden önce, aşağıdaki iki HTTP istek yöntemine hiç dokunmadım bile. PUT ve DELETE. Bu iki fiilin ayrıca Omurga için özel bir anlamı vardır. Bir kaynağı güncellemek istediğinizde (ör. Limonlu çörek aromasını limonlu çörek olarak değiştirin, vb.) Bir PUT isteği kullanırsınız. Bu modeli sunucudan hep birlikte silmek istediğinizde, bir DELETE isteği kullanırsınız.

Bu temel bilgiler çok önemlidir çünkü RESTful uygulamanızla, muhtemelen kullandığınız istek fiilinin türüne göre uygun görevi yerine getirecek bir URI atamasına sahip olacaksınız. Örneğin:

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

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

Bu URI'ye bir GET yaparsam, 17 kimliğine sahip halka modeli alırdı.: İd, onu sunucu tarafında nasıl kaydettiğinize bağlıdır. Bu yalnızca, veritabanı tablonuzdaki halka kaynağınızın kimliği olabilir.

Bu URI'ye yeni verilerle bir PUT yaparsam, onu günceller ve üzerine kaydederim. Ve eğer bu URI'ye SİLERSEM, onu sistemimden temizler.

POST ile, henüz bir kaynak oluşturmadığınız için, yerleşik bir kaynak kimliğine sahip olmayacaktır. Belki de kaynakları oluşturmak istediğim URI hedefi basitçe şudur:

http://localhost:8888/donut

URI'de kimlik parçası yok. Tüm bu URI tasarımları size ve kaynaklarınız hakkında ne düşündüğünüze bağlıdır. Ancak RESTful tasarımla ilgili olarak, benim anlayışım, eylemlerinizin fiillerini HTTP isteğinize ve kaynakları, URI'leri okumayı kolaylaştıran ve insan dostu yapan isimler olarak tutmak istediğinizdir.

Hala benimle misin? :-)

O halde Backbone hakkında düşünmeye geri dönelim. Omurga harika çünkü sizin için çok iş yapıyor. Çörekimizi ve secondHelping'imizi kurtarmak için, basitçe şunu yapıyoruz:

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

Omurga akıllıdır. Bir halka kaynağı oluşturduysanız, sunucudan bir kimliği olmayacaktır. Backbone'un dahili olarak kullandığı cID adı verilen bir şeye sahiptir, ancak resmi bir kimliği olmadığı için yeni bir kaynak oluşturması gerektiğini bilir ve bir POST isteği gönderir. Modelinizi sunucudan aldıysanız, her şey yolundaysa muhtemelen bir kimliği olacaktır. Bu durumda, kaydettiğinizde () Backbone sunucuyu güncellemek istediğinizi varsayar ve bir PUT gönderir. Belirli bir kaynağı almak için Backbone yöntemini .fetch () kullanırsınız ve bir GET isteği gönderir. Bir modelde .destroy () 'u çağırdığınızda, DELETE'i gönderir.

Önceki örneklerde, Backbone'a URI'nin nerede olduğunu asla açıkça söylemedim. Bunu bir sonraki örnekte yapalım.

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

Omurga, Üçüncü Yardım Alacak http://localhost:8888/donut/15Basitçe sitenizin kök dizinine / çörek kökü ekleyecektir.

HALA benimleysen, iyi. Bence. Kafan karışmadıkça. Ama yine de yolumuza devam edeceğiz. Bunun ikinci kısmı SUNUCU tarafıdır. Farklı HTTP fiilleri ve bu fiillerin arkasındaki anlamsal anlamlar hakkında konuştuk. Sizin, Backbone VE sunucunuzun paylaşması gereken anlamlar.

Sunucunuzun GET, POST, PUT ve DELETE isteği arasındaki farkı anlaması gerekir. Yukarıdaki örneklerde gördüğünüz gibi, GET, PUT ve DELETE'in tümü aynı URI'yi http://localhost:8888/donut/07gösterebilir. Sunucunuz bu HTTP istekleri arasında ayrım yapamazsa, bu kaynakla ne yapılacağı konusunda çok kafa karıştırıcı olacaktır.

Bu, RESTful sunucu bitiş kodunuzu düşünmeye başladığınız zamandır. Bazıları Ruby'yi sever, bazıları .net'i sever, Ben PHP'yi severim. Özellikle SLIM PHP mikro çerçevesini seviyorum. SLIM PHP, RESTful aktiviteleriyle başa çıkmak için çok zarif ve basit bir araç setine sahip bir mikro çerçevedir. Rotaları (URI'ler) yukarıdaki örneklerde olduğu gibi tanımlayabilirsiniz ve aramanın GET, POST, PUT veya DELETE olmasına bağlı olarak doğru kodu çalıştıracaktır. Recess, Tonic gibi SLIM'e benzer başka çözümler de var. Cake ve CodeIgniter gibi daha büyük çerçevelerin de asgari düzeyde sevmeme rağmen benzer şeyler yaptığına inanıyorum. Slim'i sevdiğimi mi söyledim? ;-)

Sunucudaki alıntı kodunun görünebileceği şey budur (yani özellikle rotalarla ilgili olarak).

$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));
});

Burada, Backbone'un bir JSON nesnesi beklediğini unutmamak önemlidir. Sunucunuzun her zaman içerik türünü 'uygulama / json' olarak atamasını ve yapabiliyorsanız json biçiminde kodlamasını sağlayın. Ardından Backbone, JSON nesnesini aldığında, onu isteyen modeli nasıl dolduracağını bilir.

SLIM PHP ile, yollar yukarıdakine oldukça benzer şekilde çalışır.

$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
});

Yani neredeyse tam bir gidiş dönüş yaptınız! Git bir soda al. Diet Mountain Dew'ı seviyorum. Benim için de bir tane al.

Sunucunuz bir isteği işlediğinde, veritabanı ve kaynakla bir şeyler yaptığında, bir yanıt hazırladığında (ister basit bir http durum numarası ister tam JSON kaynağı olsun), ardından veriler son işlem için Backbone'a geri döner.

Save (), fetch (), vb. Yöntemlerinizle - başarı ve hata üzerine isteğe bağlı geri çağırmalar ekleyebilirsiniz. İşte bu özel pastayı nasıl hazırladığıma dair bir örnek:

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'

Bu örnekle ilgili birkaç farklı şey var. Pastam için, kaydetmeden önce öznitelikleri ayarlamak () yerine, yeni öznitelikleri kaydetme çağrıma aktardığımı göreceksiniz. Omurga, JSON verilerini her yerde alma ve bir şampiyon gibi kullanma konusunda oldukça ninja. Bu yüzden pastamı hindistancevizi ve fındıkla kurtarmak istiyorum. (Bu 2 ceviz mi?) Her neyse, kurtarmaya iki nesne verdim. Öznitelikler JSON nesnesi VE bazı seçenekler. İlki, {bekleyin: doğru}, sunucu yan gezisi başarılı olana kadar istemci tarafı modelimi güncelleme anlamına gelir. Başarılı geri arama, sunucu başarılı bir şekilde yanıt verdiğinde gerçekleşir. Ancak, bu örnek bir hatayla sonuçlandığından (200'den farklı bir durum Backbone'a hata geri aramasını kullanacağını gösterecektir), değişiklikler olmadan modelin bir temsilini elde ederiz. Hala sade ve cevizsiz olmalıdır. Ayrıca sunucunun geri gönderdiği hata nesnesine de erişimimiz var. Bir dize gönderdik, ancak daha fazla özelliğe sahip JSON hata nesnesi olabilir. Bu, error.responseText özniteliğinde bulunur. Evet, 'fındıkları sevmiyoruz.'

Tebrikler. Bir model kurmaktan, onu sunucu tarafına kaydetmekten ve geriye doğru ilk oldukça eksiksiz gidiş-dönüş yolculuğunuzu yaptınız. Umarım bu destan cevabı size bunların nasıl bir araya geldiğine dair bir FİKİR verir. Elbette, geçmişte dolaştığım birçok ayrıntı var ama Backbone save, RESTful fiiller, Sunucu tarafı eylemleri, Response'un temel fikirleri burada. Backbone belgelerini gözden geçirmeye devam edin (diğer belgelere kıyasla okunması çok kolaydır), ancak bunun kafanızı toparlamasının zaman aldığını unutmayın. Ne kadar çok tutarsan o kadar akıcı olursun. Backbone ile her gün yeni bir şey öğreniyorum ve siz sıçramaya başladıkça ve bu çerçevedeki akıcılığınızın büyüdüğünü gördükçe gerçekten eğlenceli hale geliyor. :-)

Mutlu kodlamalar!

DÜZENLEME: Yararlı olabilecek kaynaklar:

SO'da Diğer Benzer Cevaplar: Backbone ile model kimlikleri nasıl oluşturulur

REST'te: http://rest.elkstein.org/ http://www.infoq.com/articles/rest-introduction http://www.recessframework.org/page/towards-restful-php-5-basic- ipuçları