Blog of Science





Original article: http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php

Manifestul page interfață unică

Originile de tehnologie web
Când Tim Berners Lee a inventat web a fost în căutarea pentru un sistem de a publica documente științifice de la distanță accesibile, atractive vizual, ușor de cod și ușor de utilizat pentru o persoană non-tehnic.

Într-un document științific, extern citează la alte documente este indispensabilă, pentru ca cititorul să poată dezvolta în mod opțional tema în cauză.

Din aceste motive, World Wide Web a fost conceput ca o pagină (documente) sistem bazat cu hyperlink-uri.

Inițial Web a fost o lume de pagini și link-uri statice, dar în curând generarea de pagini dinamice și, în general, utilizarea Web ca suport pentru dezvoltarea de aplicații web-based totul complicat.

Sosirea de aplicatii web
Timp de mulți ani a existat un efort puternic de a se adapta paradigma web de pagini și link-uri către dezvoltarea de aplicații. Într-o aplicație web opinia Berners “de documente statice și link-uri simple, nu există.

Abordări diferite de dezvoltare a aplicațiilor s-au întâmplat:

  • Modelul 1: traducere directă a modelului original de pagini și link-uri, în cazul în care paginile sunt generate dinamic.
  • Modelul 2 o MVC: acum link-uri nu sunt orientate direct la o pagină obiectiv concret, în acest caz, un controller decidă ce pagina următoare este în funcție de operațiunile avut loc în pagina de tranziție.
  • MVC bazat pe componente (Model 3?): Este versiunea sofisticată a modelului 2 simularea cum desktop de lucru aplicații. Ea se bazează pe componente și evenimente, astfel încât orice acțiune de utilizator implică complet reconstrui și reîncărcați paginii schimba parțial o parte, conform cu acțiunea efectuată. Tranziția pagină și pagina este acum gestionat de componente care acum ce modificări să aibă loc în conformitate cu evenimentul, simulând cum a componentelor de lucru cu privire la programarea desktop GUI.
    În ultimii ani, a fost introdus tehnica AJAX, aceasta tehnica cu ajutorul JavaScript permite modificări parțiale în paginile obținerea de noi date de la server fără reîncărcare. În ciuda tehnicii parțială schimbare pagină este cu mult înainte de introducerea XMLHttpRequest in Internet Explorer (de bază de programare AJAX), a fost impuls de utilizare sale masive.

Acum milioane de site-uri web si aplicatii web folosesc AJAX pentru a oferi o experiență mai bună pentru utilizatorii finali datorită interfețe mai sensibile, evitând parțial reîncărca pagina enervant.

În ciuda utilizării masive a AJAX, putem spune Web urmeaza un model de dezvoltare am putea numi ca “Model 2 (MVC) îmbogățit cu AJAX”. Atunci când se utilizează AJAX, “Model 3″ nu are prea mult sens pentru că AJAX reduce în mare măsură de necesitatea de management pagina bazate pe componente. Deoarece AJAX este utilizat de obicei alături de componente (nu prezintă neapărat în Modelul 2), putem clasifica starea actuală a artei de dezvoltare web ca modelul 3.5, în cazul în care de navigare în pagină este parțial evitată în caz de tranziții de stat minore efectuate de AJAX și JavaScript.

Care sunt dezavantajele de navigare și de dezvoltare bazate pe pagină?
Fiecare dezvoltator web stie cum problematic este de navigare pagină într-o aplicație web, în afară de a pierdem lățime de bandă și timp procesul de reconstrucție pagini întregi mai multe probleme face de dezvoltare web dureros ca cache nedorite, înapoi/înainte butoane, forme desynchronized cauzate de “forma de auto-fill” caracteristică a unor browsere și așa mai departe. Nu este neobișnuit să vezi aplicatii web care ascund meniurile și butoanele de browser sau folosind rame sau ansamblu (de exemplu, bănci) pentru a evita problema de butoane Înapoi/Înainte.

De dezvoltare bazat pagina forțează un stil de codificare ciudat, repetitive (o multime de include) și ineficientă (atât de lățime de bandă și putere de calcul) nu a fost găsit în dezvoltarea desktop.

Ce este ceea ce împiedică utilizarea intensivă a AJAX?
În domeniul dezvoltării web ne sunt utilizate pentru a distinge două tipuri de soluții web: aplicatii web si site-uri web.

În primul caz este AJAX ce în ce mai utilizat, deoarece acest tip de aplicații nu împărtășesc unele articole impuse de site-uri web. În site-uri web utilizarea intensivă a AJAX este o problemă.

În site-uri web publice utilizatorii finali sunt folosite pentru a conceptului paginii, legat de paginile unor articole și servicii sunt necesare în orice site web cum ar fi:

  1. Bookmarking: Fiecare pagină web are un URL diferit, acest URL pot fi salvate ca semn de carte. Deoarece AJAX poate schimba partial pagina URL-ul este același, utilizatorul final nu poate salva ca marcaj în vederea beton (de stat) a paginii.
  2. Search Engine Optimization (SEO): orice site web vrea să fie indexat pe deplin de motoare de cautare ca Google Search. Crawlerele curente vedea Web ca Web 1.0, care este, cod JavaScript este complet ignorat, astfel orice modificare parțială efectuată prin intermediul AJAX încărcate de pe server nu este executat, atunci nu indexate de crawlerele care traversează site-ul web.
  3. Servicii bazate pe vizite pagina: De exemplu servicii de publicitate, cum ar fi Google AdSense și pagina vizită de monitorizare, cum ar fi Google Analytics, în ambele cazuri a numărului de pagină se încarcă, este important. Prin urmare, orice modificare parțială efectuată de AJAX nu este considerat o nouă vizită.
  4. Nevoie ocazional de ferestre pop-puilor

Deoarece aceste articole intensiv AJAX este descurajată în site-uri web.

Cu toate acestea, diferența dintre un “web site” și un “aplicație web” din ce în ce mai mică, deoarece este aproape orice site web este un fel de “aplicatii web”…

Should we give up AJAX-intensive applications?
NO.
There are technical solutions for all above listed requisites.

Dezvoltarea de site-uri web bazate pe o singură pagină Web (SPI), este posibil?
DA !

Acesta este momentul pentru a începe această tranziție, dezvoltatorii și utilizatorii finali noi toți vor câștiga. Avem tehnologia si browserele moderne sunt calificați pentru a atinge acest obiectiv.

Pentru a reuși în această “nouă” mod de dezvoltare web trebuie să ne pentru a realiza toate articole anterioare de orice site web.

Pagini revedere, bun venit stare
Într-o aplicație web fără JavaScript, secvență de stat este echivalent cu pagini, într-o aplicație SPI orice modificare parțială presupune o nouă “stare” de “pagina”. Dintre statele putem distinge două categorii de state:

  • Statele fundamentale
  • Statele secundare

Diferențiere între cele două tipuri de stat este foarte important, deoarece statele fundamentale vor deveni pagini web atunci când este necesar. Diferențiere fundamentală și secundar este site-ul web depinde.

Pentru a înțelege mai bine ambele tipuri de state putem studia un exemplu real: conectare de validare.

Într-o pagină clasic aplicații bazate autentificare tipic este construit folosind două pagini, una pentru utilizator și o parolă și un prezentând opțiunile de utilizator în cazul în care validarea de conectare a fost corect; pagina de autentificare va fi reîncărcată prezintă unele mesaje de eroare alături de formularul de logare, atunci când de intrare de conectare este greșit.

Într-un SPI web, conectare inițială și pagina de opțiuni de utilizator ar putea fi statele fundamentale, și mesaje de eroare, alături de autentificare ar putea fi statele secundare.

Un alt exemplu, un site web bazat pe paginile care urmează să fie convertite în SPI, în acest caz, statele fundamentale vor fi paginile și statele secundare vor fi stare page cu modificări minore, nu este suficient de importante pentru marcare sau care urmează să fie traversate de crawlerele.

Interfata singură pagină și marcare
Diferite pagini au diferite URL-uri, următoarele ruta SPI cum putem schimba un stat și, în același timp URL-ul fără a reîncărca, pentru a permite acestui nou stat poate fi marcată de către utilizatorii finali ?.

Există un truc, folosind “de referință” o parte din URL-uri (“fragment hash”, shebang sau hashbang), aceasta este ultima parte, dacă este prezent, ca urmare a # character. Această referință este utilizat pentru a derula pagina la locul de beton specificată de unele <a name=”ref”></a> marca. Această parte de referință, dacă a schimbat nu reîncarcă pagina, prin urmare, în cazul în care referința URL este schimbat cu ajutorul window.location alături de starea paginii (în acest caz, acest nou stat este “fundamental”), cu JavaScript și AJAX, apoi se efectuează nici o reîncărcare. Deoarece URL-ul și statul fundamentale s-au schimbat, utilizatorii finali pot salva această adresă URL, într-un fel care conține noua info de stat, ca marcaj.

Atunci când utilizatorul final dorește să se întoarcă din nou la pagina marcată, statul țintă este specificat în partea de referință a URL-ul, serverul va fi solicitată, din păcate, partea de referință nu este trimis la server, deoarece o parte trimitere nu face nimic de a face cu locație la distanță prin HTTP, prin urmare, vom avea nevoie de un proces de post-sarcina.

Serverul va returna o pagină inițială în care statul țintă nu este specificat, însă obiectul window.location conține URL-ul original, inclusiv partea de referință. Atunci când încărcarea paginii țintă putem detecta cu JavaScript dacă window.location conține o parte de referință și dacă această referință are necesară info stat țintă, dacă este adevărat putem rescrie URL-ul adăugând un fel de parametru normal să precizeze statului țintă pentru a încărca. Deoarece URL-ul sa schimbat de fapt o nouă cerere de server se execută, de data aceasta de stat pentru a încărca este într-un parametru și serverul returnează o pagină nouă cu statul cerută.

O altă opțiune, mai bine decât hashbangs, apare odată cu apariția de HTML 5, HTML 5 History API.

Interfata singură pagină și Search Engine Optimization (SEO)
Cel mai simplu mod de a obține site-ul nostru web sunt procesate de crawlerele motorului de căutare este de a oferi două moduri de navigare diferite, SPI pentru utilizatorii finali, pagini de crawlerele web.

Următorul exemplu arată o legătură cu această idee:

<a href=”URL page” onclick=”return false”>…</a>

Acest link va face nimic într-un browser cu JavaScript activat pentru ca de navigare este dezactivat prin “return false” de atribut onclick, dar atunci când un indexurile bot acest link ignoră atributul onclick deoarece codul JavaScript nu este executat și va procesa URL-ul specificat ca în următorii pagina pentru a procesa.

În domeniul unei cereri de SPI, URL-uri fiind folosit pentru navigare pagina/de stat trebuie să conțină starea țintă, același tip de URL-uri utilizate în SPI marcare care utilizează partea de referință pentru a indica starea de țintă, sau tinta este scrisă direct ca un parametru normală, este preferată mai târziu, deoarece evită o cerere de server, desigur “URL-uri frumoase” poate de asemenea fi utilizat.

În prezent, Google accesează cu crawlere deja “AJAX URLs”, care este, URL-uri care conțin starea țintă în partea de referință următoare #! după cum se Making AJAX Applications Crawlable, în acest caz, site-ul web/cererea trebuie să returneze pagina de așteptat, se solicită cu un a _escaped_fragment_ parameter.

În același timp, cadrul de web SPI pot adăuga cod specific de tratare a onclick înainte de întoarcerea false sau se poate lega un ascultător eveniment la link-ul de a fi utilizat pentru navigare stat/pagina, înregistrată la addEventListener sau attachEvent, în funcție de browser-ul. Acest ascultător eveniment va executa unele acțiuni pentru a comanda serverul, de obicei, folosind AJAX, pentru a schimba starea paginii. Această schimbare de stat în cazul în care link-ul se face clic nu este o nouă pagină, deoarece atributul onclick=”… return false” evită comportamentul implicit.

Tehnica descrisă înainte este cea mai simplă și imediat prin utilizarea link-uri vizibile, compatibile cu boti și SPI. Puteți separa vreodată ambele funcții, de exemplu, folosind link-uri ascunse pentru utilizatorii finali, dar nu pentru boti, alături de alte elemente se poate face clic pentru a schimba SPI state, cu ajutorul JavaScript invizibil pentru boti.

Cea mai importantă caracteristică a unui cadru capabil să SPI este generație pagina ca HTML cu statul cerută în timpul de încărcare și, în același timp, aceeași stare schimbare trebuie să fie efectuate cu JavaScript și actualizarea paginii parțială. Aceste articole sunt fundamentale pentru a oferi SPI pagina simulare.

SPI și Înapoi/Înainte butoane
Înapoi/Înainte atacant sunt o sursă de probleme pe site-uri web bazate pe pagina convenționale și ar trebui evitate cât mai curând posibil. În ciuda utilizatorii sunt folosite pentru a evita butoanele Înapoi și Înainte la depunerea unui formular cu datele utilizatorului (pentru că poartă riscul de a cumpăra de două ori același plan bifat sau carte), utilizarea butoanelor Înapoi/Înainte este foarte răspândită.

Se pare că paradigma SPI rupe modul tradițional de navigare a unui site web, pentru că în teorie ÎÎnapoi/Înainte nu are nici un sens în SPI (nu pagini) și browserele Web nu oferă un control bun al acestor butoane.

Acest lucru nu este pe deplin adevărat, Înapoi/Înainte înainte pot fi simulate, în loc de pagină de navigare Înapoi/Înainte (și navigare istorie, în general) poate fi folosit pentru a schimba starea curentă la starea Înapoi/Înainte. În acest caz, un cod JavaScript poate detecta atunci când partea de referință al schimbărilor URL și solicită aplicarea a schimba starea în consecință. Deoarece browser-ul nu se schimba pagina de cererea dumneavoastră este acum pe deplin responsabil de Înapoi/Înainte evitarea problemelor tipice ale neașteptate Înapoi/Înainte de utilizatori finali la depunerea unui formular, acum în SPI nu există nici o astfel de formă și nu de navigare necontrolate pagina de locul de aplicare/web web.

SPI și servicii bazate pe vizitele pagina
Servicii de Ads și contoare pagina vizita se bazeaza pe cat de multe pagini au fost încărcate. În ambele cazuri, puteți utiliza ascunse <iframe> elemente conțin o pagină web gol cu ​​script-uri necesare pentru a executa acest tip de servicii.

În cazul serviciilor de publicitate, cum ar fi Google AdSense, inserarea dinamică a <iframe> implică încărcarea anunțuri, prin urmare, fiecare stat schimbare ar putea implica o nouă reîncărcare a <iframe> cu anunțuri. Google AdSense se pare pentru a detecta atunci când script-ul AdSense este executat într-un <iframe> și ia în considerare conținutul paginii container. Poate fi de dorit să adăugați un fel de parametru care identifică starea fundamentală, care este încărcarea <iframe>.

În cazul contoare de vizita, le putem folosi pentru a monitoriza vizite de utilizator în statele fundamentale ale site-ul nostru SPI. În acest caz, avem nevoie de un ascuns <iframe> conține o pagină web gol cu ​​script-uri de monitorizare. Cu un parametru simplu putem indica starea fundamentală vizitate. Nostru <iframe> ar trebui să fie la nivel mondial (mereu același lucru în pagina). Atunci când pagina este prima încărcată, starea fundamentală a fi încărcate (specificat în URL) ar trebui să fie indicat la <iframe> cu un parametru. După încărcare a paginii, fiecare schimbare de stare fundamentală ar putea fi notificate <iframe> schimbarea URL-ul, prin intermediul JavaScript în conformitate cu noul stat fundamentală, această modificare URL va provoca o reîncărcare de <iframe> (indicând o nouă vizită).

SPI și ferestre pop-up
Când este creată o fereastră nouă pagină a modelului SPI este rupt. Fundamentalismul este rău, nu există nici o problemă în cazul în care starea de acest nou fereastră nu are nimic de-a face cu starea ferestrei părinte, în acest caz ferestre pop-up sunt bine.

Problema apare atunci când orice acțiune efectuată în fereastra pop-up (modal sau nu modal) are o anumită influență asupra fereastra părinte, coordonarea între pagini este complicată. De exemplu, nu există nici un standard de web pentru a crea ferestre modale, deoarece conceptul Pagina a fost în mod tradițional întotdeauna un element independent și, prin urmare ciclului său de viață este dificil de a coordona de la o alta pagina.

Din fericire, această problemă are o soluție pentru un timp în SPI, puteți simula ferestre modal modal sau nu în interiorul aceeași pagină web, este creat nu fereastră nouă pagină reală. În cazul ferestrelor non-modal, orice element HTML cu poziționare absolută poate fi o “fereastră non-modal” și puteți crea ferestre modale cu ajutorul de poziționare absolută, controlul z-index și opacitate a elementelor “pe partea de sus” a paginii (“modal straturi”). Aceste soluții sunt valabile într-un context SPI.

Cu un pic de efort, chiar de stat, care arată o fereastră modal poate fi un stat fundamentală și, prin urmare navigabil de roboții motoarelor de căutare.

O schimbare culturală pentru dezvoltatori web
Cele mai multe dintre dezvoltatori web și cadre că Web-ul ca pe baza de pagini, reducerea pagină o singură pagină presupune o schimbare radicală a minții și cum o fac site-uri web si aplicatii. Această modificare nu este mulțumită atât de radicale la AJAX, AJAX este astăzi de masă și a redus numărul de pagini de site-uri web tipice, în rezumat ea ne-a adus aproape de acest model de dezvoltare SPI “nou”.

În noua SPI web <form> tag-ul dispare și, în general, necesitatea de sesiuni utilizate ca administratori de date următoarele secvențe pagina. Acum protagonistul este clientul pagina cu unele simetrie în serverul (pagina în server). De fapt, pentru că vom scăpa de coordonare pagina cu sesiuni suntem eliberați de o sursă de probleme, cum ar fi practica rea ​​a unor utilizatori care deschid mai multe ferestre cu aceeași pagină, această practică rupe, de obicei, sesiunea și aplicarea, în general.

Programarea SPI se bazează pe evenimente la fel ca în desktop, deoarece în cele mai multe desktop de aplicații rulează în aceeași fereastră cadru și atunci când există ferestre copil acestea sunt pe deplin gestionate de fereastra principală și cu adevărat modal.

Urmărind evoluția paradigmei de dezvoltare web, această abordare “nou” ar putea fi numit Modelul 4.

O schimbare culturală pentru utilizatorii finali?
Nu foarte mult, cu bookmarking și Înapoi/Înainte finali simulare forward nu sunt de gând să diferențieze un site web SPI și aceeași pagină bazat, de asemenea site-ul SPI va fi mai receptiv și clipirea tipic și derularea de navigare în pagină este eliminat.

Viabilitatea tehnică astăzi
Acest manifest nu este o declarație de intenții, dar expresia dorinței de a promova o “nouă” mod de site-uri care sunt deja reale de constructii. Studiul tehnic de mai sus a avut întotdeauna cadrul web Java ItsNat ca bază tehnologică a SPI dezvoltarea site-ului web. În ciuda ItsNat a fost conceput din prima zi la acest tip de aplicații/site-uri, tehnicile anterioare ar putea fi aplicate cu alte cadre de web sau aceste cadre ar putea evolua pentru a oferi facilități pentru acest tip de site-uri web SPI cu cerințe pagina de simulare.

Unele cerințe ale acestor site-uri web SPI pentru a putea a înlocui site-uri web bazate pe pagina tradiționale, cum ar fi pagina de simulare a statelor fundamentale privind timpul de încărcare, sunt doar posibile cu serverul de web cadre centrice deoarece randare HTML trebuie să se facă în server de pe timpul de încărcare. HTML randare pe timpul de încărcare și același încărcate dinamic și introduce cu JavaScript sunt caracteristicile cheie ale unui cadru de web gata de a construi site-uri web SPI. Cadre centrice client ar putea avea un rol major pentru realizarea așa-numitelor state secundare.

Două exemple din lumea reală
Web innowhere.com/jnieasy

Aceasta se face cu ItsNat server și un bun exemplu de site-ul web SPI pentru că rezumă toate cerințele unui site web SPI, a explicat în acest document, pentru a fi un substitut satisfăcător de un site tradițional. De fapt, noua versiune SPI înlocuit, fără estetic semnificativ de schimbare funcționale, versiunea anterioară bazată pe pagini. Ea se bazează pe hashbangs.

Caracteristici

  • Interfata singură pagină: butoanele Înapoi și Înainte sunt simulate trecerea la starea anterioară sau înainte vizitat.
  • Statele fundamentale pot fi salvate ca marcaje.
  • SEO compatibile: statele fundamental sunt accesibile cu JavaScript dezactivat, inclusiv o fereastră modal.
  • Hashbang #! format este folosit, că este, Google SEO URL-uri compatibile “AJAX URLs”, pagina este, de asemenea, solicitată ca urmare a convenției Google _escaped_fragment_ parametru. De exemplu, această stare este indexat de Google solicitarea această adresă URL.
  • Lucrări cu JavaScript dezactivat.
  • Prezintă un ads banner anunțuri pe baza Google AdSense
  • In ciuda faptului ca SPI, navigarea prin statele fundamentale este monitorizată de către Google Analytics cu ajutorul unui ascuns <iframe> care URL se schimbă atunci când curentul schimbările fundamentale ale statului.
  • O fereastră modal simulat evită crearea unui nou fereastră pagină, această fereastră simulată este, de asemenea accesibil cu un URL direct sau o versiune hashbang cu text deja în markup pe timp de încărcare, prin urmare, compatibil SEO.

Web www.itsnat.org

Este, de asemenea, face cu ItsNat server. În acest caz, se folosește JavaScript History API. Aceasta este abordarea cea mai perfectă pentru a converti un site web convențional la o versiune compatibilă SPI SEO. Dacă istoria API nu este susținută de un browser vechi de beton, de navigare în pagină convențională este folosită în mod automat. Toate browserele web moderne sprijini JavaScript History API. SPI caracteristicile acestui site web sunt în esență aceleași ca și exemplul anterior.