javascript - traductor - backbone vs react

Formas de guardar los datos del modelo Backbone.js?

Question

Estoy más interesado en el desarrollo de interfaces y recientemente comencé a explorar Backbone.js en mi aplicación. Quiero persistir los datos del modelo en el servidor.

¿Podría explicarme las diversas formas de guardar los datos del Modelo (utilizando el formato json)? Estoy usando Java en el lado del servidor. También he visto principalmente que REST se usa para guardar datos. Como estoy más interesado en el desarrollo front-end, no estoy al tanto de REST y otras cosas similares.

Sería genial si alguien pudiera por favor explicarme el proceso con un simple ejemplo.

Answer 1

Básicamente, los Modelos tienen una propiedad llamada atributos, que son los diversos valores que un determinado modelo puede tener. Backbone usa objetos JSON como una manera simple de poblar estos valores usando varios métodos que toman objetos JSON. Ejemplo:

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

Para poblar el modelo hay algunas maneras de hacerlo. Por ejemplo, puede configurar su instancia de modelo pasando un JSON O use el método llamado set () que toma un 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''}

Entonces, esto nos lleva a guardar modelos y persistirlos en un servidor. Hay una gran cantidad de detalles con respecto a "¿Qué es REST / RESTful?" Y es un poco difícil explicar todo esto en una breve reseña aquí. Específicamente en lo que respecta a REST y el almacenamiento de Backbone, lo que debe analizar es la semántica de las solicitudes HTTP y lo que está haciendo con sus datos.

Probablemente estés acostumbrado a dos tipos de solicitudes HTTP. GET y POST. En un ambiente RESTful, estos verbos tienen un significado especial para usos específicos que asume el Backbone. Cuando desea obtener un determinado recurso del servidor (por ejemplo, el modelo donut que guardé la última vez, una entrada de blog, una especificación informática) y ese recurso existe, usted hace una solicitud GET. Por el contrario, cuando quiere crear un nuevo recurso, usa POST.

Antes de entrar en Backbone, nunca he tocado los dos métodos de solicitud HTTP siguientes. PONER y ELIMINAR. Estos dos verbos también tienen un significado específico para Backbone. Cuando desee actualizar un recurso (por ejemplo, cambie el sabor de la rosquilla de limón a limon donut, etc.) use una solicitud PUT. Cuando desee eliminar ese modelo del servidor, utilice una solicitud DELETE.

Estos conceptos básicos son muy importantes porque con su aplicación RESTful, probablemente tendrá una designación de URI que hará la tarea adecuada en función del tipo de verbo de solicitud que utilice. Por ejemplo:

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

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

Si realizo un GET a ese URI, obtendría el modelo donut con un ID de 17. El ID: depende de cómo lo guarde del lado del servidor. Esto podría ser solo el ID de su recurso donut en su tabla de base de datos.

Si realizo un PUT a ese URI con nuevos datos, estaría actualizando, guardando sobre eso. Y si ELIMINO ese URI, lo purgaría de mi sistema.

Con POST, dado que aún no ha creado un recurso, no tendrá una ID de recurso establecida. Tal vez el objetivo URI que quiero crear recursos es simplemente esto:

http://localhost:8888/donut

Sin fragmento de ID en el URI. Todos estos diseños de URI dependen de usted y de cómo piensa acerca de sus recursos. Pero con respecto al diseño RESTful, entiendo que quiere mantener los verbos de sus acciones en su solicitud HTTP y los recursos como sustantivos que hacen que los URI sean fáciles de leer y amigables para los humanos.

¿Sigues conmigo? :-)

Así que volvamos a pensar en Backbone. El backbone es maravilloso porque hace mucho trabajo para ti. Para guardar nuestro donut y secondHelping, simplemente hacemos esto:

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

La red troncal es inteligente. Si acaba de crear un recurso donut, no tendrá una identificación del servidor. Tiene algo llamado cID, que es lo que Backbone usa internamente, pero como no tiene una ID oficial, sabe que debe crear un nuevo recurso y envía una solicitud POST. Si obtuvo su modelo del servidor, probablemente tendrá una identificación si todo fue correcto. En este caso, cuando guarde () Backbone asume que desea actualizar el servidor y enviará un PUT. Para obtener un recurso específico, debe usar el método Backbone .fetch () y envía una solicitud GET. Cuando llame a .destroy () en un modelo enviará el DELETE.

En los ejemplos anteriores, nunca le dije explícitamente a Backbone dónde está el URI. Hagámoslo en el siguiente ejemplo.

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 OBTENDRÁ el thirdHelping en http://localhost:8888/donut/15 Simplemente agregará / donut stem a la raíz de su sitio.

Si TODAVÍA está conmigo, bien. Creo. A menos que estés confundido. Pero vamos a caminar penosamente de todos modos. La segunda parte de esto es el lado del SERVIDOR. Hemos hablado sobre diferentes verbos de HTTP y los significados semánticos detrás de esos verbos. Significados que usted, Backbone, Y su servidor deben compartir.

Su servidor necesita entender la diferencia entre una solicitud GET, POST, PUT y DELETE. Como viste en los ejemplos anteriores, GET, PUT y DELETE podrían todos apuntar al mismo URI http://localhost:8888/donut/07 A menos que tu servidor pueda diferenciar entre estas solicitudes HTTP, será muy confuso en cuanto a qué para hacer con ese recurso.

Esto es cuando empiezas a pensar en tu código de final de servidor RESTful. A algunas personas les gusta Ruby, a algunas personas les gusta .net, me gusta PHP. Particularmente me gusta el micro-framework SLIM PHP. SLIM PHP es un micro-framework que tiene un conjunto de herramientas muy elegante y simple para tratar con actividades RESTful. Puede definir rutas (URI) como en los ejemplos anteriores y, dependiendo de si la llamada es GET, POST, PUT o DELETE, ejecutará el código correcto. Hay otras soluciones similares a SLIM como Recess, Tonic. Creo que los frameworks más grandes como Cake y CodeIgniter también hacen cosas similares aunque me gusta lo mínimo. ¿Dije que me gusta Slim? ;-)

Esto es lo que podría parecer el código de fragmento en el servidor (es decir, específicamente con respecto a las rutas).

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

Aquí es importante tener en cuenta que Backbone espera un objeto JSON. Siempre haz que tu servidor designe el tipo de contenido como ''aplicación / json'' y codifícalo en formato json si puedes. Luego, cuando Backbone recibe el objeto JSON, sabe cómo poblar el modelo que lo solicitó.

Con SLIM PHP, las rutas funcionan de manera muy similar a la anterior.

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

¡Así que casi has completado el viaje completo! Ve por un refresco. Me gusta Diet Mountain Dew. Consigue uno para mí también.

Una vez que su servidor procesa una solicitud, hace algo con la base de datos y el recurso, prepara una respuesta (ya sea un simple número de estado HTTP o un recurso JSON completo), luego los datos vuelven al Backbone para el procesamiento final.

Con sus métodos save (), fetch (), etc., puede agregar callbacks opcionales en caso de éxito y error. Aquí hay un ejemplo de cómo configuro este pastel en particular:

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

Hay un par de cosas diferentes sobre este ejemplo que. Verás que para mi torta, en lugar de establecer los atributos antes de guardar, simplemente pasé los nuevos atributos a mi llamada de guardado. Backbone es bastante ninja al tomar datos JSON por todo el lugar y manejarlo como un campeón. Así que quiero guardar mi pastel con cocos y nueces. (¿Eso es 2 nueces?) De todos modos, pasé en dos objetos para mi salvación. Los atributos objeto JSON Y algunas opciones. El primero, {wait: true} significa que no actualizo mi modelo del lado del cliente hasta que el viaje lateral del servidor sea exitoso. La devolución de llamada correcta se producirá cuando el servidor devuelva una respuesta satisfactoriamente. Sin embargo, dado que este ejemplo da como resultado un error (un estado distinto de 200 indicará a Backbone que use la devolución de llamada de error) obtenemos una representación del modelo sin los cambios. Debería ser sencillo y sin nueces. También tenemos acceso al objeto de error que envió el servidor. Devolvimos una cadena pero podría ser un objeto de error JSON con más propiedades. Esto se encuentra en el atributo error.responseText. Sí, "no nos gustan las nueces".

Felicitaciones. Has realizado tu primer viaje bastante completo desde la configuración de un modelo, guardándolo desde el servidor y viceversa. Espero que esta respuesta épica te dé una IDEA de cómo todo esto se une. Por supuesto, hay muchos detalles que estoy pasando de largo, pero las ideas básicas de guardar el backbone, verbos RESTful, acciones del lado del servidor, respuesta están aquí. Continúe con la documentación de Backbone (que es muy fácil de leer en comparación con otros documentos), pero tenga en cuenta que esto lleva tiempo. Cuanto más lo mantengas, más fluido serás. Aprendo algo nuevo con Backbone todos los días y se vuelve muy divertido a medida que comienzas a dar saltos y ver crecer tu fluidez en este marco. :-)

Feliz codificación!

EDITAR: Recursos que pueden ser útiles:

Otras respuestas similares sobre SO: cómo generar ID de modelo con Backbone

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