Il data package di Ext Js 4 è stato completamente riscritto ed introduce moltissime novità. Al centro del data package troviamo Ext.data.Model. Il Model non è altro che la rappresentazione di un certo tipo di dati trattati nella nostra applicazione. Ad esempio un applicazione per la gestione dei clienti ed relativi ordini avremo sicuramente un model che rappresenta il cliente ed un model che rappresenta l’ordine. Il model quindi è essenzialmente composto da un elenco di valori (campi) e alcune informazioni su di essi. Per comprendere meglio definiamo il model Cliente per la nostra applicazione:
Ext.define('Cliente', {
extend: 'Ext.data.Model',
fields: [
{ name: 'id_cliente', type: 'int' },
{ name: 'nome', type: 'string' },
{ name: 'cognome', type: 'string' },
{ name: 'email', type: 'string', vtype: 'email' },
{ name: 'telefono', type: 'string' }
]
});
Il Model, viene utilizzato unitamente a Ext.data.Store per visualizzare e modificare i dati all’interno della nostra applicazione. Attraverso lo Store è inoltre possibile compiere diverse operazioni come l’ordinamento, la ricerca etc. Per visualizzare l’elenco dei clienti in un grid panel, dobbiamo, quindi, definire un Store:
Ext.create('Ext.data.Store', {
model: 'Cliente',
proxy: {
type: 'ajax',
url : 'clienti.json',
reader: 'json'
},
autoLoad: true
});
In questo Store abbiamo definito un un proxy di tipo AJAX, che carica i dati dall’url specificata in formato json e li interpreta tramite il reader definito. In Ext js 4 possiamo definire svariati tipi locali o remoti di Ext.data.Proxy.
Nell’esempio precedente abbiamo definito il Proxy all’interno dello Store, Est Js 4 ci offre anche un’altro approccio, ovvero la possibilità di definire il Proxy all’interno del Model:
//definisco un modello con il relativo proxy
Ext.define('Cliente', {
extend: 'Ext.data.Model',
fields: [
{ name: 'id_cliente', type: 'int' },
{ name: 'nome', type: 'string' },
{ name: 'cognome', type: 'string' },
{ name: 'email', type: 'string', vtype: 'email' },
{ name: 'telefono', type: 'string' }
],
idProperty: 'id_cliente'
proxy: {
type: 'ajax',
api : {
create : 'createCliente.php',
read : 'elencoClienti.php',
update : 'updateCliente.php',
destroy : 'deleteCliente.php'
},
reader: {
type: 'json',
root: 'dati'
},
writer: {
type: 'json',
writeAllFields:true,
root : 'data',
encode: true
}
}
});
// Uso il proxy definito nel model
Ext.create('Ext.data.Store', {
model: 'Cliente'
});
Questo approccio offre due vantaggi. Il primo è evidente, tutti gli store che useranno il Model Cliente leggeranno i dati dallo stesso Proxy, non dovremo così definire un Proxy in ogni Store. Il secondo è meno evidente ma altrettanto interessante; possiamo caricare e salvare i dati senza l’uso di un Store.
Prima di vedere come compiere le operazioni sui dati vediamo bene il significato delle varie configurazioni del Model Cliente.
idProperty: 'id_cliente'
La configurazione serve ad indicare qual’è il campo che identifica univocamente il record, di default questo valore è id se come nel nostro Cliente si è usato un campo diverso da id, si deve necessariamente specificare quale campo riveste la funzione di id, in questo modo il Proxy verificando la presenza di questo valore sarà in grado di stabilire se si tratta di un nuovo record oppure di una modifica ad un record esistente, eseguendo la chiamata ajax corretta.
api : {
create : 'createCliente.php',
read : 'elencoClienti.php',
update : 'updateCliente.php',
destroy : 'deleteCliente.php'
}
La configurazione api consente di indicare al Porxy quali sono le url da chiamare per ogni singola operazione CRUD (Create, Read, Update, Destroy), se state usando un back end che è in grado di riconoscere le operazioni restful (PUT, POST, GET, DELETE) potete tralasciare api ed usare la configurazione url insieme a la configurazione type: ‘rest’.
reader: {
type: 'json',
root: 'dati'
}
Il reader è quello che si occupa di leggere i dati, in questo caso abbiamo specificato che il tipo di dati è json e che i dati veri e propri sono dentro l’array dati. Questo reader si aspetta una risposta json di questo tipo:
{"success":true, "message":"Dati caricati correttamente", "dati":[{record 1},{record 2},...,{record n}]}
Ed infine:
writer: {
type: 'json',
writeAllFields:true,
root : 'data',
encode: true
}
Il writer si occupa di definire il modo in cui operano le richieste di scrittura sul server remoto. In particolare stiamo indicando che i dati inviati devono essere di tipo json, che bisogna inviare sempre tutti i dati writeAllFields:true (se il framework remoto supporta l’aggiornamento solo dei campi modificati, è possibile saltare questa configurazione che di default è false) e infine che i dati saranno codificati dentro il parametro data dell’azione POST, in php avremo quindi:
$dati = json_decode($_POST['data']);
Come abbiamo detto, possiamo compiere delle operazione sui dati senza l’ausilio dello Store, vediamo:
// Prendiamo un riferimento al modello Cliente
var Cliente = Ext.ModelMgr.getModel('Cliente');
var stefano = Ext.create('Cliente', {
nome: 'Stefano',
cognome: 'Perinetti',
email : 'stefano@prova.com',
tel: '+39000000000'
});
//Possiamo salvare stefano senza l'uso di uno Store, perché abbiamo definito nel Model tutto il necessario
//per questa operazione
stefano.save({
success: function(stefano) {
console.log("Stefano salvato! id_cliente = "+ stefano.getId());
}
});
In questo esempio abbiamo creato un nuovo cliente e abbiamo salvato i suoi dati sul server remoto utilizzando un’istanza del Model Cliente senza l’ausilio di uno Store. Da notare che il metodo Ext.data.Model.save() compie due azioni, la prima è di scrittura e la seconda di lettura per ottenere l’id generato probabilmente dal server remoto. Nell’operazione di lettura che avviene su quanto restituito dalla chiamata POST per il salvataggio dei dati sul server, deve quindi essere incluso l’intero record appena salvato con il suo id all’interno dell’array (root: ‘dati’) definito nel Proxy reader. In breve save() si aspetta una risposta simile:
{"success": true, "message":"Record salvato correttamente.", "dati":{"id_cliente":123, "nome":"Stefano" ...}}
Ci sono ancora molte cose da analizzare sul data package vedremo nella seconda parte di questo articolo.
Oggi mi è successo di dover installare Centos 5.6 su di un server con 3Tb di storage. Durante l’installazione al momento di creare le partizioni ricevevo un errore strano: “impossibile fare il boot da una partizione GPT”. In sostanza il vecchio MBR supporta volumi di massimo 2Tb quindi se si crea un volume logico maggiore di 2Tb i nuovi server dotati di EFI al posto di MBR utilizzano GPT che ovviamente ha molte meno limitazioni ed è più flessibile. Il kernel di default di Centos 5.6 ha il supporto per GPT tuttavia pare che GRUB non riesca a fare il but da questi volumi.
Commenti recenti