{"id":106,"date":"2008-09-26T09:21:01","date_gmt":"2008-09-26T08:21:01","guid":{"rendered":"http:\/\/www.ilinux.it\/content\/?p=106"},"modified":"2011-07-19T00:00:04","modified_gmt":"2011-07-18T23:00:04","slug":"cocoa-e-il-mistero-del-predicato-perduto-parte-seconda-the-fog","status":"publish","type":"post","link":"https:\/\/www.ilinux.it\/content\/cocoa-e-il-mistero-del-predicato-perduto-parte-seconda-the-fog.html","title":{"rendered":"Cocoa e il mistero del predicato perduto (Parte seconda: The Fog)"},"content":{"rendered":"

\"\"<\/a>Con la precedente puntata ci siamo lasciati svelando il mistero legato al “fetch predicate” di un oggetto NSTreeController; non sembra per\u00f2 diradarsi la nebbia di mistero che avvolge il mondo Cocoa.Sembra che proprio l’astrazione NSTreeController sia quella maggiormente pregna di misteri e trabocchetti.<\/span><\/p>\n

Diciamo da subito che in questo caso non siamo di fronte ad un nuovo “predicato perduto”, ma ci sembrava doveroso collocare questo discorso a seguire, in una ideale continuit\u00e0 con il mistero precedente: un “sequel”, insomma, come ogni buon film di cassetta, con tanto di aberrazioni rispetto alla storia originale.<\/span><\/p>\n

Arcani e oscuri dunque sono i metodi di NSTreeController ed il modo di utilizzarli: le cose si fanno ancora pi\u00f9 esoteriche quando si metta il tutto in relazione a Core Data, altro “enigmatico strumento”.<\/span><\/p>\n

Abbiamo gi\u00e0 detto come Core Data sia stato forgiato a somiglianza di basi dati relazionali senza raggiungerne l’immagine speculare; tra i limiti di questa somiglianza \u00e8 da considerare l’assenza di direttive di ordinamento e raggruppamento dei dati quali conosciamo nei RDBMS (mediante espressioni quali ORDER BY, GROUP BY, note a chi “mastica” di SQL).<\/span><\/p>\n

La conseguenza pi\u00f9 evidente \u00e8 la comune accettazione che le informazioni rese persistenti un contesto Core Data non sono restituite in modo ordinato, ne per attributo, ne tanto mento per epoca di creazione. Ma \u00e8 questo realmente un limite di Core Data come gli si imputa? O di nuovo siamo davanti ad una non comprensione dei ruoli.<\/span><\/p>\n

E’ forse compito del modello manipolare i dati? Non sar\u00e0 che in un paradigma MVC \u00e8 compito del controller?<\/span><\/p>\n

Core Data rappresenta il livello Modello nel paradigma MVC: l’ordinamento dei dati \u00e8 un compito di presentazione e dunque pi\u00f9 propriamente compito del livello Controllo.<\/span><\/p>\n

Il vero mistero sarebbe allora l’assenza di strumenti utili a compiere questi aggiustamenti di presentazione in astrazioni di controllo quali NSArrayController e NSTreeController, dati appunto allo scopo di soddisfare le necessit\u00e0 della stragrande parte degli oggetti di Visualizzazione in Cocoa (omettiamo NSObjectController che non \u00e8 adatto alla gestione di aggregati di dati).<\/span><\/p>\n

Eppure sembra che le soluzioni all’ordinamento di dati Core Data vengono spesso ricercate in implementazioni personali, artistiche, complesse ma inutili.<\/span><\/p>\n

La soluzione \u00e8 invero a portata di mano ed \u00e8 rappresentata da una istanza di oggetto NSSortDescriptor. enterprise portal software<\/a> . Questi oggetti sono introdotti nel framework al solo scopo di descrivere criteri di ordinamento di informazioni quali quelle di un oggetto container.<\/span><\/p>\n

Se il Modello offerto da Core Data viene gestito dunque in modo semplice ed ottimizzato da istanze di oggetti controller, possibile che questi non abbiano metodi di ordinamento dei “managedObjects” il cui risultato sia esposto nei “arrangedObjects”? Non \u00e8 credibile.<\/span><\/p>\n

Tra i compiti degli oggetti di controllo container (NSArrayController e NSTreeController) c’\u00e8 infatti anche la realizzazione di un ordinamento dei dati: questo avviene per mezzo del metodo -setSortDescriptors.<\/span><\/p>\n

Qualsiasi sia l’ordine dei dati internamente al contesto di Core Data, il controller sar\u00e0 in grado di imporre un proprio ordine, manipolando l’insieme dei dati a favore di una visualizzazione utile all’utente finale.<\/span><\/p>\n

L’ordinamento non \u00e8 mantenuto nella persistenza ma “calcolato” ogni volta dal controller: eventualmente si pu\u00f2 mantenere persistente l’indicatore con cui l’utente impone un proprio ordinamento, ma l’azione vera e propria di ordinamento sar\u00e0 eseguita dal controller.<\/span><\/p>\n

Cos\u00ec un NSSortDescriptor che imponga un ordinamento lessicografico su un attributo del modello risulterebbe indipendente da interventi utente, mentre un NSSortDescriptor che imponga un ordinamento rispetto ad altro attributo concepito come “peso” della posizione indicata dall’utente risulter\u00e0 strumento efficace ad ordinare le informazioni secondo quanto chiesto dall’utente. longboard wheels<\/a> . Nessun codice accessorio \u00e8 necessario.<\/span><\/p>\n

Ci sembra con questo di aver concluso con i misteri.<\/span><\/p>\n

In realt\u00e0 si potrebbe concludere con un elogio della autosufficienza del framework Cocoa che dovrebbe essere naturalmente ovvia; Cocoa \u00e8 framework del sistema MacOSX, e non un generico framework per sviluppo software compatibile-con; dunque in se deve avere tutto o quasi il necessario a risolvere le questioni di implementazione dei pi\u00f9 comuni paradigmi di interfaccia utente introdotti nel HIG (Human Interface Guideline) di Apple. E questo riesce a fare, migliorandosi ad ogni revisione.<\/span><\/p>\n


\n<\/span><\/p>","protected":false},"excerpt":{"rendered":"

Con la precedente puntata ci siamo lasciati svelando il mistero legato al “fetch predicate” di un oggetto NSTreeController; non sembra per\u00f2 diradarsi la nebbia di mistero che avvolge il mondo Cocoa.<\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,4],"tags":[],"_links":{"self":[{"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/posts\/106"}],"collection":[{"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/comments?post=106"}],"version-history":[{"count":8,"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/posts\/106\/revisions"}],"predecessor-version":[{"id":176,"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/posts\/106\/revisions\/176"}],"wp:attachment":[{"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/media?parent=106"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/categories?post=106"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ilinux.it\/content\/wp-json\/wp\/v2\/tags?post=106"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}