Za postavljanje slika na net za sada je Google-ovo resenje, koje se zove Picasa, po meni najbolje. Iako je resenje "matoro", ljudi koji rade na njemu doprinose njegovom poboljsanju dodavajuci stalno nove mogucnosti, a da se pritom jednostavnost celog servisa ne gubi.
Dovoljno je da imate Google nalog (gmail) i da odete na http://picasaweb.google.com. Vase slike ce se nalaziti na http://picasaweb.google.com/vasGoogleNalog.
Kada podizete vase slike (link Upload) bicete prvo upitani da otvorite novi album (ako ne posedujete nijedan) ili da izaberete neki od postojecih. Album moze biti public (javni, svako ga vidi i svako moze doci do njega pretrazivanjem Picase) i private (samo vas, "nevidljiv" je za sve ostale korisnike). Nakon odabira/kreiranja albuma ce vam se otvoriti stranica na kojoj mozete podici maksimalno 5 slika istovremeno. Posto postavljate samo najbolje i izabrane fotke, mislim da je prostor koji vam nudi Picasa od 1 GB sasvim dovoljno.
Za mene je najveca prednost Picase je sto imate sliku u originalnoj velicini koju kasnije moze svako preuzeti.
Sto se tice "dizanja" fotki, postoji i elegantnije resenje u vidu aplikacije koja se zove Picasa (foto browser) i koja vam omogucava da postavite slike u vas album direktno sa vaseg racunara jednim klikom. Ovim putem se fotke podizu brze i imate mogucnost automatskog menjanja velicine fotografije na neku pristojnu rezoluciju, recimo 1600x1200.
Ali, sad jedno prakticno pitanje. Sta ako zelim da moje slike vide samo odabrani ljudi?
Resenje je da se logujete i da otvorite vas album. Videcete da je adresa (URL) tipa http://picasaweb.google.com/vasGoogleNalog/MojAlbum?authkey=ABCDEFGH#
Ovaj link posaljite na email ljudima za koji zelite da vide vase fotke bez potrebe da se loguju na Google.
Kvaka je u ovom "authkey". Ako toga nema, Google ce prijaviti da stranica ne postoji. Po meni ovo resenje je zaista prakticno i jos jedan razlog vise za koriscenje Picase.
Wednesday, September 10, 2008
Monday, September 8, 2008
Vasa (i njihova) sigurnost
Sve vise sajtova na Internetu zahteva vasu registraciju kako biste pristupili nekom sadrzaju ili uradili neku "akciju" (npr. slanje komentara). Svaki ovakav sajt treba da ima opciju "zaboravljene lozinke". Ovaj sistem se svodi na to da se korisniku koji je zaboravio lozinku posalje ista (postojeca ili nova automatski generisana) na e-mail adresu ili da mu se posalje link na kome se vrsi "resetovanje" (ponovno kreiranje) lozinke takodje na e-mail.
Od ova tri sistema i dalje se koristi prvi, koji je bio medju prvima i najprikladinij za "nove surfere". Medjutim, kako je rastao Internet, rastao je i rizik od namernih upada u sisteme, rusenje i/ili blokiranje sajtova, preuzimanje baze podataka i sl. Iz ovog razloga se danas sve (ili barem vecina) lozinke sifruju (enkriptuju) i takve se cuvaju u bazi podataka.
Radi se o tome da vama niko ne garantuje za sigurnost vase loznike za pristup sajtu jer ako neko pristupi bazi podataka (sto opet niko ne moze da garantuje) gde se lozinke cuvaju u citljivom formatu, svi korisnici su kao na "tacni".
Drugi nacin je da se loznika enkriptuje i takva da se cuva. Kada korisnik zahteva svoju lozinku, ona se dekriptuje i salje u email poruci takodje citljiva. Ovde sledi i jedna druga sigurnosna rupa a to je trasfer citljivih podataka kroz Internet. No, ovo cemo ovoga puta zaobici.
Treca opcija je najsigurnija od svih navedenih. Loznika se cuva u enkritpovanom formatu koji nije moguce (ili je moguce vrlo tesko) dekriptovati, a pri zahtevu za njenu promenu se salje samo link ka web stranici na kojoj se menja lozinka. Iako i ovde postoji navedena sigurnosna rupa (link je opet otvoren za usputno citanje), ovo se izbegava time sto se na stranici na koju link vodi zahteva unos korisnickog imena ili pak email adrese kako bi se mogao nastaviti proces izmene lozinke.
Dakle, zbog vaseg mirnog sna i poverenja drugih u vas, toplo vam preporucujem ovo resenje.
Iako vecina korisnika nije ovoga svesna, vi koji pravite bilo kakav sigurnosni "sistem" (makar se bazirao samo na autentikaciji tj. user/pass) bi trebalo da budete.
Od ova tri sistema i dalje se koristi prvi, koji je bio medju prvima i najprikladinij za "nove surfere". Medjutim, kako je rastao Internet, rastao je i rizik od namernih upada u sisteme, rusenje i/ili blokiranje sajtova, preuzimanje baze podataka i sl. Iz ovog razloga se danas sve (ili barem vecina) lozinke sifruju (enkriptuju) i takve se cuvaju u bazi podataka.
Radi se o tome da vama niko ne garantuje za sigurnost vase loznike za pristup sajtu jer ako neko pristupi bazi podataka (sto opet niko ne moze da garantuje) gde se lozinke cuvaju u citljivom formatu, svi korisnici su kao na "tacni".
Drugi nacin je da se loznika enkriptuje i takva da se cuva. Kada korisnik zahteva svoju lozinku, ona se dekriptuje i salje u email poruci takodje citljiva. Ovde sledi i jedna druga sigurnosna rupa a to je trasfer citljivih podataka kroz Internet. No, ovo cemo ovoga puta zaobici.
Treca opcija je najsigurnija od svih navedenih. Loznika se cuva u enkritpovanom formatu koji nije moguce (ili je moguce vrlo tesko) dekriptovati, a pri zahtevu za njenu promenu se salje samo link ka web stranici na kojoj se menja lozinka. Iako i ovde postoji navedena sigurnosna rupa (link je opet otvoren za usputno citanje), ovo se izbegava time sto se na stranici na koju link vodi zahteva unos korisnickog imena ili pak email adrese kako bi se mogao nastaviti proces izmene lozinke.
Dakle, zbog vaseg mirnog sna i poverenja drugih u vas, toplo vam preporucujem ovo resenje.
Iako vecina korisnika nije ovoga svesna, vi koji pravite bilo kakav sigurnosni "sistem" (makar se bazirao samo na autentikaciji tj. user/pass) bi trebalo da budete.
Monday, July 7, 2008
A sta da stavimo ovde?
"Pa sadrzaj".
Ovo je moj odgovor na pitanje klijenata koje stoji u naslovu kada radim konsalting za SEO (Search Engine Optimization) i promociju web sajta.
Ljudi uglavnom traze da budu dobro pozicionirani na pretrazivacima, a da pritom imaju sajt od 5 strana koji nije azuruiran od kada je postavljen - znaci nikad.
Evo kako to obicno ide u Srbiji. Rekao Mika Ziki "nema te na Googleu, covece". Onda Mika nekako kontaktira mene i kaze "hocu da se pojavim na guglu i koliko ce to da me kosta". Klijenti, ko klijenti, svugde u svetu, teski ko crna zemlja, odmah hoce cenu, a da pritom ne znaju ni sami sta hoce (u vecni slucajeva). Uglavnom se prvo uhvate za reklame sa desne strane Google-a i obicno bude "aaaaa, to se placa, dobro onda nista, da preskocimo to, a kako ja da se pojavim ovde prvi...".
Naravno, dalje sa nastavlja sa zahtevom za pojavljivanje na rezultatima pretrage za odredjene kljucne reci "znas, moj drugar bas onomad gledao, pa mi kaze...". Ovde sledi jedno pola sata objasnjavanja kako to gugl radi i zasto njih nema tu gde oni hoce (i trebaju?!?!) da budu. Uglavnom, posto njima i dalje nista nije jasno, kazem sta mogu da uradim, da prvo ide analiza sajta, konkurencije, trenutna statistika, plan aktivnosti i da za celu stvar treba vremena i da NEMA garancije. Postoje samo ciljevi (goals) ka kojima se stremi, nekad se i dostignu, ali nekad i ne. Ovo uglavnom zavisi od tematike sajta, da li je za "siroke narodne mase" ili usko specijalizovan. Medjutim, sto smo blizi , posao je bolje uradjen. Najbitnije je - pomeriti se.
Izanalizira se sta ima, napise se "akcioni" plan i daju se predlozi, koji i ne moraju da se usvoje, ali svakako ce poboljsati celu stvar. U predlozima uglavnom stoji da se sajt obogati novim sadrzajem. Jednostavno, sajt od 5 stranica (pocetna, o nama, proizvodi, usluge i kontakt) ce "piti vodu" jedno vreme (pogotovo ako je SEO bio nula), ali jednostavno nije odrzivo. Na sadrzaju sajta se MORA raditi. Uglavnom predlazem da se azurira periodicno (u najgorem slucaju jednom u 15 dana) pocetna stranica sa nekim vestima ili novostima, sto moze da uradi i sekretarica. Postoje tu i neki mali trikovi kako da se donekle zeznu roboti kako bi imali utisak da je stranica azurirana, ali ne bih sad o tome.
I, kako to u Srbiji biva, nakon pojavljivanja sajta na Google-u ("ej, nasao me Pera") u 90% slucajeva niko ne azurira sajt (tipa "zasto bih ja polagao vozacki kad nemam auto, a i ko zna kada cu ga imati").
Ovo je moj odgovor na pitanje klijenata koje stoji u naslovu kada radim konsalting za SEO (Search Engine Optimization) i promociju web sajta.
Ljudi uglavnom traze da budu dobro pozicionirani na pretrazivacima, a da pritom imaju sajt od 5 strana koji nije azuruiran od kada je postavljen - znaci nikad.
Evo kako to obicno ide u Srbiji. Rekao Mika Ziki "nema te na Googleu, covece". Onda Mika nekako kontaktira mene i kaze "hocu da se pojavim na guglu i koliko ce to da me kosta". Klijenti, ko klijenti, svugde u svetu, teski ko crna zemlja, odmah hoce cenu, a da pritom ne znaju ni sami sta hoce (u vecni slucajeva). Uglavnom se prvo uhvate za reklame sa desne strane Google-a i obicno bude "aaaaa, to se placa, dobro onda nista, da preskocimo to, a kako ja da se pojavim ovde prvi...".
Naravno, dalje sa nastavlja sa zahtevom za pojavljivanje na rezultatima pretrage za odredjene kljucne reci "znas, moj drugar bas onomad gledao, pa mi kaze...". Ovde sledi jedno pola sata objasnjavanja kako to gugl radi i zasto njih nema tu gde oni hoce (i trebaju?!?!) da budu. Uglavnom, posto njima i dalje nista nije jasno, kazem sta mogu da uradim, da prvo ide analiza sajta, konkurencije, trenutna statistika, plan aktivnosti i da za celu stvar treba vremena i da NEMA garancije. Postoje samo ciljevi (goals) ka kojima se stremi, nekad se i dostignu, ali nekad i ne. Ovo uglavnom zavisi od tematike sajta, da li je za "siroke narodne mase" ili usko specijalizovan. Medjutim, sto smo blizi , posao je bolje uradjen. Najbitnije je - pomeriti se.
Izanalizira se sta ima, napise se "akcioni" plan i daju se predlozi, koji i ne moraju da se usvoje, ali svakako ce poboljsati celu stvar. U predlozima uglavnom stoji da se sajt obogati novim sadrzajem. Jednostavno, sajt od 5 stranica (pocetna, o nama, proizvodi, usluge i kontakt) ce "piti vodu" jedno vreme (pogotovo ako je SEO bio nula), ali jednostavno nije odrzivo. Na sadrzaju sajta se MORA raditi. Uglavnom predlazem da se azurira periodicno (u najgorem slucaju jednom u 15 dana) pocetna stranica sa nekim vestima ili novostima, sto moze da uradi i sekretarica. Postoje tu i neki mali trikovi kako da se donekle zeznu roboti kako bi imali utisak da je stranica azurirana, ali ne bih sad o tome.
I, kako to u Srbiji biva, nakon pojavljivanja sajta na Google-u ("ej, nasao me Pera") u 90% slucajeva niko ne azurira sajt (tipa "zasto bih ja polagao vozacki kad nemam auto, a i ko zna kada cu ga imati").
Tuesday, April 8, 2008
Arhitektura na tri nivoa
Tronivovska arhitektura je poznatija kao "3-tier architecture" (od n-tier) koju je Microsoft prisvojio za web aplikacije koje barataju podacima ciji je izvor i odrediste baza podataka (dakle klijent-server arhitektura), a inace je ideja ziva vec poodavno. Medjutim, Microsot je prvi omogucio da u svom IDE alatu (Visual Studio) vizuleno povezete nivoe koji su do tada bili samo teoretski povezani, a programer je morao da zna sta i odakle poziva.
N-Tier arhitektura ima daleko vise nivoa, ali je arhitektura obicne desktop i web aplikacije svedena na osnovna tri - podaci (data access), logika (bussines logic) i prezentacija (presentation). Koncept se zasniva na tome da svaki nivo radi svoj posao, da je svaki nivo "ucauren" (ko zna sta on radi, prim aut.) i da svaki od njih moze biti koriscen sa vise strana (npr. istu logiku i pristup podacima mogu da koriste web i windows aplikacija) sto omogucava modularnost. Takodje, pri izvrsavanju programa nivoi se ne mogu preskakati (sem u izuzetnim slucajevima) vec proces ide korak po korak (jel to neko pomenuo Windows Workflow Foundation?)
Podaci - U ovom nivou se samo odredjuje pristup podacima i definisu CRUD operacije (CReate, Update i Delete), bilo one store procedure ili zivi upiti. Konekcija na bazu se takodje vrsi iz ovog nivoa. Dakle, bilo sta sto se radi sa bazom podataka se nalazi u ovom sloju.
Poslovna logika - Ovaj sloj definise sta se radi sa podacima koji dolaze/odlaze iz aplikacije/baze podataka. Ispituju se pravila upisa, konvertuju se podaci i jednog tipa u drugi i tome sl. Ovde bi trebala da se nalazi sva pamet aplikacije.
Prezentacija - Ovo je zapravo samo korisnicki interfejs. Znaci prozori i web stranice. Mnogi neiskusni programeri sve strpaju u ovaj nivo tako da se dobijaju "spageti" u kodu i gomila metoda kojima jednostavno tu nije mesto, vec u poslovnom sloju aplikacije.
Kako bi ovo bilo jasnije, postavicu najjednostavniji primer u formi za kreiranje novog korisnika.
- Prezentacija (ono sto korisnik vidi) sadrzi web/winform kontrole, textbox-ove za unos podataka, labele za opise i dugmad (ili samo dugme). Pored ovoga moraju postojati i EventHandler-i, najmanje jedan, za kontrolu dugmeta "Unesi korisnika". Pritiskom na ovo dugme , poziva se metoda iz biznis sloja kojoj se prosledjuju podaci (ime korisnika, lozinka i e-mail adresa) koji su ucitani iz kontrola.
- Poslovna logika je tu da proveri validnost unetih podataka (format e-mail adrese, proveru domena, provera politike za format lozinke i za naziv korisnika) i da doda jos informacija (datum kada je korisnik kreiran, IP adresa, naziv i verzija browser-a i sl.) i neke default vrednosti (broj logovanja, datum poslednjeg logovanja i sl). U ovom sloju se kreira entitet (tj. objekat iz sloja baze podataka) Korisnik koji predstavlja jedan zapis u tabeli Korisnici. Kada se kreira entitet sa svim ispravnim podacima poziva se jedna od CRUD metoda iz najnizeg sloja kome se prosledjuje ceo entitet popunjen podacima.
- Podaci ili sloj baze podataka prihvata objekat (entitet) sa svojim podacima i izvrsava jednu od operacija koja je pozvana - kreiranje, brisanje ili izmena zapisa. Opcionalno moze vracati rezultate izvrsenja opereracije.
Vise o n-tier arhitekturi mozete pronaci na linkovima:
http://en.wikipedia.org/wiki/Three-tier_(computing)
http://www.microsoft.com/belux/nl/msdn/community/columns/hyatt/ntier1.mspx
3-tier Architecture with ASP.NET 2.0
N-Tier arhitektura ima daleko vise nivoa, ali je arhitektura obicne desktop i web aplikacije svedena na osnovna tri - podaci (data access), logika (bussines logic) i prezentacija (presentation). Koncept se zasniva na tome da svaki nivo radi svoj posao, da je svaki nivo "ucauren" (ko zna sta on radi, prim aut.) i da svaki od njih moze biti koriscen sa vise strana (npr. istu logiku i pristup podacima mogu da koriste web i windows aplikacija) sto omogucava modularnost. Takodje, pri izvrsavanju programa nivoi se ne mogu preskakati (sem u izuzetnim slucajevima) vec proces ide korak po korak (jel to neko pomenuo Windows Workflow Foundation?)
Podaci - U ovom nivou se samo odredjuje pristup podacima i definisu CRUD operacije (CReate, Update i Delete), bilo one store procedure ili zivi upiti. Konekcija na bazu se takodje vrsi iz ovog nivoa. Dakle, bilo sta sto se radi sa bazom podataka se nalazi u ovom sloju.
Poslovna logika - Ovaj sloj definise sta se radi sa podacima koji dolaze/odlaze iz aplikacije/baze podataka. Ispituju se pravila upisa, konvertuju se podaci i jednog tipa u drugi i tome sl. Ovde bi trebala da se nalazi sva pamet aplikacije.
Prezentacija - Ovo je zapravo samo korisnicki interfejs. Znaci prozori i web stranice. Mnogi neiskusni programeri sve strpaju u ovaj nivo tako da se dobijaju "spageti" u kodu i gomila metoda kojima jednostavno tu nije mesto, vec u poslovnom sloju aplikacije.
Kako bi ovo bilo jasnije, postavicu najjednostavniji primer u formi za kreiranje novog korisnika.
- Prezentacija (ono sto korisnik vidi) sadrzi web/winform kontrole, textbox-ove za unos podataka, labele za opise i dugmad (ili samo dugme). Pored ovoga moraju postojati i EventHandler-i, najmanje jedan, za kontrolu dugmeta "Unesi korisnika". Pritiskom na ovo dugme , poziva se metoda iz biznis sloja kojoj se prosledjuju podaci (ime korisnika, lozinka i e-mail adresa) koji su ucitani iz kontrola.
- Poslovna logika je tu da proveri validnost unetih podataka (format e-mail adrese, proveru domena, provera politike za format lozinke i za naziv korisnika) i da doda jos informacija (datum kada je korisnik kreiran, IP adresa, naziv i verzija browser-a i sl.) i neke default vrednosti (broj logovanja, datum poslednjeg logovanja i sl). U ovom sloju se kreira entitet (tj. objekat iz sloja baze podataka) Korisnik koji predstavlja jedan zapis u tabeli Korisnici. Kada se kreira entitet sa svim ispravnim podacima poziva se jedna od CRUD metoda iz najnizeg sloja kome se prosledjuje ceo entitet popunjen podacima.
- Podaci ili sloj baze podataka prihvata objekat (entitet) sa svojim podacima i izvrsava jednu od operacija koja je pozvana - kreiranje, brisanje ili izmena zapisa. Opcionalno moze vracati rezultate izvrsenja opereracije.
Vise o n-tier arhitekturi mozete pronaci na linkovima:
http://en.wikipedia.org/wiki/Three-tier_(computing)
http://www.microsoft.com/belux/nl/msdn/community/columns/hyatt/ntier1.mspx
3-tier Architecture with ASP.NET 2.0
Regionalizacija
Ako se zeli regionalizovati ceo sajt potrebno je uneti u web.config sledecu liniju u okviru taga:
...
U ovom slucaju se ignorisu klijentova regionalna podesavanja (enableClientBasedCulture). Atribut culture se koristi za formatiranje datuma, vremena, brojeva, monete i sl. dok se atribut uiCulture koristi za podesavanje korisnickog interfejsa na odredjeni region/kulturu.
Ako se radi u windows aplikaciji, tu je situacija nesto drugacija. Jedno od resenja je da se doda u app.config promenljiva na nivou aplikacije koja ce da ima vrednost kod kulture koji ce se koristiti.
...
...
U kodu za ucitavanje aplikacije se dodaje:
string sCulture = ConfigurationSettings.AppSettings["uiCulture"];
CultureInfo.CreateSpecificCulture(sCulture);
U oba slucaja je podesen region Srbija sa latinicnim pismom.
...
...
U ovom slucaju se ignorisu klijentova regionalna podesavanja (enableClientBasedCulture). Atribut culture se koristi za formatiranje datuma, vremena, brojeva, monete i sl. dok se atribut uiCulture koristi za podesavanje korisnickog interfejsa na odredjeni region/kulturu.
Ako se radi u windows aplikaciji, tu je situacija nesto drugacija. Jedno od resenja je da se doda u app.config promenljiva na nivou aplikacije koja ce da ima vrednost kod kulture koji ce se koristiti.
...
...
U kodu za ucitavanje aplikacije se dodaje:
string sCulture = ConfigurationSettings.AppSettings["uiCulture"];
CultureInfo.CreateSpecificCulture(sCulture);
U oba slucaja je podesen region Srbija sa latinicnim pismom.
Monday, April 7, 2008
GridView dugme u koloni i dodavanje JavaScript-a
Ako ste postavili kolonu koja ima polje tipa dugme (ButtonField) prostoji mala "kvaka" kako uzeti tekst iz nje?
Radi se o tome sto je u ovom slucaju tekst koji se prikazivao u polju zapravo ID zapisa u tabeli. Resenje je dodati u GridView EventHandler na RowCommand, uhvatiti id reda iz GridView-a, zatim prvu celiju (kolonu) i uzeti LinkButton kao prvu kontrolu u celiji i iz njega izvuci tekst.
private void GridView1_OnRowCommand(object sender, EventArgs e)
{
LinkButton btn = (LinkButton) GridView1.Row[Convert.ToInt32(e.CommandArgument)].Cells[0].Controls[0];
Obrisi(btn.Text);
}
Posto ova kolona sadrzi opciju za brisanje, morao sam da dodam i pitanje tipa "Da li zelite brisanje?". Definitivno treba izbeci bilo kakav PostBack makar se radilo i u ASP.Ajax-u. Dakle, treba dodati nekako JavaScript confirm prozor.
Za ovo resenje postoje dve opcije. Jedno je da se dodaje atribut u kontrolu LinkButton pri kreiranju svakog reda ili da se isto ovo dodaje, ali nakon DataBind() metode GridView-a.
Ja sam se odlucio za ovu drugu jer je laksa za implementaciju i ne dodajem nikakav novi event za GridView (neznatno se usporava "punjenje" tabele podacima).
Dakle, kod ide ovako:
...
// punjenje podacima
GridView1.DataSource = podaci.Citaj();
GridView1.DataBind();
DodajAtribut();
...
private void DodajAtribut()
{
foreach(GridViewRow red in GridView1.Rows)
{
LinkButton btn = red[0].Controls[0];
btn.Attribute.Add("onclick", "return confirm('Da li ste sigurni za brisanje?')");
}
}
Kao u prethodnom primeru, uzima se prva kontrola celije i kastuje se u LinkButton. Zatim se na njega dodaje JavaScript u svakom redu tabele sa confirm prozorom (OK i Cancel dugmad) za brisanje.
Radi se o tome sto je u ovom slucaju tekst koji se prikazivao u polju zapravo ID zapisa u tabeli. Resenje je dodati u GridView EventHandler na RowCommand, uhvatiti id reda iz GridView-a, zatim prvu celiju (kolonu) i uzeti LinkButton kao prvu kontrolu u celiji i iz njega izvuci tekst.
private void GridView1_OnRowCommand(object sender, EventArgs e)
{
LinkButton btn = (LinkButton) GridView1.Row[Convert.ToInt32(e.CommandArgument)].Cells[0].Controls[0];
Obrisi(btn.Text);
}
Posto ova kolona sadrzi opciju za brisanje, morao sam da dodam i pitanje tipa "Da li zelite brisanje?". Definitivno treba izbeci bilo kakav PostBack makar se radilo i u ASP.Ajax-u. Dakle, treba dodati nekako JavaScript confirm prozor.
Za ovo resenje postoje dve opcije. Jedno je da se dodaje atribut u kontrolu LinkButton pri kreiranju svakog reda ili da se isto ovo dodaje, ali nakon DataBind() metode GridView-a.
Ja sam se odlucio za ovu drugu jer je laksa za implementaciju i ne dodajem nikakav novi event za GridView (neznatno se usporava "punjenje" tabele podacima).
Dakle, kod ide ovako:
...
// punjenje podacima
GridView1.DataSource = podaci.Citaj();
GridView1.DataBind();
DodajAtribut();
...
private void DodajAtribut()
{
foreach(GridViewRow red in GridView1.Rows)
{
LinkButton btn = red[0].Controls[0];
btn.Attribute.Add("onclick", "return confirm('Da li ste sigurni za brisanje?')");
}
}
Kao u prethodnom primeru, uzima se prva kontrola celije i kastuje se u LinkButton. Zatim se na njega dodaje JavaScript u svakom redu tabele sa confirm prozorom (OK i Cancel dugmad) za brisanje.
Dobra praksa (1)
Ovo je samo deo dobre prakse koju cu kasnije dopunjavati. Vazi za manje-vise sve programske jezike, iako su primeri napisani u C#-u.
Petlje
U pocetku beze samo For...Next, Do..Until i While...Whend. Ove dve poslednje se malo koriste (uglavnom za citanje slogova iz DB set-a, npr. ResultSet-a, RecordSeta...) , ali je usla u "modu" petlja foreach (negde je odvojeno, for each).
U slucaju .NET-a petlja foreach se upotrebljava kada ne vrsimo direktne izmene nad podacima koji se nalaze u kolekciji kroz koju "trcimo", kao npr:
foreach (string korisnik in korisnici)
{
Console.Write(korisnik);
}
U slucaju for petlje, sa podacima se moze manipulisati. Ako se radi brisanje zapisa iz kolekcije koja se cita, praksa je da se nakon brisanja izlazi iz petlje, ili vratiti brojac za jednu vrednost manje.
for(int i = 0; i <>
{
korisnici.RemoveAt(i);
--i;
}
U ovom slucaju je broj elemenata je promenljiv, dok je u sledecem fiksan te je bolje dodati novu varijablu kako se ne bi u svakom ciklusu izracunavala duzina niza tj. broj elemenata u kolekciji.
int limit = korisnici.Length;
for(int i = 0; i <>
{
Console.Write(korisnici[i]);
}
Iako neki programeri imaju naviku da im petlja ide od nazad (brojac se dekrementuje), ovaj pristup odstupa od "prirodnog nacina kretanja", tako da ga ne preporucujem.
EventHandler-i
Metode koje "hvataju" dogadjaje su osnova za interakciju korisnika i aplikacije. Mnogi pocetnici programeri grese, pa u ovim metodama "guraju" citavu logiku i obradu podataka, sto je losa praksa. Treba izdvojiti sve sto nema veze sa dogadjajem i sa njegovim argumentima u posebnu metodu i eventaulno joj proslediti neke parametre iz event-a. Dakle, nesto kao:
private void Btn1_OnClick(object sender, EventArgs e)
{
Radi()
}
Ako od nekog podatka koji je vezan za nosioca dogadjaja zavisi izvrsavanje programa, vrsi se ispitivanje i zatim zove odgovarajuci metod:
private void Btn1_OnClick(object sender, EventArgs e)
{
LinkButton dugme = (LinkButton) sender;
if(dugme.Text == "Cuvaj")
Sacuvaj();
else
Osvezi();
}
Uslovi
Za blokove ili "programski tok" se najcesce povezuju if uslovi. Ono sto je bitno je da se kod if naredbe prvo ispituje poslednji uslov (ako ih ima vise) te ako je "veznik" uslova AND tj && tok programa se nastavlja dalje jer uslov nije zadovoljen.
Takodje, treba obratiti paznju na ispitivanje jednakosti. Naime, brze se izvrsava ispitivanje razlicitosti nego jednakosti, tako da ako nema neke preterane potrebe za jednakoscu (kao u prethodnom primeru) bolje je uzeti u obzir razlicitost.
Petlje
U pocetku beze samo For...Next, Do..Until i While...Whend. Ove dve poslednje se malo koriste (uglavnom za citanje slogova iz DB set-a, npr. ResultSet-a, RecordSeta...) , ali je usla u "modu" petlja foreach (negde je odvojeno, for each).
U slucaju .NET-a petlja foreach se upotrebljava kada ne vrsimo direktne izmene nad podacima koji se nalaze u kolekciji kroz koju "trcimo", kao npr:
foreach (string korisnik in korisnici)
{
Console.Write(korisnik);
}
U slucaju for petlje, sa podacima se moze manipulisati. Ako se radi brisanje zapisa iz kolekcije koja se cita, praksa je da se nakon brisanja izlazi iz petlje, ili vratiti brojac za jednu vrednost manje.
for(int i = 0; i <>
{
korisnici.RemoveAt(i);
--i;
}
U ovom slucaju je broj elemenata je promenljiv, dok je u sledecem fiksan te je bolje dodati novu varijablu kako se ne bi u svakom ciklusu izracunavala duzina niza tj. broj elemenata u kolekciji.
int limit = korisnici.Length;
for(int i = 0; i <>
{
Console.Write(korisnici[i]);
}
Iako neki programeri imaju naviku da im petlja ide od nazad (brojac se dekrementuje), ovaj pristup odstupa od "prirodnog nacina kretanja", tako da ga ne preporucujem.
EventHandler-i
Metode koje "hvataju" dogadjaje su osnova za interakciju korisnika i aplikacije. Mnogi pocetnici programeri grese, pa u ovim metodama "guraju" citavu logiku i obradu podataka, sto je losa praksa. Treba izdvojiti sve sto nema veze sa dogadjajem i sa njegovim argumentima u posebnu metodu i eventaulno joj proslediti neke parametre iz event-a. Dakle, nesto kao:
private void Btn1_OnClick(object sender, EventArgs e)
{
Radi()
}
Ako od nekog podatka koji je vezan za nosioca dogadjaja zavisi izvrsavanje programa, vrsi se ispitivanje i zatim zove odgovarajuci metod:
private void Btn1_OnClick(object sender, EventArgs e)
{
LinkButton dugme = (LinkButton) sender;
if(dugme.Text == "Cuvaj")
Sacuvaj();
else
Osvezi();
}
Uslovi
Za blokove ili "programski tok" se najcesce povezuju if uslovi. Ono sto je bitno je da se kod if naredbe prvo ispituje poslednji uslov (ako ih ima vise) te ako je "veznik" uslova AND tj && tok programa se nastavlja dalje jer uslov nije zadovoljen.
Takodje, treba obratiti paznju na ispitivanje jednakosti. Naime, brze se izvrsava ispitivanje razlicitosti nego jednakosti, tako da ako nema neke preterane potrebe za jednakoscu (kao u prethodnom primeru) bolje je uzeti u obzir razlicitost.
Thursday, March 6, 2008
Staticke klase u web aplikacijama
Staticke klase su klase koje se ne moraju instancirati da bi se pristupilo njihovim metodama i propertijima.
Ovo je sjajna stvar kada se kreira windows aplikacija. Zahteva mesto u memoriji u koje mozete potrpati podatke (objekte) i koristiti ih za neku vrstu kesha, kako bi se baza podataka zvala sto manje puta i time ustedelo na komunikaciji. Naravno, ne treba preterivati jer treba imati na umu da je radna memorija ogranicena i da teba imati obzira prema racunaru, a i prema klijentu koji tu aplikaciju koristi.
Medjutim, ako se govori o web aplikaciji stvari su drugacije - treba ih apsolutno izbegavati. Ovo preporucuje i Microsoft.
Cak i ako se govori o Intranet aplikacijama (aplikacije koje se "vrte" na lokalnoj mrezi) koje nemaju toliko online usera nakacenih u jednom momentu, treba biti obazriv.

U primeru sa ovcama mozemo videti kako se moze koristiti staticki metod u okviru jedne nestaticke klase. Ovde se broj ovaca dobija pozivanjem metode countAll() koja vraca ukupan broj ovaca.
U slucaju weba, ovde mozete da skladistite bilo koju infomaciju koja se ne menja tako cesto i koja nije promenljiva direktno od strane korisnika. Recimo, svaka suma (ukupan broj clanaka, ukupan broj novinara, ukupan broj komentara, top lista najcitanijih clanaka itd) koja se prikazuje na jednoj stranici se moze cuvati u statiskim klasama, jer za ovu vrstu bi se koristilo direktno zvanje baze podataka i pozivanje razlicitih tabela za svaki entitet.
Sta je zapravo problem? Ako postoji objekat koji predstavlja jedan entitet (ovcu) ciji je podaci menjaju od strane korisnika, taj objekat stoji u memoriji - za korisnika koji hoce da izmeni podatke za jednu specificnu ovcu. Dok korisnik gleda podatke, drugi korisnik takodje zeli da izmeni podatke za drugu ovcu. Prvi korisnik je izmenio podatke za svoju ovcu i posalo ih na "cuvanje". Sta se desava - podaci koje je prosledio prvi korisnik za svoju ovcu ce se sacuvati za ovcu drugog korisnika!
Ovo se naravno moze izbeci instanciranjem novog objekta Ovca koji ce biti popunjen podacima koje je uneo prvi korisnik, ali to vec nije koriscenje statickih klasa.
Medjutim, ako se zeli dobiti na performansama (brzini ucitavanja stranice) bolje je koristiti globalne promenljive (u slucaju ASP i ASP.NET-a, suma clanaka na sajtu Application("sum_clanaka")) ako su podaci vezani za aplikaciju, ili u sesijskim promljivama ako se radi o podacima koji su vezani za svakog korisnika ponaosob (suma clanaka za ulogovanog novinara Session("sum_clanaka")).
Preporucuje se cak da se za ASP.NET koristi ViewState za cuvanje podataka, medjutim ja bih ovu opciju iskljucio jer se sama web stranica, i kolicina podataka pri postovanju iste, povecava bez preke potrebe, jer se podaci smestaju u skriveno polje web form.
Prednost sesijskih i globalnih promenljivih je sto ih mozete kastovati (konvertovati) u bilo koji objekat i raditi sa njim sve sto vam taj objekat pruza.
Ovo je sjajna stvar kada se kreira windows aplikacija. Zahteva mesto u memoriji u koje mozete potrpati podatke (objekte) i koristiti ih za neku vrstu kesha, kako bi se baza podataka zvala sto manje puta i time ustedelo na komunikaciji. Naravno, ne treba preterivati jer treba imati na umu da je radna memorija ogranicena i da teba imati obzira prema racunaru, a i prema klijentu koji tu aplikaciju koristi.
Medjutim, ako se govori o web aplikaciji stvari su drugacije - treba ih apsolutno izbegavati. Ovo preporucuje i Microsoft.
Cak i ako se govori o Intranet aplikacijama (aplikacije koje se "vrte" na lokalnoj mrezi) koje nemaju toliko online usera nakacenih u jednom momentu, treba biti obazriv.

U primeru sa ovcama mozemo videti kako se moze koristiti staticki metod u okviru jedne nestaticke klase. Ovde se broj ovaca dobija pozivanjem metode countAll() koja vraca ukupan broj ovaca.
U slucaju weba, ovde mozete da skladistite bilo koju infomaciju koja se ne menja tako cesto i koja nije promenljiva direktno od strane korisnika. Recimo, svaka suma (ukupan broj clanaka, ukupan broj novinara, ukupan broj komentara, top lista najcitanijih clanaka itd) koja se prikazuje na jednoj stranici se moze cuvati u statiskim klasama, jer za ovu vrstu bi se koristilo direktno zvanje baze podataka i pozivanje razlicitih tabela za svaki entitet.
Sta je zapravo problem? Ako postoji objekat koji predstavlja jedan entitet (ovcu) ciji je podaci menjaju od strane korisnika, taj objekat stoji u memoriji - za korisnika koji hoce da izmeni podatke za jednu specificnu ovcu. Dok korisnik gleda podatke, drugi korisnik takodje zeli da izmeni podatke za drugu ovcu. Prvi korisnik je izmenio podatke za svoju ovcu i posalo ih na "cuvanje". Sta se desava - podaci koje je prosledio prvi korisnik za svoju ovcu ce se sacuvati za ovcu drugog korisnika!
Ovo se naravno moze izbeci instanciranjem novog objekta Ovca koji ce biti popunjen podacima koje je uneo prvi korisnik, ali to vec nije koriscenje statickih klasa.
Medjutim, ako se zeli dobiti na performansama (brzini ucitavanja stranice) bolje je koristiti globalne promenljive (u slucaju ASP i ASP.NET-a, suma clanaka na sajtu Application("sum_clanaka")) ako su podaci vezani za aplikaciju, ili u sesijskim promljivama ako se radi o podacima koji su vezani za svakog korisnika ponaosob (suma clanaka za ulogovanog novinara Session("sum_clanaka")).
Preporucuje se cak da se za ASP.NET koristi ViewState za cuvanje podataka, medjutim ja bih ovu opciju iskljucio jer se sama web stranica, i kolicina podataka pri postovanju iste, povecava bez preke potrebe, jer se podaci smestaju u skriveno polje web form.
Prednost sesijskih i globalnih promenljivih je sto ih mozete kastovati (konvertovati) u bilo koji objekat i raditi sa njim sve sto vam taj objekat pruza.
Subscribe to:
Comments (Atom)