<docere>

Concepţia şi limitele aplicaţiei

Situaţia şcolară finală a clasei implică drept date: discipline (Română, Fizică, etc.), elevi (Albu Ion, Barbu Mădălina, etc.), medii (pentru fiecare elev, media anuală la fiecare disciplină) — toate acestea fiind specifice clasei respective şi trebuind să poată fi introduse (în cursul derulării aplicaţiei) de către utilizator (să zicem, de către dirigintele acelei clase).

Pe baza acestor date, aplicaţia trebuie să constituie şi să ofere utilizatorilor (nu numai dirigintelui!) diverse rapoarte, în diverse formate: lista elevilor şi a mediilor lor generale (fie în ordine alfabetică, fie în ordinea descrescătoare a mediilor generale obţinute); lista elevilor şi mediilor anuale la un obiect sau altul; statistici privind mediile şi obiectele - fie în format tabelar obişnuit, fie prin histograme sau altfel de diagrame grafice.

Calculatorul propriu şi aplicaţiile web ("limite" ale HTTP)

Aplicaţia trebuie să ofere utilizatorului şi posibilitatea de a-şi "salva" şi reconstitui datele la un moment sau altul (ca să nu fie obligat să le tasteze din nou, în urma vreunor modificări intervenite pe parcurs). Ei - aici intervine o limitare importantă (şi aparent, de netrecut) în condiţiile în care vom folosi numai HTML şi javascript: datele nu pot fi salvate de către utilizatorul aplicaţiei într-un fişier (cum am face de exemplu, din Word sau din Excel, prin meniul "File/Save As...").

În principiu, fişierele care constituie o aplicaţie web sunt rezidente pe un anumit server şi utilizatorii pot accesa aplicaţia prin intermediul browserelor (folosind protocolul HTTP); la cerere din partea unui browser, unele fişiere ale aplicaţiei - în principal, HTML-urile şi javascript-urile - sunt transferate pe calculatoarele clienţilor.

Dar - din motive de securitate a datelor şi de confidenţialitate faţă de datele de pe calculatoarele clienţilor - s-a evitat din start, posibilitatea de a folosi javascript pentru a salva date într-un fişier de pe discul utilizatorului şi de asemenea, posibilitatea de a încărca direct în aplicaţie un fişier de pe calculatorul utilizatorului.

Prin protocolul HTTP, aplicaţia deschisă în browser comunică numai cu serverul, nu şi cu sistemul de fişiere de pe calculatorul personal al utilizatorului; un fişier de pe calculatorul personal ar putea fi integrat în aplicaţie numai prin transferarea prealabilă a lui pe server (unde programele specifice acelei aplicaţii - programe de alt gen decât javascript - vor putea să prelucreze datele primite şi apoi serverul va putea returna browserului de la care a primit fişierul, rezultatele acestei prelucrări).

Putem face o analogie simplă, cu "protocolul" pe care trebuie să-l respecţi când intri într-o librărie: nu ţi se permite să iei o carte din raft şi s-o pui în ghiozdanul propriu, decât prin intermediul "serverului" (trebuie să o ceri vânzătorului şi să achiţi preţul cărţii); nu ţi se permite să scoţi o carte din ghiozdanul propriu (fişier de pe calculatorul propriu) şi să o plasezi pe un raft, decât eventual iarăşi prin intermediul vânzătorului.

Metodologia Model—View—Controller

Calea firească prin care o aplicaţie web să poată gestiona datele curente ale utilizatorului - să preia date de la utilizator (inclusiv ca fişier de date) să le memoreze şi să le redea în oricare moment după o prelucrare corespunzătoare - a devenit deja clasică, sub denumirea generică de Model—View—Controller (sugerând şi o separare de activităţi, la nivelul aplicaţiei).

Partea de "Model" ţine de memorarea fizică pe server a datelor, într-o anumită organizare (folosind fie o bază de date, fie fişiere-text de un anumit format) care să permită operaţii de accesare, modificare, regăsire, interogare precum şi diverse conversii specifice unora sau altora dintre limbajele folosite în aplicaţia respectivă.

Partea de "View" asigură diverse modalităţi de prezentare a datelor (fie ca fişiere HTML+CSS+javascript, fie ca fişiere downloadabile de exemplu de tip PDF, etc.); de asemenea, permite preluarea datelor de la utilizator şi transferarea lor pe server (la dispoziţia Controller-ului, care le va investiga şi le va prelucra corespunzător).

Partea "Controller" este pregătită să reacţioneze la toate cererile; extrage (sau înscrie) date invocând metodele oferite de Model-ul respectiv, le reorganizează şi le prelucrează - apoi, determină View-ul corespunzător şi transferă datele prelucrate metodelor specifice acestuia (în final, serverul va transfera browserului rezultatul furnizat de View).

Această metodologie implică în mod firesc limbaje de programare specifice părţii de web-server (nu au de-a face cu browserul); de exemplu, aplicaţia "orar" - vezi link-ul Orar în coloana din dreapta - foloseşte o bază de date MySql pentru a păstra (pe server) şi a gestiona datele specifice orarului şcolii şi implică (pe partea de server) diverse module şi "controllere" corespunzătoare, în limbajul Perl.

Deocamdată avem în vedere aici numai "partea de browser" (care este mai la îndemână pentru oricine); nu este necesar vreun server extern (cel mult, se poate "imita" comunicarea obişnuită între un server şi un browser, bazată pe HTTP - prin crearea unui "virtual host" corespunzător aplicaţiei, dacă s-a instalat pe calculator un web-server Apache).

O soluţie pentru încorporarea/salvarea datelor utilizatorului

Aşadar, vom folosi numai browserul şi numai limbajele HTML, CSS, javascript; cum putem realiza aplicaţia web schiţată, câtă vreme nu este posibil să folosim operaţiile obişnuite cu fişiere locale pentru a importa sau exporta date în/din aplicaţia aflată în execuţie? Există metode şi pentru aceasta, iar aici o propunem pe cea mai simplă (… din punctul de vedere al programatorului).

Pentru a salva datele aplicaţiei prezentate de browser pe ecran, utilizatorul trebuie să procedeze astfel:
  — selectează datele (din interiorul elementului de pe ecran care le conţine) folosind mouse-ul (sau, combinaţia de două taste CTRL + A, după ce s-a făcut un click în interior);
  — utilizează combinaţia standard de două taste CTRL + C, prin care ceea ce a fost selectat se copiază într-o zonă de memorie temporară ("clipboard");
  — deschide un fişier folosind un editor de text obişnuit şi foloseşte combinaţia standard de două taste CTRL + V, prin care conţinutul salvat anterior în "clipboard" este înscris ("Paste") în fişierul respectiv.

Pentru a permite utilizatorului să încarce date proprii (la un moment sau altul), în aplicaţia aflată în execuţie sub browser, în primul rând va trebui ca aplicaţia să prevadă un anumit element al cărui conţinut să poată fi înscris cu text de către utilizator; cel mai potrivit în acest scop este elementul <textarea> din HTML. Utilizatorul va deschide fişierul-text în care şi-a păstrat datele (de exemplu, cel în care a înscris numele elevilor, sau cel cu denumirile disciplinelor); va selecta datele respective; apoi va folosi CTRL+C; apoi va face click în interiorul casetei <textarea> din browser şi va folosi CTRL+V (astfel, datele au fost aduse în aplicaţie şi este rândul unui anumit mecanism javascript de a le citi din <textarea> şi de a le implica mai departe în execuţia aplicaţiei).

Desigur, tot un element <textarea> va servi drept container pentru datele pe care utilizatorul solicită să le salveze (utilizând procedura selectează conţinutul — CTRL+C — deschide fişier-text — CTRL+V descrisă mai sus).

Mici experimente cu <textarea>

Constituiţi un fişier-text .html cu următorul conţinut:

     <textarea rows="3" cols="60" style="background:#eee;"> </textarea>

Deschizându-l din browser, obţinem o casetă care oferă spaţiu pentru 3 rânduri a câte 60 caractere:

Faceţi un click în interior şi tastaţi un text oarecare; selectaţi-l (click în interior şi CTRL+A), copiaţi (CTRL+C), apoi deschideţi un fişier-text şi descărcaţi (CTRL+V). Se cheamă că am "salvat" conţinutul din browser într-un fişier propriu.

Spaţiul afişat în casetă corespunde declaraţiei (3 rânduri × 60 coloane), dar el se extinde automat pe măsură ce textul tastat devine mai lung, sau cu rânduri mai multe (caz în care se ataşează şi "bare de scroll").

Procedaţi şi invers: selectaţi dintr-un fişier-text propriu, copiaţi în "clipboard", reveniţi în browser, faceţi un click în casetă şi descărcaţi (CTRL+V) - se cheamă ca am "încărcat" date proprii în browser.

Pentru exemple de mici aplicaţii care folosesc <textarea> pentru a prelua datele utilizatorului: vezi link-urile din coloana din dreapta a acestei pagini, determinanţi şi sisteme sau drumuri minime.

Dar datele respective trebuie nu doar "încărcate"; pentru a fi prelucrate, ele trebuie să fie preluate din casetă în anumite variabile javascript. Mai subtil - este necesar un mecanism de sincronizare între operaţiile din browser (sau din aplicaţie) şi cele ale utilizatorului, prin care browserului să i se semnaleze faptul (evenimentul) că utilizatorul a terminat depunerea datelor în casetă (astfel că ele pot fi acum preluate în vederea derulării operaţiilor de prelucrare). Browserul facilitează realizarea unor astfel de sincronizări prin obiectele din DOM events.

Să modificăm fişierul anterior astfel:

     <textarea rows="2" cols="60" onblur="alert(this.value);"> </textarea>

Reîncărcaţi în browser fişierul modificat astfel, tastaţi un text în casetă şi apoi faceţi un click în afara casetei.

Faceţi un click aici şi apoi unul în afara casetei! Browserul va deschide o ferestră de alertare în care va afişa conţinutul aceste casete.

onblur semnalează părăsirea zonei editate (printr-un click în afara ei). Sensul prevederii obiectelor "eveniment" în DOM derivă din faptul că ele pot fi asociate cu diverse "handlere" - funcţii javascript care urmează să fie executate atunci când este semnalat evenimentul respectiv (astfel este funcţia "alert", asociată evenimentului "onblur" în cazul de aici).

this este folosit în multe limbaje "object-oriented" pentru a referi obiectul din care este invocată metoda sau proprietatea; aici, alert(this.value invocă metoda alert() prin care browserul deschide o fereastră de alertare, transmiţând drept conţinut al acestei ferestre valoarea proprietăţii "value" a obiectului referit prin "this" (tocmai conţinutul înscris în <textarea> - obiectul din care s-a invocat alert()).

Îndoieli — "unde mergem noi Domnule?!"

În procesul de creare a unei aplicaţii există şi etape nevăzute (nemenţionate în standardele de "elaborarea aplicaţiilor"), în care lucrătorul se opreşte din lucrul său şi-şi judecă intenţiile: unde mergem noi Domnule?

Este cam pompos termenul de "aplicaţie web" pentru o aplicaţie care de fapt nu implică şi "partea de server" - HTTP fiind implicat doar (cel mult) pentru a descărca pe calculatorul clientului fişierele HTML, CSS, javascript necesare aplicaţiei. Termenul este însă corect, câtă vreme resursele respective trebuie accesate din browser, folosind un protocol specific (fie http:// pentru resurse rezidente pe un anumit server, fie file:/// pentru fişiere HTML locale).

Dar care să fie sensul pentru care se produc asemenea aplicaţii pentru browser - când în fond, prelucrările vizate pot să fie realizate de fiecare, utilizând diverse produse software instalate pe calculator? De exemplu, "situaţia şcolară finală a clasei" poate să fie obţinută fără bătaie de cap, folosind Excel (sau analogul "free software" Gnumeric); hai să zicem pentru acest caz, că nu ne interesează atât rezultatele (să listăm situaţia şi atât), ci avem motive didactice (de iniţiere în HTML, etc.) pentru care preferăm să utilizăm numai browserul.

Spre deosebire de lucrul individual în Excel ("fiecare cu Excel-ul lui"), folosirea unei aceleiaşi aplicaţii web—accesibile de oricine, de oriunde, în orice moment, de către toţi care au nevoie, fără să fie nevoie să instalezi sau să deschizi Excel sau vreo altă aplicaţie "desktop"—permite şi asigură o anumită standardizare (de exemplu, documentele finale vor avea acelaşi format pentru toţi utilizatorii). În plus, este posibilă integrarea pe un acelaşi site a mai multor aplicaţii (chiar şi numai "pentru browser") dedicate unui domeniu specific; de exemplu, pentru domeniul şcolar - o aplicaţie pentru întreţinerea orarului şcolii, una pentru realizarea situaţiilor şcolare, aplicaţii destinate diverselor discipline şcolare, etc.

<textarea> şi Word-ul

Începând de prin 2002, s-a manifestat tendinţa generală de a înlocui aplicaţiile "desktop" prin aplicaţii "pentru browser" corespunzătoare. Astfel, în 2003 a apărut biblioteca javascript HTMLArea care extindea elementele <textarea> din HTML cu funcţionalitatea specifică Word-ului; această bibliotecă a fost preluată şi dezvoltată apoi de Xinha, iar în 2006 a apărut şi o extensie pentru Firefox, Xinha here!.

Accesând adresa menţionată pe imaginea reprodusă, veţi vedea un element <textarea> care diferă de cel obişnuit prin faptul că include un "toolbar" (asemănător cu "bara de instrumente" din Word); se poate proba acolo că este posibilă editarea directă a conţinutului în maniera obişnuită pentru Word.

HTMLArea a fost una dintre primele utilizări consistente a aspectelor de programare orientată pe obiecte ale limbajului javascript; în acelaşi spirit s-au dezvoltat începând din 2005 şi alte astfel de editoare WYSIWYG pentru browser: tinyMCE, FCKeditor, etc.

De asemenea, Google a creat şi a pus la dispoziţia utilizatorilor modalităţi WYSIWYG specifice lucrului sub Word sau sub Excel, prin Google Docs şi prin Google Spreadsheet (aflate încă în dezvoltare).