Maneiras de salvar os dados do modelo do Backbone.js?

Estou mais no desenvolvimento de front-end e recentemente comecei a explorar o Backbone.js em meu aplicativo. Eu quero manter os dados do modelo no servidor.

Você poderia me explicar as várias maneiras de salvar os dados do modelo (usando o formato json). Estou usando Java no lado do servidor. Além disso, tenho visto principalmente o REST sendo usado para salvar dados. Como eu gosto mais de front end dev, não conheço REST e outras coisas semelhantes.

Seria ótimo se alguém pudesse me explicar o processo com algum exemplo simples.

Basicamente, os modelos têm uma propriedade chamada atributos, que são os vários valores que um determinado modelo pode ter. O Backbone usa objetos JSON como uma maneira simples de preencher esses valores usando vários métodos que usam objetos JSON. Exemplo:

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

Para preencher o modelo, existem algumas maneiras de fazer isso. Por exemplo, você pode configurar sua instância de modelo passando um método JSON OU use o método set (), que recebe um objeto JSON de atributos.

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

Portanto, isso nos leva a salvar modelos e mantê-los em um servidor. Há uma série de detalhes sobre "O que é REST / RESTful?" E é meio difícil explicar tudo isso em uma breve sinopse aqui. Especificamente em relação ao salvamento de REST e Backbone, o que você precisa saber é a semântica das solicitações HTTP e o que você está fazendo com seus dados.

Você provavelmente está acostumado com dois tipos de solicitações HTTP. GET e POST. Em um ambiente RESTful, esses verbos têm um significado especial para usos específicos que o Backbone assume. Quando você deseja obter um determinado recurso do servidor (por exemplo, modelo de rosca que salvei da última vez, uma entrada de blog, uma especificação de computador) e esse recurso existe, você faz uma solicitação GET. Por outro lado, quando você deseja criar um novo recurso, você usa POST.

Antes de entrar no Backbone, nunca toquei nos dois métodos de solicitação HTTP a seguir. PUT e DELETE. Esses dois verbos também têm significado específico para Backbone. Quando você deseja atualizar um recurso (por exemplo, alterar o sabor do donut de limão para donut de limon, etc.), você usa uma solicitação PUT. Quando você deseja excluir esse modelo do servidor por completo, use uma solicitação DELETE.

Esses princípios são muito importantes porque com seu aplicativo RESTful, você provavelmente terá uma designação de URI que fará a tarefa apropriada com base no tipo de verbo de solicitação que você usa. Por exemplo:

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

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

Se eu fizer um GET para esse URI, ele obterá um modelo donut com um ID de 17. O: id depende de como você o está salvando no lado do servidor. Este pode ser apenas o ID do seu recurso donut na tabela do banco de dados.

Se eu fizer um PUT para esse URI com novos dados, eu o atualizarei e economizarei. E se eu EXCLUIR esse URI, ele o limpará do meu sistema.

Com o POST, como você ainda não criou um recurso, ele não terá um ID de recurso estabelecido. Talvez o URI de destino que desejo criar recursos seja simplesmente este:

http://localhost:8888/donut

Nenhum fragmento de ID no URI. Todos esses designs de URI dependem de você e de como você pensa sobre seus recursos. Mas com relação ao design RESTful, meu entendimento é que você deseja manter os verbos de suas ações em sua solicitação HTTP e os recursos como substantivos que tornam os URIs fáceis de ler e amigáveis ​​aos humanos.

Você ainda está comigo? :-)

Portanto, vamos voltar a pensar no Backbone. O backbone é maravilhoso porque faz muito trabalho para você. Para salvar nosso donut e a segunda ajuda, simplesmente fazemos o seguinte:

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

O backbone é inteligente. Se você acabou de criar um recurso donut, ele não terá um ID do servidor. Ele tem algo chamado cID que é o que o Backbone usa internamente, mas como não tem um ID oficial, ele sabe que deve criar um novo recurso e envia uma solicitação POST. Se você obteve seu modelo do servidor, provavelmente terá um ID se tudo estiver certo. Neste caso, ao salvar () o Backbone assume que você deseja atualizar o servidor e enviará um PUT. Para obter um recurso específico, você usaria o método Backbone .fetch () e ele enviaria uma solicitação GET. Quando você chama .destroy () em um modelo, ele enviará DELETE.

Nos exemplos anteriores, nunca disse explicitamente ao Backbone onde está o URI. Vamos fazer isso no próximo exemplo.

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

O backbone OBTERÁ o terceiro, ajudando em http://localhost:8888/donut/15 simplesmente adicionará / haste de rosca à raiz do seu site.

Se você ainda está comigo, ótimo. Eu acho que. A menos que você esteja confuso. Mas continuaremos avançando de qualquer maneira. A segunda parte disso é o lado SERVER. Já falamos sobre diferentes verbos de HTTP e os significados semânticos por trás desses verbos. Significados que você, o Backbone E o seu servidor devem compartilhar.

Seu servidor precisa entender a diferença entre uma solicitação GET, POST, PUT e DELETE. Como você viu nos exemplos acima, GET, PUT e DELETE podem apontar para o mesmo URIhttp://localhost:8888/donut/07 A menos que seu servidor possa diferenciar entre essas solicitações HTTP, ficará muito confuso sobre o que fazer com esse recurso.

É aí que você começa a pensar sobre o código final do servidor RESTful. Algumas pessoas gostam de Ruby, algumas pessoas gostam de .net, eu gosto de PHP. Particularmente gosto do micro-framework SLIM PHP. SLIM PHP é um micro-framework que possui um conjunto de ferramentas muito elegante e simples para lidar com atividades RESTful. Você pode definir rotas (URIs) como nos exemplos acima e dependendo se a chamada for GET, POST, PUT ou DELETE ela executará o código correto. Existem outras soluções semelhantes ao SLIM como Recess, Tonic. Eu acredito que frameworks maiores como Cake e CodeIgniter também fazem coisas semelhantes, embora eu goste do mínimo. Eu disse que gosto de Slim? ;-)

Isso é o que o código de trecho no servidor pode parecer (ou seja, especificamente em relação às rotas).

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

Aqui é importante observar que o Backbone espera um objeto JSON. Sempre faça com que seu servidor designe o tipo de conteúdo como 'application / json' e codifique-o no formato json, se possível. Então, quando o Backbone recebe o objeto JSON, ele sabe como preencher o modelo que o solicitou.

Com SLIM PHP, as rotas operam de forma bastante semelhante às anteriores.

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

Então você fez quase toda a viagem de ida e volta! Vá buscar um refrigerante. Eu gosto de Diet Mountain Dew. Pegue um para mim também.

Depois que o servidor processa uma solicitação, faz algo com o banco de dados e o recurso, prepara uma resposta (seja um número de status http simples ou um recurso JSON completo), os dados voltam ao Backbone para o processamento final.

Com seus métodos save (), fetch (), etc. - você pode adicionar callbacks opcionais em caso de sucesso e erro. Aqui está um exemplo de como eu configurei este bolo específico:

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'

Existem algumas coisas diferentes sobre este exemplo. Você verá que para o meu bolo, em vez de definir () os atributos antes de salvar, eu simplesmente passei os novos atributos para minha chamada de salvamento. O Backbone é bastante ninja em levar dados JSON para todos os lugares e tratá-los como um campeão. Então, quero guardar meu bolo com cocos e nozes. (São 2 nozes?) De qualquer forma, passei dois objetos para meu save. Os atributos do objeto JSON E algumas opções. O primeiro, {wait: true} significa não atualizar meu modelo do lado do cliente até que a viagem do lado do servidor seja bem-sucedida. O retorno de chamada de sucesso ocorrerá quando o servidor retornar uma resposta com sucesso. No entanto, como este exemplo resulta em um erro (um status diferente de 200 indicará ao Backbone para usar o callback de erro), obtemos uma representação do modelo sem as alterações. Ainda deve ser simples e sem nozes. Também temos acesso ao objeto de erro que o servidor enviou de volta. Enviamos de volta uma string, mas pode ser um objeto de erro JSON com mais propriedades. Ele está localizado no atributo error.responseText. Sim, 'não gostamos de nozes'.

Parabéns. Você fez sua primeira viagem completa de ida e volta configurando um modelo, salvando-o do lado do servidor e vice-versa. Espero que esta resposta épica dê a você uma IDEIA de como tudo isso se junta. Há, é claro, muitos detalhes pelos quais estou passando, mas as ideias básicas de salvamento do Backbone, verbos RESTful, ações do lado do servidor, Resposta estão aqui. Continue lendo a documentação do Backbone (que é muito fácil de ler em comparação com outros documentos), mas lembre-se de que isso leva tempo para entender. Quanto mais você persistir, mais fluente será. Eu aprendo algo novo com o Backbone todos os dias e fica muito divertido quando você começa a dar saltos e vê sua fluência neste framework crescendo. :-)

Boa codificação!

EDITAR: Recursos que podem ser úteis:

Outras respostas semelhantes no SO: Como gerar IDs de modelo com backbone

No REST: http://rest.elkstein.org/ http://www.infoq.com/articles/rest-introduction http://www.recessframework.org/page/towards-restful-php-5-basic- dicas