Cum s-ar putea implementa un sistem de Undo?

Pentru că utilizatorul nu trebuie pedepsit, un sistem de Undo mi se pare mult mai ok decât un confirm delete? yes/no.

La un sistem backend să zicem că merge cu o coloană extra în sql pentru status iar un „delete” nu va face decât să schimbe statusul, nu să șteargă efectiv (iar ștergerea s-ar întâmpla săptămânal sau lunar cu un cron). Dar cum tratăm cu utilizatorul?

Acum câteva luni am făcut un astfel de sistem într-un mod foarte simplu: elementul din DOM ce urma a fi șters îl clonam, îl puneam într-un array, abia apoi îl ștergeam. La undo pur și simplu îl luam din array și îl puneam înapoi în DOM. Probleme?

  • Aveam un număr limitat de elemente (între 8 și 12). Cu multe elemente (să zicem peste 100) cred că ar fi fost probleme mari de performanță
  • Evident, acest sistem nu avea nici o persistență: un refresh (fără salvare) ar fi pus elementele șterse la loc; după ce se salva nu mai exista nici un Undo

Ceva idei despre cum s-ar putea implementa într-un mod ok (indiferent dacă site-ul folosește un framework gen Angular, Backbone etc)

1 Like

un sistem undo pentru ce?

Pentru acțiuni destructive (ștergere, mutare etc)

probabil n-ai explicat prea bine. ce treaba ar avea un user sa modifice dom-ul?
dar ai putea incerca cu local storage sau sa salvezi in sesiuni (cu sesiunile ai putina treaba in backend)

Soft delete din Eloquent ORM(Laravel related) face o treaba destul de buna.

@alescx: am explicat cum funcționează, nu ce face userul per se.

@IonutBajescu: interesant, mulțumesc.

pai atunci poti face cum am spus. local storage sau sesiuni pe server. n-are rost sa bagi nimic in db pentru undo

Nu am facut un astfel de sistem, cum as proceda:

  1. Folosirea functionalitatilor din ORM, exemplu pentru Doctrine2
    https://github.com/simplethings/EntityAudit
    Permite salvarea mai multor versiuni inclusiv revenirea la oricare dintre ele.
    Se poate rezolva si la nivel de mysql prin triggere pe operatiunile distructive (ex. http://www.jasny.net/articles/versioning-mysql-data/)

  2. Daca e vorba de revenire o singura versiune inapoi cred ca as stoca penultima versiune sub forma unui obiect serializat si la nivel de db stochez tot timpul ultima versiune a datelor.

1 Like

asta e ‘holy grail’-ul UX-ului.

foarte simplu pt utilizator, foarte complicat pentru programator.

cu cat sistemul este mai complex si legaturi mai multe prin baza de date, cu atat e mai complicat de implementat. Plus ca daca faci undo si intre timp ai niste evenimente care ti-ar fi afectat datele la care ai dat undo, se complica treaba nasol. E fucked up.

1 Like

Pentru Undo / Redo eu consider cele mai utile urmatoarele:

  1. Arhitectura bazata pe tranzactii, nu pe date concrete (de exemplu cum sunt toate softurile bancare si majoritatea celor financiare). Aceasta arhitectura permite revenirea in timp la orice moment din istoria sa. Se poate aplica la nivel mai redus pentru aplicatii mai mici, introducand conceptul de tranzactii doar la nivelul actiunii userului unde se doreste Undo / Redo.

  2. Este un design pattern special conceput din problema de Undo / Redo numit Command Pattern. In cartea de patterns a lui Uncle Bob este si un exemplu cu Undo / Redo, dar presupun ca se gaseste si pe net.

3 Likes

Poti sa-mi dai o referinta, te rog?

1 Like

cam asta e ideea, dar si aici poate fi complicata treaba, ca ok, tu tii tranzactia si faci commit cu delay, dar pana faci commit la tranzactia respectiva, s-ar putea sa se intample altele ale caror date sunt implicate in tranzactia initiala.

cum am zis, e destul de spinoasa problema.

A… nu prea. Nu sunt nici eu foarte familiar cu tema. Incearca pe goodle “Transactional architecture” or “Event based systems”

Hmda … complexitatea ramane. Arhitectura tranzactionala sau bazata pe evenimente poate sa ajute reducand complexitatea doar intr-o oarecare masura.