Dilema - obrada podataka na klijentu ili serveru

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