DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   Undo umesto Are you sure? (http://www.devprotalk.com/showthread.php?t=7773)

ivanhoe 18. 08. 2009. 15:15

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?

zira 18. 08. 2009. 15:26

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...

robi-bobi 19. 08. 2009. 17:20

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

bluesman 19. 08. 2009. 17:33

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.

zira 19. 08. 2009. 20:57

Citat:

Originalno napisao bluesman (Napišite 72417)
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.

Može i to, samo za svaki trash record čuvaš i id trash akcije/recorda koja ga je eventualno implicitno izazvala. Tako uz nešto rekurzije možeš da vratiš i složene strukture tipa kategorije sa postovima unutar nje. Sve zavisi do kog stepena hoćeš i trebaš da napraviš tu funkcionalnost :)

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.

Dragi Tata 19. 08. 2009. 21:03

Generalno se za "Undo" operacije koristi "Memento": http://www.oodesign.com/memento-pattern.html

jablan 19. 08. 2009. 22:01

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... ;)

Dragi Tata 19. 08. 2009. 22:27

Citat:

Originalno napisao jablan (Napišite 72432)
@DT: Ovaj OO patern je zgodno znati, ali mislim da je ivanhoe mislio na ono što bi trebalo da se desi ispod haube... ;)

Patterne smatram korisnim jedino u smislu komunikacije. U ovom slučaju, princip je da kad god dođe do izmene stanja objekta za koji želimo da implementiramo, napravimo poseban "memento" objekat koji čuva stanje onog glavnog objekta i onda lako možemo da restauiramo bilo koje stanje tog objekta.

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 :)

jablan 19. 08. 2009. 22:43

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...

Dragi Tata 19. 08. 2009. 23:05

Citat:

Originalno napisao jablan (Napišite 72435)
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.

Nema veze koja operacija je u pitanju. Memento omogućava da restauiramo stanje objekta po želji. Ako baš hoćeš brisanje, evo primera.

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 ;)


Vreme je GMT +2. Trenutno vreme je 11:44.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.