|
Šta se dešava kada u inbox-u stoje poruke:
poruka 1 poruka 2 ... poruka 3749 pa onda obriše poruku 2 (kreira se memento) pa onda obriše poruku 37 (kreira se memento? Šta je sa prethodnim? Ovaj ga prepiše?) pa onda obriše poruku 381 (?) Da li postoji mogućnost višestrukog undo? Ako sam dobro razumeo to je undo samo za poslednju akciju? Ja sam više govorio o mogućnosti gde imaš neki "recycle bin" kao na desktopu, pa možeš u nekom trenutnku da vratiš šta god hoćeš a ne samo poslednju akciju... moja greška. |
Ne brišu se, nego imaš stek (ili tabelu) mementoa.
Npr. Stanje u trenutku 1: Inbox: Poruke 1, 2, 3, 4. Memento stek (ili tabela, štali): prazan Stanje 2 - izbrisana poruka 2 Inbox: Poruke 1, 3, 4. Memento: Memento1(Inbox: 1,2,3,4) Stanje 3 - izbrisana poruka 3 Inbox: Poruke 1, 4 Memento: Memento1(Inbox: 1,2,3,4), Memento2(1, 3,4) E sad, udarimo Undo. Recimo da (jednostavnosti radi) ne podržavamo Redo, inače bi kreirali nov memento i turili ga u redo stek. Pogledamo poslednji Memento - Memento2 i na osnovu njega kreiramo sledeće stanje: Stanje 4 - Undo Inbox: Poruke 1, 3, 4. Memento: Memento1(Inbox: 1,2,3,4) Opet undo? Može. Opet pogledamo poslednji (tj jedini) Memento - 1. Stanje 5 - drugi undo Inbox: Poruke 1, 2, 3, 4. Memento: prazan |
Nemam pojma... meni deluje da to nije za zahtevnije ili komplikovanije stvari, naročito sa više usera. Suviše dodatnih stvari se radi (i troši space i time) zarad jednog relativno jednostavnog feature. Reče čovek da radi nešto "poput gmaila", mislim da je to uvaj memento pattern loš(ije)e rešenje.
|
^Slažem se.
Nemanja, pa to stvarno izgleda naopako :)) Svaki put kada neko obriše jednu poruku, ti zapisuješ komplet stanje pre. Pa šta ako imaš inbox sa 100,000 poruka? Nije li jednostavnije u taj memento zapisati ono što je obrisano? I kad radiš undo samo ideš redom unazad po toj tabeli i poruke opet markiraš kao "vidljive" u inboxu.. |
Verujte mi da su u praksi većina undo sistema zasnovana na mementu. E sad, varijanta koju sam opisao (sa potpunim stanjem) je najjednostavnija i najskuplja; uvek možeš da čuvaš diff umesto kompletnog stanja kad to ima smisla.
|
hmm, ako se cuva samo diff, to se onda svede manje vise na ovo sto su zira i blues opisali, recycle bin tabela, zar ne?
@jablan: to sa spoljnim kljucem ka recordu gde su detalji o brisanju mi se svidja, cini mi se kao najjednostavnije resenje. Nekako mi se cini kao nepotreban posao da premestam podatke iz jedne tabele u drugu ako mogu samo da update-ujem jedno polje umesto toga. Plus ovako sa delete flagom ne moram da se mucim da zadrzim ref. integrity, odnosno ne moram da brinem o premestanju celokupnog relacionog stabla u drugu tabelu, nego samo markiram record ili vise njih kao obrisane, i iskljucim ih po tom uslovu iz bitnih selecta. Vracanje neke strukture nazad mi deluje kao velika glavobolja, radje se ne bih petlja sa tim... Hvala svima na idejama :) |
Citat:
Ono o čemu se ovde (bar mi se čini) govori, je druga situacija - originatora je mnogo, zapravo svaki red svake tabele može biti originator i onda se situacija dosta komplikuje jer imaš dve mogućnosti - ili da praviš neku generičku tabelu za mementa u koju ćeš smeštati neke serijalizovane podatke o izmenama (što je blagi užas za kodiranje), ili ćeš imati po jednu memento tabelu za svaku klasu originatora, što je blagi užas za održavanje. Opet da naglasim, sve ovo pričam ne iz iskustva, već iz spekulacije. A poslednji put kad sam radio nešto slično (CMS), svi objekti su bili nasleđeni iz neke osnovne klase, i imali smo relativno jednostavan recycle bin. |
Citat:
|
| Vreme je GMT +2. Trenutno vreme je 11:25. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.