\nTutte le classi che descriveremo appartengono al namespace ACTIONS. \u00a0Questo raggruppamento gestisce, come si intuisce dal nome, le possibili azioni e modifiche relative ad un oggetto.<\/p>\n
La prima classe definita nel namespace \u00e8 la classe ACTION, \u00a0che definisce una lista di\u00a0metodi, che sono ereditati, e di funzioni di interfaccia che devono essere ridefinite dalle classi derivate.<\/p>\n
Dalla classe ACTION deriveranno tutte le operazioni di undo\/redo specifiche delle classi. La classe ACTION deriva a sua volta da DB_OBJECT, la quale eredita, fra le altre l’interfaccia OPERATION_CALL. Si pu\u00f2 intuire quindi che tutte le classi che hanno l’interfaccia ACTION a loro volta possono essere oggetto di undo\/redo, in una struttura logica completamente recursiva!<\/p>\n
A titolo esemplificativo riportiamo il diagramma completo della classe AREA_RESTORE, il cui compito \u00e8 gestire le operazioni di ripristino di aree di un documento<\/p>\n L’altra classe base contenuta nel namespace \u00e8 la DOCUMENT_HISTORY che, come si intuisce, gestisce la storia delle revisioni di un documento. Come ho gi\u00e0 accennato, in questo\u00a0contesto \u00a0usiamo il termine documento\u00a0<\/em>nell’accezione di classe che espone l’interfaccia\u00a0OPERATION_CALL, <\/em>quindi in un’accezione completamente astratta, con consistente necessariamente in oggetti visuali come un testo o immagine.. La classe mette a disposizione una funzione Malloc, il cui compito e di allocare un blocco di memoria utilizzabile dalle istanze derivate o all’interno dei documenti durante la costruzione dell’azione undo\u00a0(ad esempio per allocare un buffer assegnato ad un’area immagine copiata..) Le due funzioni sono virtuali e devono essere riscritte dalle classi derivate. Consistono nell’interfaccia di salvataggio e richiamo dell’azione da un file:\u00a0\u00e8 compito della classe derivata da ACTION decidere se effettuare il flush o meno su file. In genere la strategia \u00e8 quella di decidere internamente alla classe se vale la pena liberare la memoria temporaneamente fino al FilePop successivo;<\/p>\n La funzione virtuale Do(), \u00a0esegue l’azione di undo\/redo su un documento doc passato come argomento.\u00a0Di seguito \u00e8 riportata la funzione usata nella classe AREA_RESTORE<\/p>\n [sourcecode language=”cpp”] Per maggiori dettagli sul paradigma SENDER\/RECEIVER leggere questo articolo<\/a><\/p>\n La classe mette a disposizione un insieme di metodi per la gestione della lista delle azioni; \u00e8\u00a0una FIFO che viene\u00a0popolata con il metodo Push e Redo, e svuotata con i metodi Pop, Undo, Flush.<\/p>\n La lista delle azioni Undo\/Redo non \u00e8 \u00a0limitata: questo significa che l’uso della classe permette di gestire un numero qualunque di azioni di undo, limite posto\u00a0solo dalle dimensioni della memoria e del disco a disposizione.<\/p>\n Questo metodo deve essere richiamato nel costruttore della classe per assegnare il documento di riferimento; Per le classi derivate da DB_OBJECT non \u00e8 necessario richiamare questo metodo, poich\u00e9 l’assegnazione \u00e8 fatta nel costruttore di DB_OBJECT (vedi esempio che segue)<\/p>\n [sourcecode language=”cpp”] Con questo metodo si informa l’interfaccia DOCUMENT_HISTORY che tutte le operazioni successive di Undo e Redo saranno relative al documento passato.<\/p>\n Il metodo \u00e8 usato per aggiungere alla lista un’azione di undo.<\/p>\n Il metodo rimuove l’ultimo elemento inserito nella lista; chiamate successive di Pop svuotano la lista delle azioni in sospeso, dalla pi\u00f9 recente alla pi\u00f9 vecchia. In genere non esiste necessit\u00e0 di usare questa funzione, a meno che l’applicazione specifica non lo richiedA.<\/p>\n Azzera la lista delle azioni di undo\/redo. Il metodo \u00e8 chiamato internamente dal distruttore di\u00a0DOCUMENT_HISTORY, ma pu\u00f2 essere richiamato comunque anche dall’applicazione. Tutte le operazioni di svuotamento della lista distruggono le istanze delle classi ACTION inserite con Push(); pertanto tutte le ACTION, sempre allocate dall’esterno, verranno distrutte nella\u00a0DOCUMENT_HISTORY in modo completamente trasparente al programmatore che usa l’API di Colibri.<\/p>\n esegue undo sull’ultima azione inserita in ordine cronologico, rimuove l’azione e genera un’azione di redo nella lista dei redo.<\/p>\n E’ l’operazione inversa di Undo(); l’ultima operazione inserita dalla Undo() viene ripristinata nella lista degli undo e rimossa da quella dei redo.<\/p>\n Le classi fin qui descritte\u00a0gestiscono l’infrastruttura delle operazioni di Undo\/Redo ma, come si pu\u00f2 capire dal fatto che gestiscono documenti derivati da OPERATION_CALL, comunicano con questi attraverso i metodi di questa interfaccia; A conclusione dell’articolo propongo un esempio concreto di come questi metodi sono applicati in Colibr\u00ec: la gestione undo\/redo nella classe SPECTRAL_IMAGE.<\/p>\n","protected":false},"excerpt":{"rendered":" In questo articolo descriveremo le classi che gestiscono la\u00a0struttura di undo\/redo per i documenti \u00a0generati e gestiti dalle API di Colibri. Vedremo che, in pratica, non esiste differenza fra la gestione delle revisioni dei documenti (ad esempio le varianti colore) e le…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"footnotes":"","_jetpack_memberships_contains_paid_content":false,"jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[24,19,25],"tags":[],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9rwsf-4I","jetpack_likes_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/posts\/292"}],"collection":[{"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/comments?post=292"}],"version-history":[{"count":53,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/posts\/292\/revisions"}],"predecessor-version":[{"id":402,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/posts\/292\/revisions\/402"}],"wp:attachment":[{"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/media?parent=292"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/categories?post=292"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/tags?post=292"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"ClassDiagram8\"](\"https:\/\/i0.wp.com\/www.colorwave.it\/blog\/wp-content\/uploads\/2015\/06\/ClassDiagram81.png?resize=619%2C431&ssl=1\")
<\/a>
\n
\nla classe ACTION \u00e8 \u00a0l’interfaccia di gestione di azioni su un documento. da questa classe derivano le azioni specifiche di undo\/redo eseguite su un documento. La classe espone una funzione di gestione della memoria, che permette al programmatore l’allocazione e disallocazione automatica di buffer; contiene inoltre tre metodi virtuali che saranno riscritti nelle classi derivate.<\/p>\nMalloc()<\/h3>\n
\nLa memoria allocata verr\u00e0 liberata automaticamente alla distruzione della classe<\/p>\nFilePush() e FilePop() scrittura su file delle azioni<\/h3>\n
Do(OPERATIN_CALL *doc) \u00a0esecuzione delle operazioni di Undo\/Redo<\/h3>\n
\nbool AREA_RESTORE::Do(OPERATION_CALL *doc)
\n{
\nGETSTR
\n___SENDER(doc,OP_RESTORE_AREA)
\nA_PUSH(this)
\n___SENDER_END
\nreturn RECEIVER_RESPONSE;
\n}
\n[\/sourcecode]
\nLa funzione controlla che per prima cosa che il comando OP_RESTORE_AREA sia riconosciuto dal documento, quindi esegue la chiamata\u00a0al receiver di doc.<\/span><\/p>\n
\nDOCUMENT_HISTORY \u00e8 la classe di gestione della lista delle azioni effettuate su un documento (OPERATION_CALL). \u00a0Il modo migliore per utilizzare questa interfaccia \u00e8 quella di dichiararla pubblica su una classe; La classe DB_OBJECT gi\u00e0 contiene l’interfaccia DOCUMENT_HISTORY, quindi qualunque classe derivata da essa gi\u00e0 contiene l’interfaccia alla storia del documento. Ad esempio la classe SPECTRAL_IMAGE, che gestisce le immagini spettrali di Colibri, derivando\u00a0da DB_OBJECT eredita anche DOCUMENT_HISTORY.<\/p>\nSetDocument(OPERATION_CALL *doc)<\/h3>\n
\nDB_OBJECT::DB_OBJECT(void)
\n{
\nSetDocument(this); \/\/ assegna il documento al DOCUMENT_HISTORY
\n}
\n[\/sourcecode]<\/p>\nPush(ACTION *action)<\/h3>\n
Pop()<\/strong><\/h3>\n
Flush()<\/strong><\/h3>\n
Undo()<\/h3>\n
Redo()<\/h3>\n
![\"fumetto\"](\"https:\/\/i0.wp.com\/www.colorwave.it\/blog\/wp-content\/uploads\/2015\/05\/fumetto.png?resize=24%2C24&ssl=1\")
<\/a>\u00a0Nota<\/span>:<\/h4>\n