Dilema - obrada podataka na klijentu ili serveru

[conica]

Situacija:
U extranet sistemu administrator "kreira" sastanak. Unose se osnovni podaci, fajlovi itd.
Potrebno je implementirati sistem dozvola pristupa korisnicima.
U sistemu postoje organizacije, pod-organizacije i user grupe.

Korisnik uvek mora da bude clan neke organizacije.
Korisnik moze da bude clan jedne ili vise organizacija i/ili pod-organizacija.
Korisnik moze da bude clan neke user grupe.
Broj korisnika u bazi - ~1000

Prilikom definisanja pristupa, administrator odabira (check box) organizaciju, pod-organizaciju i/ili user grupu (u daljem tekstu OPG) ciji clanovi ce imati pristup podacima sa sastanka. Osim toga, postoji i select box (moguca implementacija multiple select-a) pojedinacnih korisnika (situacija kada administrator konkretno zna osobu koja treba da ima pristup i kada je broj takvih osoba mali).
Odabrani korisnici prikazuju se svaki sa svojim check box-om na spisku - postoji mogucnost da se od-cekiranjem nekog korisnika on skine sa spiska.

Dilema:
SITUACIJA1 - OBRADA PODATAKA NA KLIJENTU - prilikom ucitavanja strane, ucita se kompletan spisak korisnika u niz A i cuva se u globalnoj varijabli.
1. Prilikom svakog cekiranja neke OPG, obradjuje se niz A i kreira se niz B koji predstavlja samo odabrane korisnike. Prikazuje se spisak odabranih korisnika. Azurira se select koji sadrzi sve neodabrane korisnike iz OPG.
2. Prilikom od-cekiranja nekog korisnika sa spiska, OPG kojoj on pripada ostaje cekiran ali je tekst sive boje (promena klase). Spisak se automatski azurira (korisnik se skida sa spiska).
3. Prilikom odabira pojedinacnog korisnika iz select-a, korisnik se automatski dodaje na spisak (obradjuje se niz A i azurira se niz B) i automatski se prikazuje na spisku.
4. Prilikom naknadnog cekiranja (od-cekiranja) OPG, obradjuje se A i azuriraju niz B i select box.

SITUACIJA2 - OBRADA PODATAKA NA SERVERU - niz A predstavlja vrednost hidden polja u kojem se cuva spisak odabranih korisnika putem cekiranja OPG. Niz B predstavlja vrednost hidden polja u kojem se cuvaju korisnici uneti preko select box-a (pojedinacni korisnici).
1. Prilikom svakog cekiranja (od-cekiranja) neke OPG, odlazi se na server i salje se id cekiranog (od-cekiranog) OPG i elementi niza A i B. Vraca se novi niz A sa unikatnim vrednostima i modifikovani niz B (ukoliko se putem selecta uneo korisnik koji se nalazi u novo-cekiranoj OPG, on se skida sa niza B i smesta u niz A). Azurira se select koji sadrzi sve neodabrane korisnike iz OPG.
2. Prilikom od-cekiranja nekog korisnika sa spiska, ostaje se na klijentu, azurira se niz A i niz B, azurira se spisak, select box i menja se klasa OPG kojoj pripada.
3. Prilikom odabira pojedinacnog korisnika iz select-a, ostaje se na klijentu, azurira se niz B, select box, spisak i menja se klasa OPG kojoj pripada.
4. Prilikom naknadnog cekiranja (od-cekiranja) OPG, ponavlja se opcija 1. odnosno odlazi se na server i vrsi obrada.

E SAD....
ako postoji elegantniji nacin, slobodno ga predlozite (posto sam gotovo sigurna da postoji)
I GLAVNO PITANJE: koja situacija je brza i jednostavnija za administratora.

[Pedja]

Ja sam uvek za to da posao radi server a da se klijent bavi samo prikazom...

[dee]

Originalno napisao Pedja

Ja sam uvek za to da posao radi server a da se klijent bavi samo prikazom...

nacelno da, al lici na puno mucenja i servera i admina koji radi da se za svaki check cima server.

zasto ne otprilike ovako:

- ucitavanjem stranice, na klijentu postavis za svaku organizaciju/podorganizaciju/usergrupu po jedan niz + niz svih korisnika
- clanovi niza su useri koji pripadaju toj OPG -> neki_opg[n] = userN
- prilikom (od)chekiranja bilo koje OPG/usera dodajes/brises neki_opg[n]
- nakon sto se sve odradi -> submit na server

[misk0]

Dilema. Buduci da su administratori osobe od povjerenja, slanje svih podataka k njemu ne bi trebalo narusiti sigurnost, ali opet ako nije potrebno - izbjegavati - svesti rizik na minimum. Osim toga, administratora nema 1000 pa da to nesto posebno opterecuje server i u slucaju kad bi se sve odradjivalo na serveru. Ja bih to uradio na serveru - laksa manipulacija podataka, imas server side jezik a ovamo se moras zezati sa Javascriptom (ako sam dobro skontao tehnologije koje se koriste).

[cvele]

Moj predlog bi bila kombinacija. Odnosno predlozio bih ti da podatke o izabranim korisnicima drzis u sesiji.
Na strani na kojoj ti je interfejs, za svaki checkbox (select, whatever) implementiras ajax poziv koji na promenu vrednosti salje(ajax) podatke skripti koja osvezava sesiju. Sama organizacija niza unutar sesije je nebitna.
Na "submit" svega, sledeca strana je svesna osvezene sesije i mozes da obradjujes podatke prosledjene preko sesije.

[conica]

mda...izgleda da ce biti kombinacija obrade na serveru i javascripta (ajax)

@Pedja, @mishk0: kompletna obrada na serveru mi je malo rizicno posto moze da se desi sledeca situacija: pre momenta cekiranja neke OPG admin ne zna koje sve osobe joj pripadaju. Cekirace neku OPG koja recimo ima 40 clanova - ide se na server, pokupi se spisak i prikazuje se adminu (svako ime sa svojim cekiranim boxom). Onda treba da odstrani recimo 10 ljudi, i sa svaki check se opet ide na server. Onda se seti da mu treba jos neki OPG, i opet se ide na server i opet se sve ponavlja. Zatim mu ipak ne odgovara prvi cekirani OPG, ide na server i opet azurira spisak. Dodaje usera iz selecta i opet na server.....
Pod pretpostavkom da je administrator extranet-a idiot (ne u pogrdnom znacenju, vec da bi se istakla obaveznu "idiotproof" karakteristiku aplikacije), ovakvih smorova moze da bude previse.

@dee: ovo bi bila varijacija situacije 1 koju sam opisala. Problem je sto jedna osoba moze a ne mora da pripada vise OPG. To znaci da bi za svako odcekiranje boxa osobe, morala da prevrtim svaki taj niz (vec sada imam oko 40 organizacija clanica, 5 pod-organizacija i 15 user grupa). Tu mi je bila dilema kod te situacije koliko cu da smorim klijenta, odnosno koliko ce biti opterecen.

@cvele: pojasni malko

Za sada mi je favorit opcija kada:
1. operacije koje treba da vrate spisak korisnika saljem na server (cekiranje / odcekiranje OPG-a)
2. operacije koje inicira neka funkcija pojedinog korisnika radim na klijentu.
Recimo - ako id check box-a u spisku korisnika ne sadrzi samo njegov id vec recimo a[,a1,a2]-b[,b1.b2]-c[,c1,c2]-d, gde su a - id organizacije, b - id podorganizacije, c - id user grupe i d - id korisnika, onda bih promene klase i cekiranja (odcekiranja) OPG mogla da radim klijentski.

[MrSteel]

koliko sam ja radio web aplikacije, a jesam dosta izracunavanje na strani servera koje zahteva excel tip obrade podataka, dakle promena vrednosti odmah rezultuje promenom neke druge vrednosti na stranici ajax ne dolazi u obzir

bullet time effekat, vreme kao da staje na sekundu ili par sekundi i nastavlja
jednostavno dok ti posaljes serveru i sacekas odgovor interakcija se izgubi
najbolje da probas ali ja sam se jednom prevario i vise nikad

ja govorim iz iskustva samo o racunanju i slicnim rabotama, ovo oko logovanja ako je samo to sa nizovima potrebno i nije ti potreban rezultat odmah onda moze i ajax

mozda ce nekad da pomogne ovaj moj savet

[conica]

@MrSteel: naravno da znaci ovo sto si napisao iz iskustva. Evo konkretno zasto: sada je implementacija ovog dela realizovana u tabovima. u prvom tabu je odabir organizacije, u drugom podorganizacije, u trecem user grupe dok je u cetvrtom spisak odabranih korisnika i select box sa navedenim neodabranim korisnicima.
Bilo koji odabir u prva tri taba moze da tolerise sekund delay da se populise spisak i azurira select, posto cetvrti tab nije vidljiv vec treba da se klikne na njega, ali bilo kakva operacija u cetvrtom tabu bi zahtevala rad bez zastoja - konkretno, odcekiranje nekog korisnika bi zahtevalo da se on momentalno skine sa list i da se pojavi u selectu, dok bi odabir u selectu opet zahtevao njegovo momentalno ubacivanje na spisak.