18. 08. 2009. | #1 |
Ivan Dilber
Sir Write-a-Lot
|
Undo umesto Are you sure?
hteo bih da na novom projektu, poput gmaila, umesto dosadnih pitanja "Are you sure?" za akcije poput delete, omogucim da se akcija odmah izvrsi, ali da postoji i Undo opcija za slucaj greske.
Jel radio neko nesto tako? Kako najlakse implementirati ovako nesto u backend, da li postoji neka varijanta pametnija od klasicnog pristupa sa "deleted" flagom u bazi, i nekim cron jobom koji jednom dnevno pobrise sve markirane postove?
__________________
Leadership is the art of getting people to want to do what you know must be done. |
18. 08. 2009. | #2 |
Vladan Zirojević
Grand Master
|
Na jednom projektu davno sam pravio nesto slicno. Ne sjecam se svih detalja, ali je rjesenje bilo tako da je postojala tabela "recycle_bin" i u njoj polja id, datum brisanja, tip podatka (u smislu "post", "category", "media"...) i ko ga je obrisao... mozda i jos nesto. I naravno serijalizovani podaci koji se brisu.
Kada se brise, podaci se samo smjeste u tu tabelu i obrisu iz originalne/originalnih, a svaki objekat je imao metodu on_delete koji je tacno znao sta treba da radi prilikom brisanja svojih podataka, uz neophodne provjere. Kada se vraca iz korpe nazad, zavisno od sacuvanog tipa poziva se odgovarajuci on_undelete metod koji zna sta treba da uradi da bi iz korpe vratio podatke. Opet uz neke provjere. I na kraju par nekih stvari za odrzavanje tih podataka, kao brisanje cijele korpe, brisanje korpe samo za datog korisnika itd... To je OK radilo... |
19. 08. 2009. | #3 |
expert
Grand Master
|
nezgodan i lep task
mozda generirati obratne SQL-e? ukoliko user uradi 'move to folder' sto je (recimo) promena folder_id u bazi sa 3 na 5, onda da recycle bin sadrzi ID akcije i sql koji treba uraditi da bi se ponistila akcija (update sa 5 na 3) ovo nije bas zgodno ukoliko su neke akcije nadovezane, ali pri kratkim undo, bi trebalo biti ok |
19. 08. 2009. | #4 |
Goran Pilipović
Sir Write-a-Lot
|
Kada imaš nevezane stavke, onda nije problem. Recimo neke komentare na blogu ili nešto slično. Nastaje problem ako imaš više vezanih record-a.
Recimo, kada treba da obrišeš temu na forumu, normalno je da se obrišu i svi upisi u tabelu postova. Ako uradiš "undo" za tabelu gde su teme, oni postovi i dalje ostaju obrisani i tema je prazna. Tako bi onda trebao da napraviš neki grupni undo, da kada se vrati tema - da se vrate i svi obrisani postovi. Ja tu nemam pametno rešenje. A za ovaj "jednostavan" slučaj, imam tabelu trash u kojoj čuvam ceo objekat koji de obrisan, tip objekta, ko je obrisao, i kada. Pa kada neko gleda trash i uradi "undelete" pročitam koji je objekat bio i ponovo upišem taj record tamo gde je stajao. A namešten je cron da svaki dan briše iz "trash" tabele sve što je starije od 30 dana.
__________________
Goran Pilipović a.k.a. Ugly Fingers Bradley f.k.a. bluesman I don't always know what I'm talking about but I know I'm right! |
19. 08. 2009. | #5 | |
Vladan Zirojević
Grand Master
|
Citat:
Edit: Ako nije neophodno, svakako izbjeći složene akcije. Npr. ne daš da se obriše kategorija u kojoj ima postova. "Rekurzija" mi uvijek diže alarm u glavi. Poslednja izmena od zira : 19. 08. 2009. u 20:00. |
|
19. 08. 2009. | #6 |
dinosaurus
Master
Datum učlanjenja: 29.12.2005
Lokacija: Nova Engleska
Poruke: 636
Hvala: 79
263 "Hvala" u 66 poruka
|
Generalno se za "Undo" operacije koristi "Memento": http://www.oodesign.com/memento-pattern.html
|
19. 08. 2009. | #7 |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
Ja ipak glasam za "delete" flag. Ili eventualno malo poboljšanu verziju, gde je delete flag zapravo spoljni ključ na tabelu koja sadrži dodatne informacije o brisanju (tipa timestamp - da bi janitor cronjob znao šta da briše, eventualno id korisnika koji je izvršio brisanje), ili, još generalnije, na tabelu akcija.
Posebna tabela u koju se smeštaju obrisani objekti mi je skroz ružno rešenje, zbog normalizacije... @DT: Ovaj OO patern je zgodno znati, ali mislim da je ivanhoe mislio na ono što bi trebalo da se desi ispod haube... Poslednja izmena od jablan : 19. 08. 2009. u 21:03. |
19. 08. 2009. | #8 | |
dinosaurus
Master
Datum učlanjenja: 29.12.2005
Lokacija: Nova Engleska
Poruke: 636
Hvala: 79
263 "Hvala" u 66 poruka
|
Citat:
Konkretno, verovatno bi dodavali po rekord u nekoj "memento" tabeli kad god dođe do neke akcije koja menja stanje objekta (šta god da je u pitanju) i kad dođe do "undo" akcije pročitamo vrednost poslednjeg mementa i rekreiramo stanje pre poslednje korisnikove akcije. Pošto se radi o PHPu koji ne poznajem, bojim se da ne mogu da idem dublje ispod haube |
|
19. 08. 2009. | #9 |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
Ma sve je to ok, ali uzmi za primer baš brisanje. Šta bude sa objektom? Ako ga zaista brišemo, memento objekat nam nije od velike koristi. Ako ga ne brišemo (u smislu uništavanja instance), nekako moramo svetu da stavimo do znanja da je obrisan.
I šta je zapravo memento tabela? Kakvu strukturu ima? Da li se koristi posebna memento tabela za svaku klasu Originator objekta? Itd itd... |
19. 08. 2009. | #10 | |
dinosaurus
Master
Datum učlanjenja: 29.12.2005
Lokacija: Nova Engleska
Poruke: 636
Hvala: 79
263 "Hvala" u 66 poruka
|
Citat:
Pre brisanja, stanje "Inbox" objekta je: poruka 1. poruka 2. poruka 3. Kad korisnik izbriše poruku 2., kreiramo memento koji upamti da smo imali poruke 1, 2 i 3. Sad je stanje Inbox-a (obrati pažnju da poruku 2 fizički uopšte ne brišemo): poruka 1. poruka 3. Onda korisnik kaže: "uh, zeznuo sam se" i pritisne Undo. Pogledamo poslednji memento, vidimo da očekujemo poruke 1, 2 i 3, generišemo nov momento sa stanjem poruka 1 i 3 i Inbox izgleda opet: poruka 1. poruka 2. poruka 3. Provereno radi Poslednja izmena od Dragi Tata : 19. 08. 2009. u 22:08. |
|
|
|
Slične teme | ||||
Tema | Početna poruka teme | Forum | Odgovori | Poslednja poruka |
Pauk umesto duga | blogowski | Opušteno | 6 | 15. 11. 2008. 16:47 |
output u promenljivu umesto na stdout | japan | PHP | 3 | 09. 08. 2007. 17:56 |
Umesto tag-a H, slika | blogowski | (X)HTML, JavaScript, DHTML, XML, CSS | 13 | 11. 05. 2006. 12:59 |
Šta umesto tabela da koristim? | presretach | Web design, Layout, User Interface | 14 | 07. 01. 2006. 12:43 |