Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Manifest o interfejsu jedne stranice


Ažurirano: 15. juna 2011.

Poreklo web tehnologije


Kada je Tim Berners Lee izumeo web on je tražio sistem za objavljivanje naučnih dokumenata kojima će se moći pristupiti sa daljine, a koji je vizuelno privlačan, lak za kodiranje i lak za upotrebu od strane osoba koje nisu tehničari.

U naučnom dokumentu, spoljni navodi ka drugim dokumentima su neophodni kako bi čitalac mogao da razvije temu u pitanju.

Zbog ovih razloga svetska mreža (World Wide Web) je začeta kao sistem baziran na stranici (dokumentu) sa hiperlinkovima.

U početku je mreža bila svet statičkih stranica i linkova ali su ubrzo generacija dinamičkih strana i uopšte korišćenje mreže kao podrške za dizajniranje aplikacija baziranih na internetu zakomplikovali sve.

Dolazak web aplikacija


Mnogo godina je ulagan napor da se web paradigma stranica i linkova prilagodi razvoju aplikacija. U web aplikaciji Bernersov pogled na statičke dokumente i jednostavne linkove ne postoji.

Događali su se različiti pristupi razvoju aplikacija:
  • Model 1: direktan prevod originalnog modela stranica i linkova, gde se stranice dinamički generišu.

  • Model 2 o MVC: sada linkovi ne ukazuju direktno na betonsku ciljanu stranicu. U ovom slučaju kontroler odlučuje šta je sledeća stranica u zavisnosti od operacija koje su se dogodile u tranziciji stranice.

  • MVC baziran na komponentama (Model 3?): je sofisticirana verzija Modela 2 koja simulira kako aplikacije na desktopu rade. Bazirana je na komponentama i događajima, tako da bilo koja radnja koju obavi korisnik nagoveštava kompletnu obnovu i ponovno učitavanja stranice delimično menjajući neke delove u skladu sa radnjom koja je izvršena. Stranicom i tranzicijom stranice sada upravljaju komponente koje se sada nalaze prema događaju, simulirajući kako komponente rade u programiranju desktop GUI.
Nedavno je predstavljena AJAX tehnika. Ova tehnika uz pomoć JavaScripta omogućava delimične promene na stranicama koje dobijaju nove podatke sa servera a da nije potrebno da se one ponovo učitaju. Uprkos delimičnoj tehnici promene stranice, prošlo je dugo pre objavljivanja XMLHttpRequest u Internet Exploreru (bazi AJAX programiranja), što je bio podsticaj njegove masovne upotrebe.

Sada milioni web sajtova i web aplikacija koriste AJAX kako bi omogućili bolje iskustvo krajnjim korisnicima zahvaljujući odgovornijim korisničkim interfejsima koji delimično izbegavaju ponovna učitavanja dosadne stranice.

Uprkos širokoj upotrebi AJAX-a, možemo da kažemo da Web prati razvojni model koji bismo mogli da nazovemo “Model 2 (MVC) obogaćen AJAX-om”. Kada koristimo AJAX, “Model 3” nema mnogo smisla jer AJAX široko smanjuje potrebu za upravljanjem stranicom, koja je bazirana na komponentama. Budući da je AJAX obično koristio usputne komponente (koje nisu nužno prisutne u Modelu 2), možemo da klasifikujemo trenutno stanje umetnosti web razvoja kao Model 3.5, gde se navigacija po stranici delimično izbegava u slučaju manje tranzicija stranica koje izvode AJAX i JavaScript.

Koje su mane navigacije i razvoja baziranih na stranici?


Svaki web programer zna kako je problematična navigacija po stranici u web aplikaciji, pored rasipanja propusnog opsega i vremena procesiranja neophodnog za ponovno pravljenje čitavih stranica, tu je više problema koji čine razvoj bolnim kao što je neželjeno keširanje, dugmad za nazad/napred, nesinhronizovane forme koje stvara funkcija “automatoskog popunjavanja forme” na nekim pretraživačima i tako dalje. Nije neobično videti web aplikacije koje sakrivaju meni i dugmad na pretraživaču ili koje koriste okvire ili iokvire (frames i iframes) (npr. banke) da bi izbegli problem dugmadi nazad/napred.

Razvoj baziran na stranici primorava stil kodiranja da bude čudan, ponavljajući i neefikasan (i propusni opseg i snaga kompjutera) koji se ne mogu naći u razvoju desktopa.

Šta je to što sprečava intenzivnu upotrebu AJAX-a?


U polju razvoja weba naviknuti smo da razlikujemo dve vrste web rešenja: web aplikacije i web sajtove.

U prvom slučaju AJAX se sve više i više koristi jer ova vrsta aplikacije ne deli neke rekvizite koji su nametnuti web sajtovima. Na web sajtovima intenzivna upotreba AJAX-a je problem.

Na javnim web sajtovima krajni korisnici su naviknuti na koncept stranice, a vezano za stranice neki rekviziti i servisi su potrebni bilo kom web sajtu kao što su:
  1. Bukmarkovanje (Označavanje): Svaka web stranica ima drugačiji URL, a ovaj URL se može sačuvati kao oznaka (bukmark). Budući da AJAX može delimično promeniti stranicu, dok URL ostaje isti, krajnji korisnik ne može da sačuva stanje stranice kao bukmark.

  2. Optimizacija web sajta (SEO): Bilo koji sajt želi da bude potpuno ubačen u indeks od strane pretraživača kao što je Google Search. Trenutni popisivači vide Web kao Web 1.0, to jest, JavaScript kod se potpuno ignoriše, te stoga bilo koja delimična promena koja se obavi putem AJAX-a učitanog sa servera se ne izvršava, a potom nije ni ubačena u indeks od strane popisivača web sajtova.

  3. Servisi bazirani na posetama sajtu: Na primer, oglasni servisi kao Google AdSense i praćenje posećenosti stranica kao što je Google Analytics, u oba slučaja broj učitavanja stranica je bitan. Stoga, bilo koja delimična promena koju sprovede AJAX se ne računa kao nova poseta.

  4. Povremena potreba za pop-up prozorima:
Zbog ovih rekvizita, intenzivni AJAX nije preporučen na web sajtovima.

Pa ipak, razlika između “web sajta” i “web aplikacije” postaje manja jer je skoro bilo koji sajt forma “web aplikacije”...

Da li bi trebalo da odustanemo od intenzivnih AJAX aplikacija?


NE.

Postoje tehnička rešenja za sve gore pomenute rekvizite.

Da li je moguć razvoj web sajtova baziranih na jednoj web stranici (SPI)?


DA!

Ovo je vreme da se počne ova tranzicija, programeri i svi krajnji korisnici će biti na dobiti. Imamo tehnologiju i moderni pretraživači su kvalifikovani da dostignu ovaj cilj.

Da bismo uspeli u ovom “novom” načinu razvoja web-a, moramo da ispunimo sve prethodne rekvizite bilo kog sajta.

Doviđenja stranice, dobrodošla stanja


U web aplikaciji bez JavaScripta, sekvenca stanja je jednaka stranici, u SPI aplikaciji bilo koja delimična promena ukazuje na novo “stanje” “stranice”. Među stanjima možemo razlikovati dve vrste stranja:
  • Fundamentalna stanja

  • Sekundarna stanja
Razlikovanje ova dva vida stanja je vrlo važno jer će fundamentalna stanja postati web stranice kada to bude neophodno. Diferencijacija fundamentalnih i sekundarnih stranja zavisi od web sajta.

Da bismo bolje razumeli oba tipa stanja možemo proučiti pravi primer: validacija pristupa nalogu.

U klasičnim aplikacijama baziranim na stranici tipičan pristup je napravljen pomoću dve strane, jedne za korisničko ime i šifru i druge koja pokazuje opcije korisnika ako je validacija pristupa nalogu bila ispravna. Stranica za pristup će se ponovo učitati pokazujući neke poruke o greškama zajedno sa formom za pristup kada je unos podataka za prijavu na nalog pogrešan.

U SPI web-u, početni pristup nalogu i korisnička stranica sa opcijama mogu biti fundamentalna stanja, a poruke o greški zajedno sa pristupom nalogu mogu biti sekundarna stanja.

Drugi primer: web sajt baziran na stranicama koje će se prebaciti u SPI. U ovom slučaju fundamentalna stanja će biti stranice, a sekundarna stanja će biti stanja stranice sa manjim izmenama, što neće biti dovoljno bitno za označavanje ili za pretragu popisivača.

Interfejs i bukmarkovanje jedne stranice


Različite stranice imaju različite URL-ove. Prateći SPI rutu, kako možemo da promenimo stanje i URL u isto vreme a da ne učitamo stranicu opet kako bismo omogućili da ovo novo stanje bukmarkuju krajnji korisnici?

Postoji caka, korišćenje dela URL-a o “referenci” (“hash fragment”, shebang ili hashbang), ovo je poslednji deo, ako je prisutan, a koji prati # karakter. Ova referenca se koristi da se pomera stranica do određene lokacije koja je specifikovana od strane oznake. Ovaj deo sa referencom ne učitava ponovo stranicu ako se promeni, stoga ukoliko se URL referenca promeni korišćenjem window.location zajedno sa stanjem stranice (u ovom slučaju ovo novo stanje je “fundamentalno”) sa JavaScript-om i AJAX-om, ne dešava se ponovno učitavanje. Budući da su se URL i fundamentalno stanje promenili, krajnji korisnici mogu da sačuvaju ovaj URL, koji delimično sadrži informacije o novom stanju, kao bukmark.

Kada krajnji korisnik želi da se vrati natrag na bukmarkovanu stranicu, dato stanje se određuje u URL delu za reference, server će biti neophodan, dok se deo o referencama nažalost ne šalje serveru jer on nema nikakve veze sa udaljenom lokacijom koja koristi HTTP, te će nam stoga trebati proces nakon učitavanja.

Server će vratiti početnu stranicu u kojoj dato stanje nije određeno. Pa ipak, window.location objekat sadržava originalni URL zajedno sa delom o referencama. Kada se učitava data stranica koju možemo da detektujemo pomoću JavaScripta bez obzira na to da li window. location sadrži deo za reference i bez obzira da li ova referenca zahteva informacije o datom stranju, ukoliko je tačna, možemo ponovo da napišemo URL dodajući neku vrstu normalnog parametra kako bismo odredili koje stanje treba da se učita. Budući da se URL zapravo promenio, novi zahtev za serverom je izvršen, a ovog puta stanjeza učitavanje je u parametru, dok server vraća novu stranicu sa željenim stanjem.

Druga opcija, bolja od hashbang-ova, dolazi sa pojavom HTML 5, HTML 5 istorijskim API-jem.

Interfejs jedne stranice i optimizacija web sajta (SEO)


Najlakši način da dobijemo naš web sajt koji je procesiran od strane popisivača pretraživača jeste da ponudimo dva različita moda za navigaciju, SPI za krajnje korisnike, stranice za web popisivače.

Sledeći primer pokazuje link sa ovom idejom:

<a href="URL page" onclick="return false">…

Ovaj link neće uraditi ništa u pretraživaču sa omogućenim JavaScript-om jer je navigacija onemogućena od strane “return false” onclick atributa, ali kada robot indeksira ovaj link, on ignoriše onclick atribut jer JavaScript kod nije izvršen i procesira specifični URL kao sledeću stranicu za procesiranje.

U polju SPI aplikacija, URL-ovi koji se koriste za navigaciju stranica/stanja moraju sadržati dato stanje, a to je isti tip URL-ova koji je korišćen u SPI bukmarkovanju a koji koristi deo za reference da ukaže na dato stanje ili da je to stanje direktno napisano kao normalni parametar. Kasnije je bolje, jer izbegava zahtev servera, dok se naravno “lepi URL-ovi” takođe mogu koristiti.

Trenutno Google već popisuje “AJAX URL-ove”, to jest, URL-ove koji sadrže ciljano stanje u delu za reference iza #! kao što je određeno u Kako da se AJAX aplikacije popišu, u ovom slučaju web sajt/aplikacija se mora vratiti na očekivanu stranu koja je tražena sa a_escaped_fragment_ parameter.

Istovremeno SPI web okvir za rad može dodati specifični kod onclick handler pre return false ili može vezati slušaoca događaja za link koji se koristi za navigaciju po stranici/stanju, a što je registrovano sa addEventListener ili attachEvent u zavisnosti od pretraživača. Ovaj slušalac događaja će izvršiti neke radnje kako bi komandovao serveru, obično pomoću AJAX-a, u svrhu promene stanja stranice. Kada se klikne na link ova promena stanja nije nova stranice jer atribut onclick="... return false" izbegava takvo ponašanje.

Tehnika koja je prethodno opisana je najjednostavnija i trenutna korišćenjem vidljivih linkova kompatibilnih sa robotima i SPI. Nikad nećete razdvojiti obe funkcije, na primer, korišćenjem skrivenih linkova za krajnje korisnike, ali ne i za robote pored drugih elemenata na koje se može kliknuti kako bi se promenilo SPI stanje korišćenjem JavaScripta nevidljivog za robote.

Najbitnija odlika SPI sposobnog okvira jeste generisanje stranice kao HTML sa zahtevanim stanjem za vreme učitavanja, dok se istovremeno ista promena stanja mora izvesti sa JavaScript-om i parcijalnim ažuriranjem stranice. Ovi rekviziti su fundamentalni da bi omogućili SPI i simulaciju stranice.

SPI i dugmad nazad/napred


Dugmad nazad/napred su izvor problema na konvencionalnim web sajtovima baziranim na stranici i trebalo bi ih izbegavati. Uprkos tome što su korisnici naviknuti na to da izbegavaju dugmad za nazad i napred kada predaju formular sa korisničkim podacima (budući da to nosi rizik da se avionska karta ili knjiga kupi dva puta), korišćenje nazad/napred dugmića je široko rasprostranjeno.

Očigledno SPI paradigma menja tradicionalni način navigacije na web sajtu, jer u teoriji dugmad nazad/napred nemaju smisla u SPI (bez stranica), dok web pretraživači ne obezbeđuju dobru kontrolu ovih dugmića.

Ovo nije u potpunosti tačno. Ponašanje napred/nazad može biti simulirano, umesto navigacije napred/nazad po stranici (i navigacije po istoriji uopšte) može se koristiti da promeni trenutno stanje na prethodno/buduće stanje. U ovom slučaju JavaScript kod može da detektuje kada se deo za reference URL-a menja i zahteva da se aplikacija promeni shodno tome. Buduži da pretraživač ne menja stranicu, Vaša aplikacija je sada u potpunosti odgovorna za ponašanje napred/nazad izbegavajući tipične probleme neočekivane upotrebe nazad/napred dugmića od strane korisnika kada predaju formular. Sada u SPI ne postoji takva forma i ne postoji nekontrolisana navigacija po stranici od strane web aplikacije/web sajta.

SPI i servisi bazirani na posećenosti stranice


Servisi za reklame i brojači poseta stranice su bazirani na tome koliko je stranica učitano. U oba slučaja možete koristiti sakrivene <iframe> elemente koji sadrže praznu web stranicu sa odgovarajućim skriptovima kako bi se ova vrsta servisa izvršila.

U slučaju reklama, servisi kao što su Google AdSense, dinamičko ubacivanje <iframe> impliciraju učitavanje novih reklama kako bi bilo koja promena stanja ukazivala na novo učitavanje <iframe> sa reklamama. Čini se da Google AdSense detektuje kada se AdSense skript izvršava unutar <iframe> i uzima u obzir sadržaje stranice. Može biti poželjno da se doda neka vrsta parametra koja identifikuje fundamentalno stanje koje učitava <iframe>.

U slučaju brojača poseta, možemo ih koristiti da pratimo posete korisnika fundamentalnim stanjima našeg SPI web sajta. U ovom slučaju nam treba sakriveni <iframe> koji sadrži praznu stranicu sa skriptovima koji prate. Uz jednostavan parametar možemo ukazati na to da je fundamentalno stanje posećeno. Naš <iframe> treba da bude globalan (uvek isti na stranici). Kada se stranica prvi put učita, fundamentalno stanje koje se učitava (specifikovano u URL-u) treba da ukazuje na <iframe> sa parametrom. Nakon što se stranica učita, svaka promena fundamentalnog stanja bi trebalo da bude zabeležena u <iframe> menjajući URL putem JavaScript-a u skladu sa novim fundamentalnim stanjem. Ova URL promena će izazvati ponovno učitavanje <iframe> (ukazujući na novu posetu).

SPI i pop-up prozori


Kada se napravi novi prozor stranice, SPI model se kvari. Fundamentalizam je loš, ne postoji problem ako stanje novog prozora nema veze sa stanjem osnovnog prozora, te su u ovom slučaju pop-up prozori sasvim u redu.

Problem nastaje kada neka akcija koja se obavi na pop-up prozoru (modalnom ili nemodalnom) utiče na osnovni prozor, a tada je koordinacija između stranica komplikovana. Na primer, ne postoji web standard za kreiranje modalnih prozora jer je koncept stranice tradicionalno uvek bio nezavistan element i stoga je teško upravljati njegovim životnim ciklusom sa druge stranice.

Srećom, ovaj problem ima rešenje u SPI-ju; možete da simulirate modalni ili nemodalni prozor unutar iste web stranice, dok nijedan novi realni prozor nije napravljen. U slučaju nemodalnih prozora, bilo koji HTML element sa apsolutnim pozicioniranjem može biti “nemodalni prozor”, dok Vi možete napraviti modalne prozore putem apsolutnog pozicioniranja, kontrolisanja z-indeksa i neprozirnosti elemenata “na vrhu” stranice (“modalni slojevi”). Ova rešenja su validna u SPI kontekstu.

Uz malo napora, čak i stanje koje pokazuje modalni prozor može biti fundamentalno stanje i stoga se njime može upravljati putem robota pretraživača.

Kulturni pomak za web programere


Većina web programera (i web okvira za rad) misle da je Web baziran na stranicama, dok smanjenje na jednu stranicu implicira radikalnu promenu mišljenja i načina na koji pravimo web stranice i aplikacije. Ova promena nije tako radikalna zahvaljujući AJAX-u. AJAX je danas popularan i ima smanjen broj stranica tipičnih web sajtova, te nas je u suštini približio ovom “novom” programerskom modelu.

U novom SPI web-u, oznaka
nestaje i u suštini potreba za sesijama korišćenim za upravljanje podataka prati sekvence stranice. Sada je protagonista klijent stranice sa nekom simetrijom u serveru (stranicom u serveru). U suštini, budući da mi pokušavamo da se otarasimo koordinacije na stranici sa sesijama od kojih smo oslobođeni, izvor problema je loša praksa nekih korisnika koji otvaraju nekoliko prozora sa istom stranicom, jer ova praksa obično kvari sesiju i uopšte aplikaciju.

SPI prorgamiranje je bazirano na događajima koji su isti kao na desktopu, budući da se na desktopu većina aplikacija pokreće unutar istog okvira prozora, a kada novonastali prozor postoji, ovim se upravlja sa glavnog prozora i pravog modala.

Prateći paradigmu evolucije web programiranja, ovaj “novi” pristup se može nazvati Model 4.

Kulturni pomak za krajnje korisnike?


Ne baš. Sa bukmarkovanjem i napred/nazad simulacijom, krajnji korisnici neće razlikovati SPI web sajt i istu stranicu, a nadalje, SPI sajt će biti responsivniji, dok će tipično treptanje i pomeranje stranice gore/dole biti uklonjeno.

Tehnička izvodljivost danas


Ovaj manifest nije izjava o namerama već izraz želje da se promoviše “novi” način pravljenja web sajtova koji već postoje. Tehnička studija koja je navedena je uvek imala Java web okvir za rad ItsNat kao svoju tehnološku bazu za SPI programiranje web sajtova. Uprkos svom ItsNat ona je začeta prvog dana do ove vrste aplikacija/sajtova. Prethodne tehnike se mogu primeniti sa drugim web okvirima za rad ili čak ovi okviri mogu evoluirati da omoguće opcije za ovu vrstu SPI web sajtova sa zahtevima za simulaciju strane.

Neki zahtevi ovih SPI web sajtova da budu sposobni da zamene tradicionalne web sajtove bazirane na stranici, kao što su simulacija stranica fundamentalnih stanja vremena učitavanja, su mogući sa serverom orijentisanim web okvirima jer HTML rad mora biti obavljen na serveru za vreme učitavanja. HTML rad za vreme učitavanja i isto dinamičko učitavanje i ubacivanje sa JavaScript-om su ključne karakteristike okvira spremnog za pravljenje SPI web sajtova. Klijentu orijentisani okviri bi mogli da imaju glavnu ulogu u realizaciji takozvanih sekundarnih stanja.

Primer iz stvarnog života


Web Innowhere.com je napravljen sa svojim ItsNat u serveru i dobrim primerom SPI web sajta jer sumira sve zahteve SPI web sajta, kao što je objašnjeno u ovom tekstu, kako bi bio adekvatna zamena tradicionalnom sajtu. U suštini, nova SPI verzija zamenjuje, bez značajne estetske ili funkcionalne promene, prethodnu verziju baziranu na stranicama.

Karakteristike:
  • Interfejs jedne stranice: Nazad i Napred dugmići su simulirani menjajući stanje u prethodno ili naknadno posećeno stanje.

  • Fundamentalna stanja se mogu sačuvati kao bukmarkovi.

  • Kompatibilan je sa SEO: fundamentalna stanja se mogu dostići sa onemogućenim JavaScriptom uključujući modalni prozor.

  • Google “AJAX URL-ovi” kompatibilni sa SEO koristeći #! format. Postoji zahtev za stranicom koji prati Google konvenciju of _escaped_fragment_ parameter. Na primer, ovaj sajt je popisan od strane Google koji zahteva ovaj URL .

  • Radi sa onemogućenim JavaScript-om.

  • Pokazuje reklame bazirane na Google AdSense.

  • Iako je SPI, pretragu kroz fundamentalne sajtove nadgleda Google Analytics korišćenjem skrivenog <iframe> kog URL menja kada se menja fundamentalni sajt.

  • Simulirani modalni prozor izbegava pravljenje stranice u novom prozoru. Ovaj simulirani prozor se takođe može dostići pomoću direktnog URL sa tekstom koji se već nalazi u markup-u i koji je posledično SEO kompatibilan.




Published (Last edited): 11-10-2012 , source: http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php