Newsgroup: it.lavoro.informatica
Titolo: Strategia di implementazione di Undo/Redo [Luc, puoi buttarci uno sguardo?]

Salve a tutti,
non so se sono propriamente IT, ma non saprei proprio a chi rivolgermi. 
Vorrei avere pareri su come implementare una buona strategia per 
l'Undo/Redo. Lo scenario è questo: il presentation layer è un editor 
visual tramite il quale l'utente esegue l'editing di un grafo 
(tipo-UML), "sotto" c'è una BL piuttosto complessa. L'approccio finora 
seguito è che tutti gli oggetti modificati tengono traccia del loro 
stato precedente (andando indietro per N passi, dove N è il max numero 
di CTRL+Z che l'utente possa fare). Può essere un buon apporoccio? Avete 
qualche consiglio in alternativa?
Ciao,
Giulio
p.s. Luc, ti ho chiamato in causa "direttamente" perchè mi pare di aver 
capito che lavori nel campo dell'editoria, quindi probabilmente hai 
incontrato problemi del genere. ;-)

Pattern Memento : 
http://www2.mokabyte.it/1999/04/memento_teoria.htm
Segui il link, in coda c'è il riferimento ad una possibile
implementazione.

 l'Undo/Redo. 
Direi il design pattern memento fa il caso tuo.

 Pattern Memento : 
http://www2.mokabyte.it/1999/04/memento_teoria.htm
Si, in pratica è quello che faccio adesso. Il fatto è che se gli oggetti 
coinvolti sono tanti l'occupazione di memoria diventa "onerosa". Ho 
notato poi che anche altri editor grafici hanno un apporoccio piuttosto 
"riduttivo", tipo Argo-UML, che ad ogni CTRL+Z riporta indietro 
all'ultima versione *salvata*.
Comunque grazie,
Giulio
--

 l'Undo/Redo.
Boh.. io seguirei la strada della serializzazione ...
Ogni cambiamento genera una stringona che contiene i vecchi oggetti
modificati serializzati, le stringhe non occupano molta memoria e
possono essere facilmente scaricate su disco.
In fase di undo deserializzi gli oggetti e li ripristini.. e ualà..
funziona sempre, serve poco codice e puoi usare il disco come swap.

 funziona sempre, serve poco codice e puoi usare il disco come swap.
Uhm... non saprei... considera la mia applicazione come un editor per 
diagrammi a blocchi... metti caso che gli utlimi cambiamenti sono solo 
relativi ad un blocco, che faccio, in una applicazione di 200 salvo ogni 
volta anche gli altri 199? Al limite potrei implementare una specie di 
history "incrementale" della serializzazione...
Grazie per il suggerimento,
Giulio

alternativa?
Non mi sembra molto sensato distribuire le informazioni tra un bel po' di 
oggetti differenti. E poi, come la gestisci la sincronizzazione? Come fai a 
sapere qual è l'ultimo oggetto che ha cambiato stato senza una logica un po' 
più centralizzata?
Io, personalmente archivierei le ultime modifiche in una sola lista, in un 
qualche tipo di formato appropriato... non ho idea del funzionamento interno 
dell'applicazione, ma posso ipotizzare ad esempio una copia di ogni oggetto 
così com'era prima di essere modificato. Poi userei solo quella per 
l'undo/redo.
Massimo

 history "incrementale" della serializzazione...
Ad ogni operazione poi salvare solo gli oggetti modificati, per la
precisione la posizione grafica userei una struttura apposita.
In qualunque caso, sul fatto di salvare 200 oggetti serializzati
dipende.. da quanto sono grandi. Se ipotizzo 1kb ad oggetto sono 200 kb
a passo, se tieni 20 passi in memoria occupi 4Mb non compressi. Se li
comprimi con un flusso zip in memoria saranno si e no 150 kb ed hai
memorizzato tutto (poco lavoro = Pochi errori).

 qualche consiglio in alternativa?
Secondo me non sono i singoli oggetti che compongono il documento a dover
memorizzare la loro storia precedente. Una soluzione piu' generale puo'
essere questa:
Per ogni documento hai uno stack, inizialmente vuoto, e naturalmente uno
stack pointer SP. Ogni entrata dello stack contiene due campi che chiamero'
REDO e UNDO.
Quando l'utente esegue una azione (aggiunge un oggetto, muove un oggetto,
ecc.) questa azione la traduci in un comando opportunamente codificato e
metti questo comando nel campo REDO in cima allo stack; inoltre metti nel
campo UNDO il suo inverso.
Esempio: l'utente afferra l'oggetto numero 123 e lo sposta a destra di 50
pixel. Il comando da mettere in REDO e' "SPOSTA 123 dx=50" mentre nel campo
UNDO metti "SPOSTA 123 dx=-50".
Se l'utente seleziona Edit:Undo tu esegui il comando UNDO in cima allo stack
e decrementi SP (lo stack e' sicuramente non-vuoto perche' altrimenti avresti
dovuto disabilitare l'opzione Undo nel menu). Se l'utente esegue Edit:Redo
tu incrementi SP ed esegui il comando REDO (l'entrata nello stack esiste
sicuramente perche' altrimenti l'opzione Redo del menu dovresti renderla
inattiva).
Riguardo alla codifica dei comandi, si possono inventare cose complicate,
ma delle banali stringhe potrebbero essere la cosa piu' semplice e potente,
usando un meta-linguaggio di tua invenzione. Questo renderebbe il programma
"scriptabile".
Ciao,
 ___ 
/_|_\  Umberto Salsi
\/_\/  
www.icosaedro.it

 funziona sempre, serve poco codice e puoi usare il disco come swap.
E come fai se lo stato di quell'oggetto è enorme con dipendenze su altri
oggetti? Se c'è condivisione di stato? Non credo che la tua idea sia
materialmente praticabile in un contesto complesso
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 materialmente praticabile in un contesto complesso
E come fai se non si può fare ?
Ma guarda che discorsi... è solo una idea buttata lì senza conoscere
il progetto.

 il progetto.
Guarda che mica ti stavo criticando. Cercavo di capire cosa intendessi
fare in quel tipo di situazioni.


Se il file sul quale conservi le informazioni non ha "grosse" dimensioni,
il sistema piu' semplice ed efficace e' di salvare tutto il file e 
rileggerlo.

 il sistema piu' semplice ed efficace e' di salvare tutto il file e 
sticazzi, soluzione elegantissima e performante direi... :)
-- 
Complimenti, il futuro del progetto Dharma e' nelle vostre mani.
Namaste' ...e buona fortuna.

 ha scritto nel messaggio 
news:epddq3$r3k$1...@news.task.gda.pl...

Tu continua a farti le seghe mentali e buttare tempo in algoritmi.
Io produco 

 Io produco 
Cit.: classico programmatorucolo nell'italietta.
-- 
Salvatore Iovene
http://www.iovene.com/

 Io produco 
pure io, ma un po' meglio.


http://www.codeproject.com/docview/undo.asp

 Salve a tutti,
cavoli !
sei riuscito a tenerlo lontano da giorni
felice_pago
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 sei riuscito a tenerlo lontano da giorni
ROTFL !!!
risponde ad ogni post di cazzate, e l' unica volta che gli chiedono 
direttamente una cosa quasi in topic scappa per giorni :))))


 direttamente una cosa quasi in topic scappa per giorni :))))
Beh, non è che avessi chiesto *a lui*, ma da quanto ho capito è l'unico 
che lavora in un ambito un minimo "vicino" al mio.
Ciao,
Giulio