Способы сохранения данных модели Backbone.js?

Я больше занимаюсь разработкой внешнего интерфейса и недавно начал изучать Backbone.js в своем приложении. Я хочу сохранить данные модели на сервере.

Не могли бы вы объяснить, как можно сохранить данные модели (в формате json). Я использую Java на стороне сервера. Также я в основном видел, как REST используется для сохранения данных. Поскольку я больше знаком с разработчиком, я не знаю о REST и других подобных вещах.

Было бы здорово, если бы кто-нибудь мог объяснить мне процесс на простом примере.

86 голосов | спросил testndtv 22 MaramThu, 22 Mar 2012 08:03:01 +04002012-03-22T08:03:01+04:0008 2012, 08:03:01

1 ответ


0

В основном модели имеют свойство, называемое атрибутами, которые представляют собой различные значения, которые может иметь определенная модель. Backbone использует объекты JSON как простой способ заполнения этих значений с помощью различных методов, которые принимают объекты JSON. Пример:

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

Для заполнения модели есть несколько способов сделать это. Например, вы можете настроить экземпляр модели, передав метод JSON OR с именем set (), который принимает объект атрибутов JSON.

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

Итак, это подводит нас к сохранению моделей и их сохранению на сервере. Существует целый ряд деталей относительно того, что такое REST /RESTful? И это довольно сложно объяснить вкратце. В частности, что касается сохранения REST и Backbone, вам нужно обратить внимание на семантику HTTP-запросов и то, что вы делаете со своими данными.

Вероятно, вы привыкли к двум видам HTTP-запросов. ПОЛУЧИТЬ и ПОСТ. В среде RESTful эти глаголы имеют особое значение для конкретных целей, которые предполагает Backbone. Если вы хотите получить определенный ресурс с сервера (например, модель пончика, которую я сохранил в прошлый раз, запись в блоге, спецификацию компьютера) и этот ресурс существует, вы делаете запрос GET. И наоборот, когда вы хотите создать новый ресурс, вы используете POST.

До того как я попал в Backbone, я никогда не касался следующих двух методов HTTP-запроса. ПОСТАВИТЬ и УДАЛИТЬ. Эти два глагола также имеют особое значение для позвоночника. Если вы хотите обновить ресурс (например, изменить вкус лимонного пончика на лимонный пончик и т. Д.), Вы используете запрос PUT. Если вы хотите удалить эту модель с сервера все вместе, вы используете запрос DELETE.

Эти основы очень важны, потому что в приложении RESTful у вас, вероятно, будет обозначение URI, которое будет выполнять соответствующую задачу в зависимости от типа используемого глагола запроса. Например:

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

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

Если я сделаю GET для этого URI, он получит модель пончика с идентификатором 17. Значение: id зависит от того, как вы сохраняете его на стороне сервера. Это может быть просто идентификатор вашего ресурса пончика в таблице базы данных.

Если я сделаю PUT для этого URI с новыми данными, я обновлю его, сохранив поверх него. И если я удаляю этот URI, он удаляет его из моей системы.

С POST, поскольку вы еще не создали ресурс, у него не будет установленного идентификатора ресурса. Может быть, цель URI, которую я хочу создать, состоит в следующем:

http://localhost:8888/donut

Нет фрагмента идентификатора в URI. Все эти конструкции URI зависят от вас и вашего мнения о ваших ресурсах. Но что касается дизайна RESTful, я понимаю, что вы хотите сохранить глаголы ваших действий в своем HTTP-запросе, а ресурсы в качестве существительных, которые делают URI простыми для чтения и удобными для человека.

Ты все еще со мной? : -)

Итак, вернемся к размышлениям о Backbone. Магистраль - это замечательно, потому что она делает для вас много работы. Чтобы сохранить наш пончик и secondHelping, мы просто делаем это:

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

Костяк умный. Если вы только что создали ресурс пончика, у него не будет идентификатора с сервера. У него есть то, что называется cID, и это то, что Backbone использует внутренне, но поскольку у него нет официального идентификатора, он знает, что должен создать новый ресурс, и отправляет запрос POST. Если вы получили свою модель с сервера, она, вероятно, будет иметь идентификатор, если все было правильно. В этом случае при сохранении () Backbone предполагает, что вы хотите обновить сервер, и он отправит PUT. Чтобы получить конкретный ресурс, вы должны использовать метод Backbone .fetch (), и он отправляет запрос GET. Когда вы вызываете .destroy () для модели, она отправляет УДАЛИТЬ.

В предыдущих примерах я никогда не указывал Backbone, где находится URI. Давайте сделаем это в следующем примере.

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 ПОЛУЧИТ третью помощь в http://localhost:8888/donut/15, которая просто добавит /пончик ствол на ваш сайткорень.

Если ты все еще со мной, хорошо. Я думаю. Если вы не запутались. Но мы все равно будем тащиться. Вторая часть этого - сторона SERVER. Мы говорили о разных глаголах HTTP и семантических значениях этих глаголов. Значения, которыми вы, Backbone, и ваш сервер должны поделиться.

Ваш сервер должен понимать разницу между запросами GET, POST, PUT и DELETE. Как вы видели в приведенных выше примерах, GET, PUT и DELETE могут указывать на один и тот же URI http://localhost:8888/donut/07 Если ваш сервер не может различать эти HTTP-запросы, это будет очень запутано, что делать с этим ресурсом.

Это когда вы начинаете думать о коде завершения вашего сервера RESTful. Некоторым нравится Ruby, другим нравится .net, мне нравится PHP. Особенно мне нравится микро-фреймворк SLIM PHP. SLIM PHP - это микро-фреймворк с очень элегантным и простым набором инструментов для работы с RESTful-операциями. Вы можете определить маршруты (URI), как в приведенных выше примерах, и в зависимости от того, является ли вызов GET, POST, PUT или DELETE, он выполнит правильный код. Есть и другие решения, похожие на SLIM, такие как Recess, Tonic. Я считаю, что большие фреймворки, такие как Cake и CodeIgniter, также делают подобные вещи, хотя мне нравится минимальный. Я сказал, что мне нравится Slim? ; -)

Вот как может выглядеть код выдержки на сервере (то есть, в частности, относительно маршрутов.)

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

Здесь важно отметить, что Backbone ожидает объект JSON. Всегда делайте так, чтобы ваш сервер определял тип контента как «application /json» и кодируйте его в формате json, если можете. Затем, когда Backbone получает объект JSON, он знает, как заполнить модель, которая его запросила.

В SLIM PHP маршруты работают примерно так же, как описано выше.

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

Итак, вы почти совершили круговое путешествие! Иди возьми газировку. Мне нравится Диета Маунтин Дью. Получите один для меня тоже.

Как только ваш сервер обработает запрос, сделает что-то с базой данных и ресурсом, подготовит ответ (будь то простой номер статуса http или полный ресурс JSON), затем данные возвращаются в Backbone для окончательной обработки.

С помощью методов save (), fetch () и т. д. вы можете добавить дополнительные обратные вызовы при успехе и ошибке. Вот пример того, как я настроил этот конкретный торт:

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'

В этом примере есть несколько разных вещей. Вы увидите, что для моего торта вместо установки () атрибутов перед сохранением я просто передал новые атрибуты своему вызову сохранения. Backbone - отличный ниндзя, который берет данные JSON повсюду и обрабатывает их как чемпион. Поэтому я хочу сохранить свой пирог с кокосами и орехами. (Это 2 чокнутых?) Во всяком случае, я передал два объекта, чтобы сохранить. Атрибуты объекта JSON И некоторые параметры. Первое, {wait: true} означает, что не обновляйте мою модель на стороне клиента, пока отключение на стороне сервера не будет успешным. Успешный обратный вызов произойдет, когда сервер успешно вернет ответ. Однако, поскольку этот пример приводит к ошибке (состояние, отличное от 200, укажет Backbone на использование обратного вызова с ошибкой), мы получаем представление модели без изменений. Это все еще должно быть простым и без гаек. У нас также есть доступ к объекту ошибки, который сервер отправил обратно. Мы отправили обратно строку, но это мог быть объект ошибки JSON с дополнительными свойствами. Это находится в атрибуте error.responseText. Да, мы не любим орехи.

Поздравления. Вы сделали свой первый довольно полный круговой обход от настройки модели, сохранения ее на стороне сервера и обратно. Я надеюсь, что этот эпический ответ даст вам ИДЕЮ того, как все это объединяется. Конечно, есть много деталей, о которых я расскажу, но основные идеи о сохранении Backbone, глаголах RESTful, действиях на стороне сервера и ответах здесь. Продолжайте изучать документацию по Backbone (которую очень легко читать по сравнению с другими документами), но имейте в виду, что на это нужно время, чтобы обернуть голову. Чем большеВы держите это, тем более свободно вы будете. Я узнаю что-то новое с Backbone каждый день, и это становится действительно забавным, когда вы начинаете совершать прыжки и видите, что ваша беглость в этой среде растет. : -)

Удачного кодирования!

РЕДАКТИРОВАТЬ: ресурсы, которые могут быть полезны:

Другие похожие ответы на SO: Как создать идентификаторы модели с помощью Backbone

На отдыхе: http://rest.elkstein.org/ http://www.infoq.com/articles/rest-introduction http://www.recessframework.org/page/towards-restful -PHP-5-основные-советы

ответил jmk2142 25 MarpmSun, 25 Mar 2012 21:02:46 +04002012-03-25T21:02:46+04:0009 2012, 21:02:46

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132