Proiectarea Interfetei In Aplicatia de Gestiune Arheologica Rm360 Folosind Tehnologii Web

Cuprins

Lista figurilor…………………………………………………………………………………………………………9

Lista acronimelor……………………………………………………………………………………………………11

Introducere…………………………………………………………………………………………………………….13

Aplicația RM360………………………………………………………………………………………….15

Sistem de gestiune arheologică…………………………………………………………………15

Descrierea aplicației RM360…………………………………………………………………….15

Tehnologii folosite pentru dezvoltara aplicației………………………………………………..17

2.1 Mediu de dezvoltare Microsoft Visual Studio……………………………………………..17

2.2 Tehnologii principale folosite……………………………………………………………………17

2.2.1 HTML5…………………………………………………………………………………………….17

2.2.2 CSS3………………………………………………………………………………………………..18

2.2.3 Framework-ul Boostrap………………………………………………………………………20

2.3 Limbajul de programare JavaScript……………………………………………………………20

2.3.1 jQuery………………………………………………………………………………………………21

2.3.2 AJAX……………………………………………………………………………………………….21

2.3.3 JSON………………………………………………………………………………………………..22

2.4 Adobe Photoshop……………………………………………………………………………………22

2.5 Google Maps API…………………………………………………………………………………. 22

2.5.1 Conceptul Google Maps API……………………………………………………………..22

2.5.2 Avantaje și dezavantaje Google Maps API…………………………………………..23

3. Prezentare aplicație…………………………………………………………………………………….25

3.1 Interfața dedicată utilizatorilor de tip vizitatori/ guest (user)………………………26

3.1.1 Pagina principală……………………………………………………………………………..27

3.1.2 Pagină logare (log in)……………………………………………………………………….31

3.1.3 Pagină creare utilizator nou (register)…………………………………………………33

3.1.4 Pagini obiective……………………………………………………………………………….33

3.2 Interfața dedicată utilizatorului cu drept de administrator (admin)……………….37

3.2.1 Pagină administrator…………………………………………………………………………38

3.2.2 Pagină mesaje………………………………………………………………………………….41

3.2.3 Pagină management utilizatori…………………………………………………………..43

3.2.4 Pagini editat obiective………………………………………………………………………44

3.3 Interfața dedicată utilizatorului de tip supervizor………………………………………47

3.3.1 Pagină supervizor…………………………………………………………………………….48

3.3.2 Pagini administrare aplicație……………………………………………………………..48

Concluzii și direcții viitoare…………………………………………………………………………….49

Bibliografie…………………………………………………………………………………………………..50

Anexe

RM360 HTML……………………………………………………………………………………….51

RM360 CSS………………………………………………………………………………………….

Lista figurilor

Figura 2.1 – Logo Microsoft Visual Studio……………………………………………………………..17

Figura 2.2 – Logo HTML5……………………………………………………………………………………18

Figura 2.3 – Structura unui document HTML…………………………………………………………..18

Figura 2.4 – Logo CSS3………………………………………………………………………………………..19

Figura 2.5 – Logo Boostrap……………………………………………………………………………………20

Figura 2.6 – Logo JavaScript………………………………………………………………………………….21

Figura 2.7 – Logo jQuery……………………………………………………………………………………….21

Figura 3.1 – Diagramă UML a aplicației în funcție de logare……………………………………..26

Figura 3.2 – Diagramă de funcționare a secțiunii dedicate userilor……………………………..26

Figura 3.3 – Interfața de pornire……………………………………………………………………………..28

Figura 3.4 – Footer interfață de pornire……………………………………………………………………28

Figura 3.5 – Secținea dedicată hărții din pagina principală ………………………………………..31

Figura 3.6 – Interfață pagină logare ………………………………………………………………………..32

Figura 3.7 – Interfață pagină înregistrare………………………………………………………………….33

Figura 3.8 – Model interfață pagină monumente……………………………………………………….34

Figură 3.9 – Model interfață-responsivă pagină monumente……………………………………….36

Figura 3.10 – Modal fișă monument………………………………………………………………………..37

Figura 3.11 – Modal eroare…………………………………………………………………………………….37

Figura 3.12 – Diagramă de funcționare a secțiunii dedicate administratorului……………….38

Figura 3.13 – Interfață pagină administrator……………………………………………………………..39

Figura 3.14 – Pagină administrator animații……………………………………………………………..39

Figura 3.15 – Interfață pagina mesaje………………………………………………………………………41

Figura 3.16 – Modal citire mesaj……………………………………………………………………………..42

Figura 3.17 – Pop-up confirmare ștergere mesaj………………………………………………………..43

Figura 3.18 – Interfață pagină management utilizatori………………………………………………..44

Figura 3.19 – Interfață pagină Adaugă monument…………………………………………45

Figura 3.20 – Interfață pagina Editare monumente…………………………………….….45

Figura 3.21 – Modal editare monument……………………………………………………46

Figura 3.22 – Modal editare fișă……………………………………………………………46

Figura 3.23 – Diagramă de funcționare a secțiunii dedicate supervizorului…………………….47

Figura 3.24 – Interfață Pagină supervizor………………………………………….………48

Lista acronimelor

AJAX – Asynchronous JavaScript and XML

API – Application Programming Interface

CSS – Cascading Style Sheets

DOM – Document Object Model

HTML – HyperText Markup Language

HTTP – Hypertext Transfer Protocol

IDE – Integrated Development Environment

JSON – JavaScript Object Notation

RM360 – Roșia Montană 360

UML – Unified Modeling Language

URL – Uniform Resource Locator

UTF-8 – UCS Transformation Format 8 bit

Web – World Wide Web  totalitatea siturilor / documentelor și informaților de tip hipertext legate între ele, care pot fi accesate prin rețeaua mondială de Internet

XML – Extensible Markup Language

Introducere

Pentru proiectul de diplomă am ales să dezvolt o interfeță web dinamică pentru un sistem de gestiune arheologică. Interfața presupune apelarea metodelor existente în serverul de back-end, pentru a adăuga sau a extrage informații în baza de date existentă în aplicația de gestiune arheologică RM360 (din programul „Adoptă o casă”), populată cu obiecte de patrimoniu (istorice, arheologice, culturale) și obiective naturale (masive, lacuri, monumente ale naturii etc.).

Caracterul dinamic al acestei interfețe este dat de folosirea unor tehnologii noi de încarcare parțială a paginii web, afișarea rezultatelor în timp real, pagini populate cu elemente existente în baza de date în momentul interogarii, precum și alte elemente cu caracter dinamic.

Scopul acestei aplicații web este acela de a se putea vizualiza într-un mod complex monumentele existente în baza de date atașată acesteia. Fiind un sistem de gestiune, există posibilitatea de a introduce, modifica sau de a șterge aceste obiective, prin intermediul unor pagini accesibile doar unor categorii restrânse de utilizatori. Accesul ierarhizat al utilizatorilor este monitorizat de către administratorul principal.

Am ales această temă datorită interesului propriu pentru domeniul de programare în internet, în special pentru tehnologii de programare web. Mai mult decât atât, am ales să dezvolt această interfață pentru a ajuta persoanele ce se ocupă de gesiunea unor astfel de obiective de patrimoniu.

Pentru dezvoltarea acestui proiect am folosit limbaje de programare și tehnologii precum JavaScript, jQuery, HTML5, CSS3, AJAX, Google Maps API, framework-ul boostrap. Mediul de dezvoltare folosit îl consituie Microsoft Visual Studio 2012, iar pentru design-ul grafic al elementelor componente, am folosit ca mediu de editare grafică Adobe Photoshop CS6.

Primul capitol reprezintă o scurtă descriere a unui sistem de gestiune arheologică și câteva informații despre aplicația RM360.

Al doilea capitol reprezintă descrierea succintă a tehnologiilor folosite pentru dezvoltarea acestei interfețe.

Al treilea capitol reprezintă descrierea detaliată a aplicației, evidențiind și contribuția personală.

Ultimul capitol evidențiază contribuția proprie și direcții viitoare de continuare a aplicației.

Aplicația RM360

Sistem de gestiune arheologică

Scopul unui sistem de gestiune îl reprezintă oferirea informației solicitate de utilizator, sub

forma dorită și la momentul oportun, în vederea fundamentării deciziilor. [11] Principala caracteristică a unui sistem de gestiune este domeniul în care acesta își desfășoară activitatea.

În această lucrare, vom prezenta principalele caracteristici ale unui sistem de gestiune arheologică, deoarece aplicația se axează pe studierea siturilor arheologice, împreună cu obiectivele prezentate la o anumită locație (obiective de patrimoniu istorice, culturale, arheologice și obiective naturale).

În cadrul arheologiei, calculatorul are un loc privilegiat, deoarece asigură o utilizare mult mai perfomantă și practică a bazelor de date( fișe specializate ce conțin informațiile dobândite de-alungul anilor despre un anumit obiectiv). Calculatorul are un rol important și în procesul de prelucrare a informațiilor cu ajutorul unor sisteme speciale domeniului necesar, pentru o analiză finală și pentru publicarea informațiilor. Astfel un sistem de gestiune arheologică ajută la creșterea eficienței în gestiune și reducerea timpului de acces la resurse. Deși necesitatea unui sistem de gestiune informatic este mare, unii utilizatori nu acceptă sistemul nou fie din necunoștiință de cauza, fie din obișnuința cu sistemul clasic. Un alt dezavantaj al unui sistem de gestiune arheologic și al tuturor sistemelor de gestiune în general este folosirea inadecvată, de persoane fară pregatire, ducând astfel la apariția unor erori neprevăzute. De aceea un sistem de acest fel va fi gestionat de către utilizatori cu pregătire necesară prelucrării informației, sau de utilizatori din domeniul de de activitate al acestuia. Pentru a ne asigura că un astfel de sistem este gestionat de utilizatori specializați, este necesară administrarea conturilor operatorilor de date. Unul din cazurile favorabile este de a ierarhiza utilizatorii în funcție de un parametru numit nivel de acces. În aceste condiții vom avea un sistem cu trei tipuri de utilizatori: utilizatori care doar pot vedea informația, utilizatori care pot prelucra informația și utilizatori care pot vizualiza, modifica și adăuga informații în sistem.

Aplicația RM360 reprezintă un sistem de gestiune arheologică ce se bazează pe aceasta ierarhizare a utilizatorilor în funcție de contul de logare.

Descrierea aplicației RM360

Aplicația de gestiune arheologică RM360 face parte din programul „Adoptă o casă la Roșia Montană”, inițiat în luna Iunie 2012, având ca scop salvarea patrimoniului cultural de la Roșia Montană și din satele învecinate. Acest program este inițiat de asociația locală Albumus Maior în parteneriat cu ARA – Arhitectură. Restaurare. Arheologie, asociație ce are ca scop conservarea și punerea în valoare a patrimoniului cultural în beneficiul comunităților și al societății. UAR – Uniunea Arhitecților din România, prin Timbrul Arhitecturii, a ajutat financiar demararea proiectului. Anual, programul include o școală de vară dedicată studenților în domeniul patrimoniului cultural, prilej cu care lucrările de restaurare devin obiect de studiu și de experimentare pentru participanți. O dată cu creșterea conștientizării importanței patrimoniului și managementul eficient al acestuia, a crescut și nevoia unui inventar al monumentelor. Astfel, a fost lansătă aplicația Roșia Montană 360( RM360) ce are ca scop gestionarea obiectelor de patrimoniu (arheologice, istorice, culturale) și a obiectivelor naturale (masive, lacuri, monumente ale naturii). În 2014 a fost lansată prima versiune a platformei RM360, obiectivele acesteia constituind punctul de plecare al noii versiuni.

Aplicația oferă posibilitatea de vizualizare complexă a obiectivelor arheologice, cu un acces ierarhizat al utilizatorilor. Astfel în funcție de contul de logare aplicația va conține trei componente importante: interfața de administrator, interfața de supervizor și interfața de user. Fiind o aplicație de gestiune, utilizatorii care au permisiuni, vor putea edita/ șterge obiectivele introduse, sau să adauge obiective noi.

Tehnologii folosite pentru dezvoltarea aplicației

Mediu de dezvoltare Microsoft Visual Studio

Figura 2.1 – Logo Microsoft Visual Studio

Sursa: http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles

Microsoft Visual Studio este un mediu de dezvoltare integrat (IDE), ce permite partajarea instrumentelor și crearea de soluții utilizând mai multe limbaje de programare.

Microsoft Visual Studio a debutat în 1995 cu o versiune pilot, urmând ca în 1997 să fie lansată prima platformă integrată de dezvoltare software, bazată pe IDE-uri performante , cu suport pentru programarea web. [3] Deoarece acceptă mai multe limbaje de programare, Visual Studio asigură un mediu ce oferă un set complet de unelte de dezvoltare pentru aplicații ASP.NET, aplicații mobile, Visual Basic, Visual C++, Visual C#, servicii Web, dar și în crearea și editarea interfețelor web.

Visual Studio folosește framwork-ul .NET dezvoltat de Microsoft, cu ajutorul căruia se creează conexiuni între entitățile unui domeniu. Astfel în cadrul aceluiași proiect se pot utiliza mai multe limbaje de programare, constituind un avantaj major al mediului de dezvoltare Microsoft Visual Studio.

Tehnologii principale folosite

În acest subcapitol vor fi descrise tehnologiile care au stat la baza dezvoltării interfeței aplicației, web-ul reprezentând o colecție de tehnologii capabile de a transporta o gamă variată de informații pe Internet.

HTML5

HTML(HyperText Markup Language) reprezintă tehnologia principală ce stă la baza unui document web, fiind responsabilă cu transmiterea informțiilor browser-ului web (exemplu: Microsoft Internet Explorer, Mozilla Firefox, Opera, Safari Mac, Google Chrome ), precum și modul în care acesta va afișa conținutul.

Limbajul HTML a fost într-o continuă evoluție. La început, când singurul program de navigare era Mosaic se utiliza verisunea standard de HTML, HTML 1.0. Ulterior au apărut noi programe de navigare, fiind nevoie de noi standarde pentru Internet. Astfel au apărut versiunile 2.0, 3.0, 4.0, 4.1, de HTML fiecare aducând o nouă facilitate (tabele, formule matematice, diverse forme de scriere a stilului).

În prezent se utilizează standardul HTML 5, apărut in 2011 ce este într-o continuă dezvoltare. Acesta reprezintă o însumare a versiunii HTML4 cu XHTML1 și DOM2HTML (în special JavaScript), având ca obiective principale îmbunătățirea limbajului cu un suport pentru cele mai recente apariții.

Figura 2.2 – Logo HTML5

Sursa: https://ro.wikipedia.org/wiki/HTML5

Noua versiune introduce noi caracteristici sintactice cum ar fi: <video>, <audio>, <header>, <canvas>, <object>(pentru inluderea și manipularea în web a conținuturilor multimedia și grafice) și <section>,<article>,<dialog>,<nav>,<header>(pentru îmbunătățirea conținutului semantic al documentelor).

Structura unui document HTML este aceeași indiferent de standardul adoptat. Astfel pentru formatarea oricărui document HTML trebuie să utilizăm tag-urile: <html>, <head>, <body> ce transmit comenzi către browser. În interiorul acestor tag-uri vor fi introduse diverse tag-uri cu rol în editarea paginilor.

Figura 2.3 – Structura unui document HTML

Sursa: http://ciobanu.cich.md/lectii_view.php?id=1

2.2.2 CSS3

CSS (Cascading Style Sheets) este un limbaj bogat, oferind un control bazat pe proprietate peste multe aspecte ale documentelor HTML.[1] Apariția acestui standard a ușurat munca web-designerilor, făcând posibilă separarea conținutului documentului de prezentarea acestuia.

Standardul CSS formatează elementele unui document folosind stiluri. Cu ajutorul acestora elementele din cadrul unui document HTML care folosesc un anumit stil își pot schimba definiția. Astfel se reduce complexitatea structurii conținutului unei pagini web, nemaifiind necesară codificarea individuală a elementelor.

Definiția unui stil CSS este simplă, conținând un selector și o declarație bloc. Selectorul este o expresie utilizată pentru a potrivi elemente specifice în documentul HTML. Aceste elemente pot fi selectate pe bază de identitate, de clasă, de atribut, de tip etc. Blocul de declarație conține una sau mai multe declarații separate prin “;”. O declarație este alcatuită din proprietăți de stil și seturi de valori separate prin “:”.

Pentru a insera stilurile CSS într-un document HTML există trei modalități:

Atașarea unui fișier extern cu extensia “.css” în care se vor declara toate regurile de formatare asupra unui document HTML. Acest tip de fișier este util mai ales când dorim să edităm mai multe documente HTML cu aceleași stiluri.

Foaie de stil internă introdusă prin tag-ul <style>. Aceasta este utilizată atunci când fiecare document HTML are un stil unic.

Stilurile inline se introduce pentru fiecare tag în parte. Acestea sunt mai putin indicate deoarece conținutul este amestecat cu prezentarea.

În cazul în care un fișier HTML conține toate cele 3 tipuri de stiluri, stilurile inline au cea mai mare prioritate(vor suprascrie un stil definit în interiorul tag-ului <head>, sau într-un fișier extern).

Ca și în cazul tehnologiei HTML există mai multe versiuni ale standardului CSS, cea mai recentă fiind CSS3.

Figura 2.4 – Logo CSS3

Sursa: http://howtoprogram.wikia.com/wiki/File:CSS3.png

CSS3 aduce noi atribute ce contribuie la dezvoltarea noilor concepte de webdesign. Spre deosebire de versiunile anterioare în care caracteristicile erau incluse într-un singur bloc de specificații, CSS3 este împărțit pe module.

Cele mai importante module adaugate în CSS3 sunt:[4]

Selectors

Box Model

Backgrounds and Borders

Image Values and Replaced Content

Text Effects

2D/3D Transformations

Animations

Multiple Column Layout

User Interface

Framework-ul Boostrap

Boostrap este un framework dezvoltat de Twitter folosit pentru crearea paginilor web, conținând instrumente predeclarate și înglobând tehnologii HTML, CSS, JavaScript și funcționalități din jQuery. Astfel framework-ul Boostrap este un instrument utilizat pentru a gestiona cât mai bine faza inițială a unui proiect deoarece putem conta pe o serie de componente care pot fi reutilizate și personalizate oferindu-ne o bază solidă de pornire a proiectelor. [5]

Figura 2.5 – Logo Boostrap

Sursa: http://perdevelopment.org/bootstrap-framework-html-css-si-javascript/

În prezent este cel mai folosit framework pentru crearea interfețelor web deoarece este compatibil cu browserele moderne și permite realizarea de site-uri responsive ce se adaptează la orice rezoluție de dispozitiv.

Implementarea acestui framawork este destul de simplă, fiind utilă introducere în proiect scripturilor necesare.

Limbajul de programare JavaScript

JavaScript este un limbaj de programare obiect-orientat bazat pe prototipuri, dezvoltat inițial de Netscape Communication Corporation sub numele de Mocha, apoi LiveScript și în final JavaScript. La baza acestui limbaj stau sintaxe bazate pe limbajul C și anumite convenții de denumire preluate din Java. Limbajul JavaScript se aseamană cu limbajul C#, diferența dintre acestea fiind faptul că JavaScript este implementat în general pe partea de client, în timp ce C# pe partea de server.

Figura 2.6 – Logo JavaScript

Sursa: http://www.trinitive.com/best-e-commerce-website-tamilnadu_javascript.html

Limbajul JavaScript este un limbaj de scripting, folosit în special pentru introducerea anumitor funcționalități în paginile HTML care interacționează cu DOM-utile din pagină. Astfel programatorii web pot îngloba în paginile HTML script-uri pentru diverse activități cum ar fi verificarea datelor introduse de utilizatori sau crearea de meniuri și alte efecte animate.[6]

jQuery

jQuery este o bibliotecă JavaScript, cu rolul de a simplifica programarea în acest limbaj. Este cea mai utilizată librărie JavaScript având o mulțime de funcționalități și rulând pe multiple platforme.

Figura 2.7 – Logo jQuery

Sursa: https://en.wikipedia.org/wiki/File:JQuery_logo.svg

jQuery este un software liber, open-source, ce ajută programatorii web prin simplificarea manevrării documentelor și animațiilor, selectarea și modificarea elementelor DOM, cât și în dezvoltarea de aplicații AJAX.

În cadrul unui proiect librăria JQuery este inclusă într-o pagină web printr-un link la copia locală a fișierului sau la una din multele copii disponibile pe serverele publice. [7] Această librărie conține un fișier JavaScript, compus din cele mai utilizate DOM-uri, evenimente, efecte și funcții AJAX.

AJAX

AJAX(Asynchronous JavaScript and XML) reprezintă o tehnică de construire a paginilor web, folosind standardele existente. Un mare avantaj îl reprezintă schimbul de date cu serverul în mod asincron, adică este posibilă actualizarea paginilor fară a fi necesară reîncarcarea întregii pagini.

AJAX reprezintă un grup de tehnologii. Pentru a marca informații de stil se poate utiliza în combinație cu HTML și CSS. Pentru schimbul de date cu serverul se utilizează JavaScript și obiectul XMLHttpRequest. Acest obiect nu este obligatoriu să fie de tip XML, locul acestuia putând fii luat de JSON(JavaScript Object Notation). Astfel, folosind metodele JavaScript și obiectul transmis, există posibilitatea de a interoga informațiile fără a se reîncarca toată pagina, dezvoltându-se interfețe web cu timp de răspuns mic.

JSON

JSON (JavaScript Object Notation) este o sintaxă pentru stocarea și schimbul de date. Este un format text, inteligibil pentru oameni pentru reprezentarea obiectelor și a altor structuri de date și este folosit în special pentru a transmite date structurate prin rețea, procesul purtând numele de serializare. [8] Această serializare se referă la faptul că un obiect este compus din mai multe elemente pentru a fi transmis, iar la recepție este descompus în părțile componente. JSON reprezintă o alternativă pentru XML deoarece este mai simplu din punct de vedere al construcției și al transmiterii datelor. Fiind mai simplu de construit sunt și mai rapide, elementele de tip JSON devenind din ce în ce mai populare în dezvoltarea aplicațiilor Web 2.0 .

JSON este un subset al limbajului JavaScript, iar codarea se face unicode.

Adobe Photoshop

Adobe Photoshop , așa cum este cunoscut astăzi, este vârful de lance al gamei de produse software pentru editare de imagini digitale, fotografii, grafică pentru tipar, video și Web de pe piață.[9] Adobe Photoshop a luat naștere în 1988 din pasiunea pentru fotografie și editarea imaginilor a fraților Thomas și John, împreună cu tatăl lor Glenn Knoll. Reușind să obțină licență de la Adobe, în anul 1990 a fost lansată prima versiune a programului Adobe Photoshop.

Photoshop este un program cu o interfață intuitivă și care permite o multitudine extraordinară de modificări necesare în mod curent profesioniștilor și nu numai: editări de luminozitate și contrast, culoare, focalizare, aplicare de efecte pe imagine sau pe zone (selecții), retușare de imagini degradate, număr arbitrar de canale de culoare, suport de canale de culoare pe 8, 16 sau 32 biți, efecte third-party etc.[9]

Programul suportă un număr mare de formate de imagine, dar are și propriile formate PSD si PSB. Formatul PSD este utilizat pentru salvarea datelor, fișierele având acest format permițând utilizatorului să lucreze cu straturi individuale ale imaginii.

Adobe Photoshop este disponibil în mai multe versiuni, actuala versiune fiind Adobe Photoshop CS6.

Google Maps API

Conceptul Google Maps API

Google Maps reprezintă un serviciu dezvoltat de Google pentru web, desktop și dispozitive mobile, ce oferă imagini din satelit, hărți stradale, vederi panoramice de străzi (Street View ), condițiile de trafic în timp real (Google Traffic) și planificarea rutelor de călătorie pe jos, cu mașina, bicicleta (în versiunea beta) sau transportul public. Google Maps permite realizarea de geo-mashup-uri și se încadrează în categoria sistemelor informaționale geografice(GIS-Geographic Information Systems). Aceste sisteme permit computerului să adauge datelor deținute diverse componente geografice indicând localizarea acestora. [10] În iunie 2005 Google a lansat gratuit pentru uz comercial (prezintă limitări ale traficului ), Google Maps API. Acesta reprezintă un mare avantaj, deoarece permite dezvoltatorilor să integreze Hărți Google în propriile aplicații.

Google Maps este codificat aproape integral în JavaScript și XML, ceea ce înseamnă ca poate fi integrat cu success în aplicația prezentă. Google Maps API a fost extins și pentru aplicații Adobe Flash, fiind astfel utilizat în majoritate site-urilor web.

Google Maps API este folosit în doua moduri: Google Static Maps API și Google Maps Javascript API.

Google Static Maps API permite adăugarea unei imagini Google Maps într-o pagină web, fără a necesitata JavaScript, ci pe baza unor parametrii URL.

Google Maps Javascript API asigură o încărcare dinamică a unei imagini într-o pagină web.

Pentru a putea încărca o imagine utilizând Google Maps API este necesară o cheie ce permite monitorizarea traficului aplicației.

Implementarea Google Maps API într-un proiect nu prezintă mari dificultăți. În momentul implementării avem posibilitatea adăugarii de noi opțiuni, de a formata harta și elementele ce se află pe aceasta.

Avantaje și dezavantaje Google Maps API

În ultimii ani serviciile de mapare online au început să fie mult mai utilizate decât hărțile printate, datorită multitudinii de informație pe care o oferă. Unul dintre aceste servicii este Google Maps ce prezintă o gamă largă de avantaje cum ar fi:

moduri diferite de vizualizare a hărții: ROADMAP – mod de vizualizare 2D, SATELLITE – oferă imagini din satelit, StreetView – vederi panoramice de străzi, TERRAIN – informații despre teren ( munți, râuri, câmpii, etc. ) și un mod personalizat de către utilizatori prin introducerea hărții cu ajutorul API-ului.

modul personalizat oferă utilizatorului posobilitatea de a-și crea propriile locații și indicații despre acestea, precum și posibilitatea de a salva ăn format electronic sau printat

imaginile prin satelit prezintă o rezoluție foarte bună pentru majoritatea zonelor urbane ale lumii

datorită Google Taffic utilizatorii pot vizualiza condițiile de trafic în timp real

( disponibilitatea drumurilor, fotografii din zonă, camere video din jurul locației, etc. ), și pot calcula distanța dintre două locații în funcție de mijlocul de transport ales

în fucție de locație oferă rute alternative și timpul estimativ al acestora

permite utilizatorului să mărească anumite porțiuni, sau întreg drumul. Nivelul de zoom depinde de zonă

suportă toate browserele moderne

Deși este un serviciu util, cu multe avantaje, Google Maps prezintă și câteva dezavantaje:

în cazul unei conexiuni slabe la internet, imaginile se vor încarca greu deoarece au dimensiuni mari

pot exista informații neactualizate sau imprecise

Prezentare aplicație

În cadrul acestei lucrări se propune dezvoltarea interfeței web-responsive a aplicației de gestiune arheologică RM360 din programul „Adoptă o casă la Roșia Montană”. Aplicația oferă utilizatorilor posibilitatea de a vizualiza, adaugă, șterge sau modifica fișe de gestiune standardizate, corespunzătoare anumitor locații. Aceste acțiuni nu sunt permise oricărui utilizator, ci sunt împărțite în două categorii: utilizatorii de tip vizitator care doar pot vizualiza fișele și utilizatorii cu drepturi de a realiza diferite acțiuni asupra acestora.

Rolul meu în acest proiect, este de a implementa intefața grafică, împreună cu fucționalitățile corespunzătoare și crearea legăturilor cu metodele existente în serverul de back-end. Altfel spus, mă ocup de partea de frontend a aplicației, adică acea parte dedicată clientului. Întreaga interfață este dezvoltata folosind HTML5, CSS3 și clase de boostrap pentru asigurarea caracterului responsive. Pentru a putea folosi clasele standard de boostrap, în secțiunea <head> a fiecărui document HTML sunt inserate scripturile ce fac trimitere la fișierele ce cuprind aceste clase. Aspectul dinamic al interfeței și funcționalitatea sunt date de scripturile inserate, funcțiile de JavaScript și jQuery create și de conexiunea cu serverul (colectarea datelor ce vor fi procesate). Documentele HTML sunt formatate în fișiere cu extensia „.cshtml”, deoarece codul HTML este îmbinat cu cel de server prin folosirea sintaxelor razor. Aceste sintaxe sunt introduse în fișierul HTML prin caracterul „@” și au rolul de a asigura dinamica paginii prin rularea codului și trimiterea paginii la browser. Un mare avantaj al sintaxei razor îl constituie crearea dinamică a conținutului de client.

Având în vedere aceste caracteristici, am dezvoltat în Visual Studio 2012 o interfață web-responsive, care în fucție de logare prezintă trei componente importante:

interfața utilizatorului cu drept de administrator (admin)

interfața utilizatorilor de tip vizitator/guest (user)

interfața utilizatorilor de tip supervizor

Principiul de funcționare al aplicației este relativ simplu: la accesarea aplicației se va deschide pagina principală ce conține o serie de informații despre aceasta și un formular de contact , prin care se poate lua legătura cu persoanele ce administreză aplicația. Din această pagină utilizatorul poate naviga către pagina ce cuprinde lista obiectivelor intratate în program (acestea pot fi monumente, case etc. ), iar din aceasta către pagina unui obiectiv. În această pagină se va găsi și fișa de gestiune arheologică. Din pagina principală se face și redirecționarea către pagina de logare. După logare în funcție de permisiunea contului se va face redirecționare către secțiunea dedicată administratorului, sau supervizororului. Administratorul are drepturi depline asupra aplicației, având voie să facă orice modificare asupra acesteia, poate oferi permisiuni unui cont , citește mesajele de la utilizatori. Supervizorul are aceleași drepturi ca administratorul, mai puțin managementul conturilor de utilizatori.

Conform principiului de funcționare, descris și în diagrama de mai jos, user-ul are dreptul doar de a vizualiza informațiile, fără a putea efectua modificări, în timp ce supervizorul și administratorul pot realiza o serie de acțiuni.

Figura 3.1 – Diagramă UML a aplicației în funcție de logare

(creată pe site-ul http://yuml.me/ )

Interfața dedicată utilizatorilor de tip vizitatori/ guest (user)

Această secțiune este disponibilă tuturor vizitatorilor care doresc să obțină informații despre programul „Adoptă o casă la Roșia Montană” și obiectivele de patrimoniu intrate în program. Fiind o categorie de utilizatori cu restricții, vizitatorii aplicației au acces doar de a vizualiza informațiile oferite de aplicație și de a contacta persoanele ce o administreză ( administrator, supervizor), pentru a solicita mai multe informații. Pentru o înțelegere mai ușoară a funcționării acestei părți din aplicație, mai jos am inserat o diagramă în care sunt detaliate acțiunile la care au acces acest tip de utilizatori.

Figura 3.2 – Diagramă de funcționare a secțiunii dedicate userilor

(creată pe site-ul http://yuml.me/ )

Pagina principală

Această pagină este cea care întâmpină utilizatorii aplicației fiind setată implicit din back-end ca pagină de start.

Pentru a crea design-ul paginii de pornire a aplicației am avut ca punct de plecare un model deja existent oferit gratuit pe site-ul http://www.bootstrapzero.com/ , pe care l-am editat cu elemente de stilizare CSS3 conform cerințelor aplicației.

Din punct de vedere al structurii fișierului HTML în care a fost creată interfața este de tipul:

@{

ViewBag.Title = "Home";

}

@{

Layout = null;

}

<html>

<head>

<meta charset="utf-8">

<!– Css Files–>

@Styles.Render("~/Content/themes/sitecss/css")

<!– Script Files –>

@Scripts.Render("~/bundles/sitescripts")

<!– GoogleMaps Script –>

<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false"></script>

<title> Home </title>

</head>

<body>

/* div-uri pentru construirea și delimitarea secțiunilor */

</body>

</html>

Partea de sus, înainte de structura propriu-zisă a unui document HTML, asigură legătura cu server-ul, iar „Layout = null;” are rolul de a semmnala că nu există un model deja existent pe bza căruia se construiește pagina.

Tag-ul <html> este folosit pentru a informa browser-ul în legătură cu formatul paginii ce urmează să o deschidă.

În secțiunea <head> este specificat tipul de codare a caracterelor, în cazul de față UTF-8, fiind cea mai folosită formă de codificare a textului deoarece suportă caractere speciale pentru mai multe limbi, nu numai pentru limba engleză. De asemenea în această secțiune sunt introduse scripturile necesare încărcării paginii și fișierele de stil externe. Am optat pentru fișiere de stil externe deoarece reprezintă o metodă practică, eliminând timpul necesar introducerii codului specific fiecărei pagini. Tot în această secțiune este inserat și scriptul necesar încărcărcării și vizualizării hărții Google, necesare acestei aplicații. Între tag-ul <title> am introdus numele paginii, ce va apărea în url-ul din browser la încărcarea paginii.

În secțiunea <body> se întâlnesc în special tag-uri <div>, ce au rolul de a diviza pagina în mai multe părți. În interiorul tag-rilor <div> pot exista mai multe elemente de formatare, în funcție de rolul fiecărui element formatat.

Din punct de vedere al design-ului și al funcționalității pagina de start cuprinde un mic carusel cu imagini de la Roșia Montană ( preluate de pe http://www.mixdecultura.ro/2013/09/ și https://turismrosia.wordpress.com/poze-rosia-montan/ ) și o bară de meniu, care se pot vedea în figura 3.2 și footerul în care sunt link-uri de redirecționare către site-ul oficial al programului „Adoptă o casă la Roșia Montană” ( http://www.adoptaocasa.ro/ ) și către pagina oficială de facebook a acestuia.

Carusel-ul și bara de meniu sunt implementate folosind clase de boostrap și au fost stilizate conform design-ului propus prin adăugarea de clase noi, pe care le-am declarat în fișierele de stil externe atașate documentului HTML.

Pentru construirea footer-ului, nu am folosit clase predefinite, ci am construit clasa „footer”, prezentată mai jos, conform definiției CSS.

.footer {

padding-top: 20px; // distanța de la marginea de sus a footer-ului păna la conținutul // acestuia

text-align: center; // aliniere text

background-color: #2e2e2e; // culoare background

color: #888888; // culoare scris

font-family: 'Open Sans', sans-serif; // tipul scrisului

font-size: 15px; // mărimea scrisului

padding-bottom: 20px; //distanța de la marginea de sus a footer-ului păna la conținutul // acestuia

width:100%; // lățime footer

left:0; // margine stânga

bottom:0; // margine dreapta

position:fixed; // mod poziționare

}

Am optat pentru folosirea unei clase și nu a unui id, pentru a putea formata și footer-ul celorlalte pagini din secțiunea dedicată utilizatorilor. Declarațiile acestei clase sunt utile atât design-ului ( dimenisiune, culoare, tip scris), precum și pentru asigurarea caracterului responsive (prin setarea modului de poziționare și folosirea procentelor pentru valoarea proprietății „width”).

Figura 3.3 – Interfața de pornire

Figura 3.4 – Footer interfață de pornire

Bara de meniu conține șase tab-uri: primele patru fac scroll la secțiunea specifică, iar ultimele două redirecționeză utilizatorii către pagina cu lista obiectivelor și către pagina de log-in. Cele șase tab-uri sunt introduse prin li-uri, sub forma unei liste, iar pentru a putea face scroll direct în secțiunea dorită, fiecare prezintă câte un id. De exemplu pentru secțiunea „Home” avem:

<li class="lead"><a href="#section1">Home</a></li>

<div class="divider" id="section1"></div>

Clasa .divider {

height:50px;

}

are rolul de a aloca fiecărei secțiuni o anumită dimensiune. Clasa „lead” conține proprietăți pentru editarea fontului și a culorii.

Pentru a știi cu exactitate în cadru cărui tab se află sau ce tab a accesat anterior, am adăugat acesora un hover negru.

.navbar-custom .navbar-nav li>a:hover, .navbar-nav li .open, .navbar-custom .navbar-nav .active a {

background-color: #000; // culoare fundal

height: 68px; // lățime

}

În secțiunea „Home” sunt oferite informații despre programul „Adoptă o casă la Roșia Montană”, preluate de pe site-ul oficial, logo-ul aplicației RM360 și logo-ul programului (sursa: http://www.simpara.ro/rosia-montana-360-expo-atelier-567.htm ).

În secțiunea „Localizare” este introdusă o imagine din satelit cu poziționarea localității Roșia Montană. Această hartă este introdusă folosind Google Maps API. Am optat pentru o hartă Google Maps API deoarece aceesta oferă o mulțime de opțiuni, oferă flexibilitate în vizualizarea hărții, față de cea statică ce reprezenta o simplă imagine pe care atașez marcaje. Google API oferă posibilitatea modificării nivelului de vizualizare al hărții prin modificarea proprietății „zoom”, astfel se poate extinde aria de vizualizare, sau se poate vizualiza mai în detaliu o anumită arie a globului pământesc.

Primul pas pentru introducerea hărții în aplicație este adăugarea script-ului.

<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false"></script>

Acesta cuprinde două atribute: primul specifică tipul scriptului, iar al doilea locația fișierului JavaScript necesar folosirii API-ului Google Maps. „sensor=false” indică faptul că dispozitivul care utilizeaza harta nu poate detecta geolocații. După inserarea API-ului, următorul pas a fost introducerea hărții, prin crearea unui script de jQuery, conform documentației oficiale Google Maps API.

<script type="text/javascript">

$(document).ready(function () {

initialize();

});

function initialize() {

var mapOptions = {

center: new google.maps.LatLng(46.306293, 23.130430),

zoom: 16,

mapTypeId: google.maps.MapTypeId.SATELLITE

};

var map = new google.maps.Map(document.getElementById("map_canvas"),

mapOptions);

// create a marker

var latlng = new google.maps.LatLng(46.306293, 23.130430);

var marker = new google.maps.Marker({

position: latlng,

map: map,

title: 'Rosia Montana'

});

}

</script>

Variabila „mapOptions” conține trei proprietăți importante despre cum se va vizualiza harta în pagină, primele două fiind opțiuni obligatorii. În „center” se setează locația exactă în care se va deschide harta inițial, prin crearea unui obiect de tip „LatIng”, ce reprezintă un punct geografic. Acest punct geografic este caracterizat de latitudine și longitudine, ambele specificate în grade. Pentru specificarea latitudii avem intervalul [-90, 90], iar în cazul longitudinii [-180,180]. Proprietatea „zoom” specifică rezoluția inițială la care va afișată harta. Deoarece Google Maps API oferă o hartă a întregului Pământ într-o singură imagine, pentru a nu crea o hartă imensă, au optat pentru împărțirea acesteia în 21 de nivele de zoom. Pentru harta introdusă în proiectul meu am considerat ca nivel de zoom 16, pentru ca harta introdusă să nu acopere o suprafață mai mare, ci o arie relative mică din jurul puctului meu de interes. Deși am setat nivelul de zoom, acesta poate fi modificat de utilizator în momentul vizualizării hărții din butoanele din partea stangă: „-”, „+”.

În „mapTypeID” am setat modul în care vreau să apară afișată harta inițial. „MapType” este un obiect folosit de API-ul Google Maps, ce definește ecranul și utilizarea datelor hărții și transpunerea sistemelor de coordonate de la coordonatele ecranului, la coordonatele pe hartă. [12].

Există patru moduri de afișare, ce se setează folosind „MapTypeId”

ROADMAP, tipul de afișare standard ce afișează o hartă rutieră

SATELLITE, afișează imagine din satelit

HYBRID, adaugă și etichete imaginii din satelit

TERRAIN, afișează o hartă fizică

În cazul de față am optat pentru o imagine din satelit, dar această afișare se va putea schimba din cele două opțiuni aflate în partea dreapta sus a hărții, pe care utilizatorul le poate accesa printr-un click.

Pentru crearea obiectivului map se crează o instanță, folosind opertorul „new”. Astfel declarăm variabila „map”, în care prin metoda (document.getElementById(), se face referire la elementul cu id-ul „map_canvas”. Acest element se găsește în codul HTML, destinat hărții. Astfel, în secțiunea cu id-ul destinat locației se crează prin div-uri container-ul destinat hărții. În interiorul div-ului am introdus id-ul care face referire la obiectul de tip JavaScript „document” și stil-uri inline pentru editarea container-ului în care va fi inserată harta. Butonul creat apelează funcția, resetând harta la modul inițial de vizualizare.

<div class="row"> // rând nou

<div class="col-sm-10"> // partea unui rând pe care poate să o acopere

<h1 class="title">Locație</h1><hr> //titlu separate de conținut prin folosire tag <hr>

<div id="map_canvas" style="width:100%;height:300px !important;">

</div> // spațiul propriu-zis încărcării hărții

<input type="button" class="btn btn-default" onClick="initialize();" value="Rosia Montana"> // construirea butonului ce apelează scriptul jQuery creat

</div>

</div>

Funcția „initialize” conține și variabilele în care se creează marker-ul. Acesta este caracterizat de trei proprietăți: position, map și title. „position” este o proprietate obligatorie, deoarece are rolul de a specifica locația, printr-un obiect de tip LatIng. Proprietățile „map” și „title” sunt opționale. Prima specifică harta pe care se va afișa marcajul, iar a doua numele acestuia. Deși este o proprietate opțională, în cazul în care nu se specifică harta, marcajul nu va fi afișat.

Figura 3.5 – Secținea dedicată hărții din pagina principală

Secțiunea „Obiective” cuprinde obiectivele de patrimoniu intrate în program ( monumente, case ). Această secțiune are rolul de scurtă prezentare a acestora( poate vedea numele și o imagine)

Secțiunea „Contact” este destinată utilizatorilor care doresc să contacteze administratorul aplicației. Pentru a putea trimite un mesaj administratorului, utilizatorul este obligat să introducă numele și adresa de e-mail, ce sunt setate cu proprietatea „required”. În cazul în care unul dintre aceste câmpuri nu este completat, în momentul în care dă click pe butonul „Contact”, va apărea mesajul „Completează acest câmp” în dreptul input-ului respectiv. Câmpurile acestei secțiuni sunt delimitate prin div-uri, ce fac parte dintr-un form ce se încheie prin apăsarea butonului „Contact”, ce face trimiterea în mod invizibil utilizatorului către pagina setată la începutul form-ului.

Tab-ul „Informații obiective” redirecționează utilizatorii către pagina cu lista obiectivelor introduse în aplicație. Alegând un obiectiv din tabel se va deschide o pagină ce conține informații despre acesta și fișa lui de gestiune.

Tab-ul „Sign in”, este accesat de către administrator, utilizatorii de tip supervizori ( pentru a putea avea acces în secțiunile dedicate acestor tipuri de utilizatori ) și de către utilizatorii de tip vizitatori care doresc să se înscrie în programul „Adoptă o casă la Roșia Montană”, pentru a ajuta la conservarea patrimoniului cultural.

Pagină logare (log in)

În această pagină se poate ajunge atât din pagina de start, cât și cele dedicate monumentelor. Este o pagină dedicată în special utilizatorilor cu permisiuni, utilizatorii de tip vizitatori nu au niciun beneficiu după logare. Pagina are un design simplu alcătuit din trei elemente principale, separate prin tag-uri de tip <div>:

bara de meniu ce conține logo-ul aplicației, și trei tab-uri dintre care primul este un link de navigare către prima pagină, iar celelate două sunt modale (primul pentru descrierea aplicației, iar celălalt pentru contact)

câmpurile necesare introducerii datelor pentru autentificare ( nume utilizator și parolă)

footerul în care este scris numele aplicației

Figura 3.6 – Interfață pagină logare

Pentru construirea modalelor am folosit structura standard cu clasele caracteristice ( modal-header, modal-body ), iar conținutul a fost stilizat folosind elemente CSS.

Modalul pentru contact este integrat între etichetele <form> și </form> deoarece am creat un formular în care utilizatorul introduce date ce vor fi transmise către o anumită adresă URL.

<form name="Contact" method="post" action="@Url.Action("Contact","Home")"> Sintaxa cuprinde elementele principale necesare unui form: un nume unic, metoda prin care se transmit datele (am folosit o metodă de tip „POST” deoarece nu doresc să trimit o informație vizibilă utilizatorului și restricționată din punct de vedere al cantității), iar în action am adăugat url-ul paginii către care se tranmit informațiile form-ului. Toate aceste informații se transmit după apasarea butonului „Contact”, ce are rolul de a trimite datele introduce în formular către server ( are setat ca tip „submit”). Câmpurile pentru nume, adresă e-mail, număr telefon sunt de tip „input” , iar pentru câmpul destinat mesajului am folosit tag-ul <textarea>, fiind necesară editarea textului în mai multe rânduri. Pentru toate câmpurile am folosit proprietatea „placeholder”, proprietate specifică HTML5, ce reprezintă un indiciu afișat în zona de text, atunci când aceasta este goală și dispare în momentul în care este accesat acel input. De asemenea, câmpurile obligatorii pentru trimiterea unui mesaj sunt marcate , având proprietatea „required”.

<input class="input-contact pull-left" type="text" name="Name" id="nume" required placeholder="Nume (*)" /> Cele două clase sunt create pentru formatarea input-ului conform design-ului.

Câmpurile destinate autentificării fac parte dintr-un <form>, ce transmite datele către action="@Url.Action("Login","Account")"(metoda Login din controller-ul Account) printr-o metodă de timp „POST”. Câmpurile sunt de tip „input” cu proprietatea „placeholder”. Câmpul în care se introduce parola este de tip „password”, pentru ca browser-ul să înțeleagă că nu trebuie să afișeze conținutul introdus sub formă de text. Cele două imagini din input-uri sunt preluate de pe http://glyphicons.com/ decupate și redimensionate în Adobe Photoshop CS6. Butonul are setat ca tip „submit”, deoarece are rolul de a executa acțiunea formu-ului din care face parte.

Utilizatorii care nu au cont pentru autentificare, folosesc opțiunea „ Sign Up” , ce reprezintă un link de redirecționare către pagina „Register”, unde se pot înregistra.

Pagină creare utilizator nou (register)

Figura 3.7 – Interfață pagină înregistrare

Interfața paginii de înregistrare a unui nou utilizator, urmarește acelaș format ca cel al paginii de logare, singura diferență fiind input-urile. Astfel elementele de stil folosite pentru formatarea paginii HTML sunt cele utilizate pentru pagina de logare.

Pagini obiective

În această pagină utilizatorii pot găsi mai multe informații despre un obiectiv cultural intrat în program, cum ar fi infomații arhitecturale, anul ridicării, utilitatea acestuia, precum și localizarea.

Pentru a accesa pagina obiectivului dorit utilizatorii dau click pe tab-ul „Informații Obiectiv” din prima pagină, de unde vor fi redirecționați către o pagină ce cuprinde un tabel cu numele acestora. Din acest tabel, utilizatorii aleg obiectivul dorit și se va deschide o pagină de tipul celei din figura 3.7. Din păcate în acest moment, sunt disponibile informații doar pentru o parte din obiectivele intrate în program, despre celelalte, utilizatorii pot obține informații accesând site-ul oficial al programului „Adoptă o casă la Roșia Montană” (legătura cu site-ul oficial se poate face și din footer-ul paginii).

Figura 3.8 – Model interfață pagină obiective

Pentru paginile create am optat pentru un design simplu.

Pagina cu lista obiectivelor cuprinde un header și footer ca și paginile de logare și înregistrare utilizator nou, iar conținutul este un tabel cu două coloane ( Denumire obiectiv și Vizualizare detalii). În coloana „Vizualizare detalii” se găsește un buton prin care se face redirecționarea către pagina obiectivului respectiv. Pentru a fi redirecționat către pagina dorită este accesată funcția „redirect”, printr-o metodă de tip onclick="redirect(@item.SiteId);"

Funția are ca parametru id-ul, deoarece în funcție de acesta se cunoaște pagina cărui monument va fi încărcată. Astfel variabilei „x” i se adresa paginii create pentru obiectiv și id-ul pentru a se cunoște și obiectivul selectat. După atribuire se face redirecționarea către pagina dorită.

function redirect(id)

{

var x = "@Url.Action("ViewSite", "Home")"+"/"+id;

window.location.href = x;

}

În partea dreaptă a paginii obiectivului, există numele și anul ridicării, o imagine reprezentativă a acestuia, precum și informații cu privire la localizare ( adresă, coordonate ). Tot aici se găsește butonul „Vizualizare fișă”, care deschide un modal ce cuprinde fișa de gestiune standard a respectivului obiectiv. Restul paginii cuprinde descrierea clădirii și o hartă introdusă folosind Google Maps API, ca și în pagina principală.

$(document).ready(function () {

initialize();

});

function initialize() {

var mapOptions = {

center: new google.maps.LatLng('@Model.PosX', '@Model.PosY'),

zoom: 17,

mapTypeId: google.maps.MapTypeId.ROADMAP

};

var map = new google.maps.Map(document.getElementById("map_canvas"),

mapOptions);

// create a marker

var latlng = new google.maps.LatLng('@Model.PosX', '@Model.PosY');

var marker = new google.maps.Marker({

position: latlng,

map: map,

title: '@Model.Name'

});

}

Funcția este creată urmând aceași structură ca cea din prima pagină, numai că aici, informațiile sunt inserate în mod dinamic( latitudinea și longitudinea prin @Model.PosX' și @Model.PosY', iar numele prin '@Model.Name' ). O altă diferență este efectuată asupra proprietăților variabilei „mapOptions” . am optat pentru un zoom de nivel 17, pentru a-mi arata zona mai restransă din jurul obiectivului , iar modul în care este afișată harta este cel standard.

Toate informațiile acestei pagini nu sunt introduce în codul HTML, ci vin în mod dinamic prin sintaxele de razor introduce în locul dedicat introducerii acestora. Am optat pentru această metodă deoarece constituie mai multe avantaje cum ar fi: economisire timp și resurse deoarece nu a fost necesară construirea mai multor pagini (pentru fiecare obiectiv în parte), este posibilă adăugarea de noi obiective fără a se face vreo modificare în codul HTML(creare de noi documente HTML).

Header-ul și footer-ul conțin link-uri utile user-ului ( către pagina principală, contact, login, către pagina de facebook și către site-ul oficial). Header-ul este construit folosind clase predefinite de boostrap ( clasa nav specifică meniurilor de navigare), iar așezarea tab-urilor este realizată cu ajutorul elementelor de stil CSS.

Pentru dispozitivele de rezolutie mică, partea din dreapta se comportă ca un dashboard. Astfel, tab-urile din header și conținutul din partea dreaptă a paginii sunt compactate într-un meniu de tip dropdown, ca în figura 3.8. Aici ele apar ca o listă, deoarece în fișierul HTML sunt introduse în interiorul tag-ului <ul>, specific listelor neordonate, prin tag-ul <li>. Acest lucru a fost posibil prin editarea claselor cu elemente de stil create inițial pentru diferite rezoluții. Am ales modificarea acestuia pentru rezoluții mai mici de 768pixeli, iar pentru compactarea în dropdown, am folosit clasele de bootstrap „dropdown” și „dropdown-menu”. Pentru a putea fi posibilă derularea conținutului din bara de meniu în momentul apăsării butonului am folosit proprietatea overflow-y: auto; ce derulează bara de meniu pe direcție verticală atunci când este necesar, iar valoarea „relative” a proprietății „position” permite schimbarea poziției inițiale, asigurând astfel caracterul responsive al dashboard-ului.

@media (min-width:768px) { //pentru rezoluții mai mici de 768px

.side-nav {

margin-left: -225px; //margine stânga

width: 335px; //lățime

position: fixed; // mod poziționare

top: 50px; // margine sus

height: 100%; //înălțime

border-radius: 0; // margine rotunjită

border: none; //margine

background-color:#2e2e2e; // culoare fundal

overflow-y: auto; // modu în acre apare conținutul (de sus în jos)

}

.side-nav>li.dropdown>ul.dropdown-menu { // proprietățile clasei side-nav pentru dropdown

position: relative;

min-width: 225px;

margin: 0;

padding: 0;

border: none;

border-radius: 0;

background-color: transparent;

box-shadow: none;

-webkit-box-shadow: none;

}

}

Figură 3.9 – Model interfață-responsivă pagină obiective

Pentru deschiderea modalului am creat un mic script de jQuery ce se apelează în momentul în care apăsăm butonul „Vizualizare fișă”, printr-o metodă de tip onclick="showModal()".

function showModal() {

$('#extend').modal('show');

}

Majoritatea claselor folosite pentru crearea modalului sunt clase de boostrap, pentru o structurare mai ușoară a elementelor de conținut. Pentru dimensiunea header-ului și culoarea modalului am creat doua clase cu proprietăți de culoare și dimensiune, iar pentru butonul „close” am folosit formatare cu stil inline style="color: red !important;" pentru a mă asigura că la încărcare browser-ul va înțelege formatarea acestuia.

Fișa este structurată în șapte subcategorii, scrise pe fundal verde, care la rândul lor oferă anumite informații structurate. Aceste subcategorii sunt create folosind clasele de bootstrap „panel” și „panel-success” , iar împărțirea se face prin clasele „panel-header” și „panel-body”. întreg modalul este structurat în div-uri, pentru ca fiecare clasă să-și cunoască încadrarea în interiorul acestuia. Ca și restul conținutului, paginii de obiective și modalul reprezintă un format tip pentru toate obiectivele din baza de date și cele care urmează a fi inserate. De aceea toate informațiile oferite de acesta, mai exact cuprinsul fiecărei subcategorii, sunt inserate în mod dinamic, prin legături directe cu baza de date.

<div class="panel panel-success"> // panelul ce cuprinde toate subcategoriile

<div class="panel-heading"> //header panel

<h3 class="panel-title">Analiză Urbanistică</h3> //titlu panel

</div>

<div class="panel-body" id=""> //corpul panelului

<div class="panel panel-default"> // panel subcategorie

<div class="panel-heading"> // header panel

<h3 class="panel-title">Forma Parcelei</h3> //titlu

</div>

<div class="panel-body" id=""> // conținut

@Model.SiteShape //preia informație

</div>

/* informații obiectiv*/ </div>

Figura 3.10 – Modal fișă obiectiv

În cazul în care nu există fișă pentru un obiectiv se va deschide un modal de eroare cu mesajul „Nu există fișă pentru acest obiectiv momentan”.

Conținutul modalului este introdus în mod dinamic. Astfel dacă nu se găsesc informații în baza de date (@if (Model.Exists == 0) ) va fi afișat acest modal, în caz contrar modalul cu fișa obiectivului.

Conținutul modalului eroare urmează aceeași structura ca și cel cu fișa: titlu și conținut, singura diferență fiind clasa principală, care în acest caz este „panel-danger”, pentru a transmite vizual un semnal de eroare. Conținutul acestui modal este formatat în cod HTML.

Figura 3.11 – Modal eroare

Interfața dedicată utilizatorului cu drept de administrator (admin)

Această secțiune este dedicată utilizatorului cu drept deplin asupra aplicației, administratorul. Acesta este singurul care are acces pentru a administra aplicația. În această secțiune paginile urmează aceeași structură din punct de vedere al design-ului: în partea dreaptă un dashboard cu tab-urile necesare și conținutul în funcție de utilitatea paginii. Deși dashboar-ul î-l vom întâlni în toate paginile acestei părți a aplicației, nu am optat pentru editarea acestuia într-o pagină separată ce va servi pe post de plan (layout ) pentru toate paginile. Adăugându-l în codul fiecărei pagini, am optat pentru adăugarea clasei

.selected {

border-left:7px solid #2A9FD6;

}

tab-ului cu numele paginii în care ne aflăm. Astfel tab-ul respectiv va apărea selectat printr-o bară verticală de culoare albastru, servind pe post de informție,dar și ca element de design al respectivei pagini.

Acțiunile administratorului asupra aplicației sunt prezentate în diagrama din figura 3.11.

Figura 3.12 – Diagramă de funcționare a secțiunii dedicate administratorului

(creată pe site-ul http://yuml.me/ )

Pagină administrator

După logare, dacă contul introdus are permisiune de administrator va fi redirecționat în secțiunea care îi este destinată, unde se va deschide o pagină de tipul celei din figura 3.13. Această pagină cuprinde toate instrumentele necesare administratorului pentru a putea gestiona aplicația ( vizualizare mesaje, listarea utilizatorilor și drepturile acestora, editare/adăugare/ștergere obiective). Astfel am conceput un design prietenos administratorului, pentru a găsi foarte ușor ce are nevoie.

Partea dreaptă a paginii cuprinde un dashboard cu șase tab-uri, de unde administratorul poate ajunge în pagina principlă, administra aplicația sau a ieși din aceasta. Primul tab conține url-ul paginii de administrator. Acest dashboard este folosit în toate paginile din această secțiune pentru o navigare mai ușoară. Design-ul acestuia a fost creat folosind clasele implementate pentru paginile obiectivelor, pe care le-am mutat în fișierul de stil extern specific acestei secțiuni. Nu am folosit fișierul extern paginii de obiective pentru a nu se produce conflicte, dorind o altă editare a paginii (adăugare de noi proprietăți de stil claselor deja existente, sau editarea lor, adăugare noi clase). De asemenea pentru dispozitivele de rezoluție mică dashboard-ul împreună cu header-ul se compactează într-un meniu de tip dropdown.

Figura 3.13 – Interfață pagină administrator

În centrul paginii, sub forma unor mici animații sunt reluate link-uri de redirecționare către paginile importante ale gestunii aplicației.

Figura 3.14 – Pagină administrator animații

Aceste pătrate, în momentul în care administratrul se află cu mouse-ul pe ele se rotesc și își schimbă culoarea. Pentru implementarea acestora am folosit doar clase proprii, principală fiind clasa „meniu_animat”:

.meniu_animat {

width: 100%; //lățime

height: 100%; // înălțime

text-align:center; //aliniere text

transform-style: preserve-2d; // modul de deplasare

transition: all 0.5s linear; // timpul dintre tranziții

}

.meniu_animat:hover { // proprietățile clasei în momentul în care te afli cu mouse-ul

transform: rotateY(180deg); // rotire cu 180 garde pe axa Y

background-color: #0033FF; // culoare fundal

color: white; // culoare scris

text-align: center; //aliniere text

-webkit-transform: rotate(-180deg);//asigurare rotire în broserul Google Chrome

-moz-transform: rotate(-180deg); // asigurare rotire în broserul Mozzila

}

Principala proprietate responsabilă cu rotirea pătratelor este transform: rotateY(180deg);. Aceasta face o rotire de 180 de grade față de axa Y în spatiul sd, după cum am specificat proprietății „transform-style”. Tranziția pătratelor este liniară și începe dupa 0.5 secunde. Celelalte proprietăți sunt uzuale, referitoare la lățime, înălțime, culoare, scris.

În partea de sus a paginii, administratorul este întâmpinat cu un mesaj de bun venit și înștiințat dacă are mesaje necitite de la utilizatorii aplicației. Acestea se gasesc pe o bandă portocalie, de tipul unei alerte warning, folosind pentru creare chiar clasa de boostrap „alert-warning”, căreia i-am asociat noi elemente de stil. Pentru a apărea numărul mesajelor necitite am creat funția „ ready” utilizând tehnologia AJAX. Scriptul este introdus în secțiunea <body> și nu în <head> deoarece nu se execută la încârcarea paginii ci reprezintă un apel de funcție.

<script type="text/javascript">

$(document).ready(function () {

var x = '@User.Identity.Name';

if (x) {

$.ajax({

url: '@Url.Action("Numbers","Administrator")',

type: "GET",

success: function (result) {

var x = result;

if (x != 1) {

var y = "Aveti " + x + " mesaje noi."

}

if (x == 1) {

var y = "Aveti " + x + " mesaj nou."

}

if (x != 0) {

$("#newmessage").html(y);

$("#message").html(x);

}

}

});

}

});

</script>

Funcția „ready” face un apel de tip GET către server și primește rezultatele sub forma unui JSON. În funcția creată, în variabila „x”, preiau valoarea câmpului cu id-ul nume, apoi apelez funcția AJAX din jQuery. Această funcție primește un set de parametrii: type, url, succes.

Parametrul „type” preia valoarea „GET”, ce reprezintă metoda cu care se face apelul clientului la server. Am folosit metodă de tip „GET” deoarece doresc ca informația transmisă de la utilizator să fie încărcată într-un url, iar informațiile dorite se extrag din baza de date. Parametrul „url” preia adresa resursei către care se trimite informația, iar parametrul „succes” preia o funcție ce se va apela în momentul încheierii cu succes al apelului. Parametrul „result” al acestei funcții reprezintă răspunsul dat de server. Variabila reprezintă un string prin intermediul căruia afișez un mesaj administraorului. Ultimul „if” din funcție afișează numărul mesajelor necitite pe bara portocalie, căreia i-am atribuit id-ul „newmessage” și în tab-ul „Mesaje” cu id-ul „message”.

<li><a href="@Url.Action("ViewMessages","Administrator")">Mesaje<span class="badge" id="message"></span> </a></li>

Dacă dorește să citească mesajele va accesa tab-ul „Mesaje” din dashboard sau de pe pătratul animatie de unde va fi redirecționat către pagina acestora.

Pagină mesaje

Scopul acestei pagini este de a ușura munca administratorului în gestionarea mesajelor primite. Astfel am creat un tabel ce cuprinde opt coloane:

primele patru coloane conțin informații despre expeditor ( nume, e-mail, telefon și numele organizației dacă este cazul)

a cincea coloană conține data și ora la care a fost primit mesajul

a șasea coloană conține un buton pentru a deschide mesajul primit

a șaptea coloană informează administratorul despre statusul mesajului (citit/necitit)

ultima coloană conține butonul de ștergere

Figura 3.15 – Interfață pagina mesaje

După cum am menționat mai sus, primele patru coloane conțin date despre expeditor. Primele două, cea pentru nume și e-mail , trebuie să fie populate obligatoriu, datorită proprietății „required” pe care o au câmpurile de nume și e-mail din secțiunea „Contact”. Datele despre expeditor sunt introduse în mod dinamic printr-o sintaxă razor de tipul @item.Name pentru coloana ce conține numele. Coloanele ce conțin numele organizației/companiei și numărul de telefon sunt populate conform unei instrucțiuni condiționale:

@if (item.Organization == null)

{

<td>-</td>

}

else

{

<td>@item.Organization</td>

}

Astfel dacă expeditorul nu a completat aceste câmpuri, va apărea semnul „-”, iar dacă au fost completate se va prelua informația introdusă.

Pentru a citi mesajul, administratorul trebuie să dea click pe butonul „Deschide” și i se va deschide un modal ca în figura 3.14.

Figura 3.16 – Modal citire mesaj

Acest modal se deschide prin apelarea funcților jQuery

function showModal(message) {

$('#messagesArea').html(message);

$('#extend').modal('show');

}

function updateMessage(id) {

$.post("@Url.Action("UpdateMessage", "Administrator")", { id: id }, function () {

});

}

prin metoda onclick="showModal('@item.Message');updateMessage(@item.Id)" atașată coloanei.

Prima funție deschide modalul în care este afișat mesajul și va înlocui conținutul acestuia introdus de mine inițial, cu mesajul trimis de utilizatorul expeditor. Funcția „updateMessage” face un apel de tip POST către metoda „UpdateMessage” din controller-ul „Administrator”, preia id-ul aferent mesajului selectat, apoi se va reîncarca pagina, cu statusul mesajului schimbat.

Statusul mesajului este afișat printr-o imagine semnificativă. Cele două imagini se schimbă datorită unei sintaxe de razor pe care am creat-o:

@if (item.Status == 1)

{

<td><span class="ckeck_middle">

<img src="~/Images/site/check-icon.png" /></span></td>

}

else

{

<td><span class="ckeck_middle">

<img src="~/Images/site/close-icon.png" /></span></td>

}

Sintaxei de mai sus reprezintă o instrucțiune conditională simplă ce testează dacă statusul mesajului este „1”. Dacă este îndeplinită condiția (statusul este 1) va apărea imaginea specifică mesajului vizualizat, în caz contrar imginea specifică mesajului nevizualizat.

Pentru a afla mai ușor numărul mesajelor necitite, fără a număra în tabel pe cele cu status de necitit, în dashboard, ca și în prima pagină a acestei secțiuni este afișat numărul acestora.

Funcția care are rolul de a număra și afișa mesajele necitite are aceeași structură cu cea din prima pagină a administratorului ( apel de tip GET către server și primește rezultatul sub forma un ui JSON), diferența constând în eliminarea primelor două if-uri din funcția dată parametrului „success”. Am eliminat aceste if-uri deoarece nu am nevoie să-mi afișeze sub forma unui mesaj numărul acestora și nici afișarea valorii „0”.

$(document).ready(function () {

var x = '@User.Identity.Name';

if (x) {

$.ajax({

url: '@Url.Action("Numbers", "Administrator")',

type: "GET",

success: function (result) {

var x = result;

if (x != 0) {

$("#message").html(x);

}

}

});

}

});

Pentru a șterge un mesaj, administratorul dă click pe butonul „Sterge”, iar pentru finalizarea acțiunii va trebui să confirme în pop-ul ce se deschide.

Figura 3.17 – Pop-up confirmare ștergere mesaj

Butonul „Sterge” prezintă o metodă de tipul onclick="deleteMessage(@item.Id)" ce apelează funcția „deleteMessage”. Această funcție are ca parametru variabila „id”, în care este înregistrat id-ul mesajului asupra căruia se execută acțiunea. În primă fază se cere o confirmare a finalizării acțiunii de ștergere, apoi se face un apel de tip POST către controller-ul „Administrator” în care este creată acțiunea de ștergere. După ștergerea mesajului selectat, se va reîncărca pagina de mesaje cu schimbările efectuate.

function deleteMessage(id) {

if (confirm('Are you sure you want to delete the message?')) {

$.post("@Url.Action("DeleteMessage","Administrator")", { id: id }, function () {

location.reload();

});

}

}

3.2.3 Pagină management utilizatori

Pagina „Management Utilizatori” poate fi accesată din dashboard sau dând click pe animația aferentă. Din această pagină administratorul listeză utilizatorii înregistrați, acordă perminisiuni (administrator, supervizor) anumitor utilizatori, sau să-i șteargă. Astfel administratorul poate alege cine și în ce mod utilizează aplicația.

Design-ul are aceeași structură cu celelalte pagini din secțiunea dedicată administratorului, toate informațiile despre un utilizator și toate acțiunile asupra acestuia făcându-se dintr-un tabel ce conține toate instrumentele necesare.

Un utilizator nou înregistrat are setată implicit ca permisiune „user” ( poate doar să vizualizeze aplicația, fară a putea face modificări ). Dacă administratorul dorește ca acesta să aibă mai multe drepturi în ce privește utilizarea aplicației, îi poate modifica permisiunea în „supervizor” ( citește mesaje, adaugă/șterge/ editează monumente), sau să-i acorde drepturi depline (administrator) prin apăsarea butonului „Modifică”. După ce dă click pe acest buton se va deschide un modal în care este un dropdown din care selecteză permisiunea dorită și butonul „Submit” prin care finalizează acțiunea. Deoarece din acest modal se fac modificări asupra aplicației, modalul este inclus într-un form ce trimite informații către "@Url.Action("UpdateUserRole", "Administrator") printr-o metodă de tip „POST”.

Pentru crearea dropdown-ului am optat pentru un meniu încadrat între tag-urile <select> și </select>, iar elementele listei sunt opțiuni ale tag-ului. Fiecare opțiune are o valoare specifică.

<select name=" newrole " class="permisiune">

<option value="utiliz" selected>user</option>

<option value="superviz">supervizor</option>

<option value="admin">administrator</option>

</select>

Prima opțiune are și proprietatea „select” deoarece aceasta se setează implicit. Clasa „permisiune” este creată pentru a seta dimenisunile dropdown-ului.

Figura 3.18 – Interfață pagină management utilizatori

Pagini editat obiective

Pentru a putea edita obiectivele deja existente în aplicație sau pentru a adăuga unele noi, administratorul are la dispoziție două pagini: pagina pentru editat/șterge obiecive și pagina pentru adăugare.

În continuare o să prezint pagina pentru adăugare obiective. Aceasta are un conținut simplu, alcătuită din cinci câmpuri pentru introducerea datelor ( nume, adresă, coordonate, descriere) și un buton prin care se încheie acțiunea de adăugare.

Câmpurile sunt de tip input , având fiecare o etichetă ce oferă informații despre ce conținut treuie introdus în input-uri. Astfel pentru construirea fiecărui câmp am utilizat o pereche formată din etichetă și input ca în exemplu:

<div class="row">

<label class="margine_stanga titlu_label">Denumire:</label>

<input class="label-dim" name="Name"/>

</div>

Clasele „margine_stanga” și „titlu_label” sunt create pentru o bună încadrare în pagină și pentru stilizarea scrisului.

.margine_stanga {

margin-left:320px;

}

.titlu_label {

font-size:20px;

font-style:normal;

font-family: -webkit-pictograph;

}

Aceste clase sunt folosite pentru toate etichetele. Clasa „label-dim” impune dimensiunile câmpului în care se introduc informații. Toate aceste clase sunt editate pentru diferite tipuri de rezoluții folosind @media. Pentru câmpul alocat descrierii am folosit tag-ul <textarea>, pentru a permite introducerea unui număr de caractere mai mare.

Fiecare pereche, etichetă și câmpul pentru introducerea datelor, sunt cuprinse între div-uri, pentru a putea fi separate unele de altele. De asemenea clasa „row” atribuie câte un rând fiecărei perechi.

Figura 3.19 – Interfață pagină Adaugă obiectiv

Toate câmpurile, ce alcătuiesc conținutul paginii, sunt incluse într-un form, deoarece doresc ca datele introduse, să fie adăugate în baza de date după apăsarea butonului „Adaugă”, setat ca tip „submit”.

În pagina Editare obiective, se pot face modificări asupra acestora, asupra fișelor, sau ștergere în cazul în care nu mai este inclus în programul de restaurare. Toate aceste acțiuni sunt gestionate dintr-un tabel, ca cel din figura 3.18.

Figura 3.20 – Interfață pagina Editare obiective

În cazul în care se dorește o modificare asupra unei informații despre un obiectiv existent, se va apăsa butonul „Editare obiectiv” și se va deschide un modal ce conține un formular ca cel din pagina Adăugare obiectiv. Din punct de vedere am construirii modalului, urmează aceeași structură ca toate celelalte modale, iar câmpurile sunt introduse între div-uri cu perechi de tag-uri <label> și <input>, iar în cazul descrierii tag-ul <textarea>. Pentru editarea dimensiunii câmpurilor de tip input și poziționarea aceestora am creat noi clase, în care aceleași proprietăți ca și cele ale claselor folosite pentru pagina Adaugare obiectiv primesc valori diferite.

Figura 3.21 – Modal editare obiectiv

Modalul destinat editării fișei de gestiune, este structurat în panel-uri, dar pentru a se putea face editare asupra conținutului acestora, informațiile sunt introduse în input-uri.

Figura 3.22 – Modal editare fișă

Modalele pentru editare obiectiv și fișă obiectiv se deschid prin apelarea funcției create pentru deschiderea modalului respectiv, ( pentru editare obiectiv onclick="showModalSiteEdit(@item.SiteId)"),funcție ce primește ca parametru în mod dinamic id-ul respectivului obiectiv.

function showModalSiteEdit(id) {

$('#siteid').val(id);

$('#extend').modal('show');

}

('#siteid').val(id); face trimitere către <input id="siteid" style="display:none" name="Id"/>, din interirul modalului. Acest input care nu este vizibil administratorului datorită proprietății de stil „display” setată ca „none”, conține id-ul obiectivului ce servește ca parametru funcției. Acest lucru se întâmplă și în cazul modalului pentru editare fișă.

În cazul ștergerii unui obiectiv, se va apăsa butonul „Sterge”, se va deschide un pop-up pentru confirmare, apoi se va elimina obiectivul. După eliminarea obiectivului se va face reactulizarea paginii. Aceeste acțiuni sunt date de funcția:

function deleteSite(id) {

if (confirm('Are you sure you want to delete this site?')) {

$.post("@Url.Action("DeleteSite", "Administrator")", { id: id }, function () {

location.reload();

});

}

} ,

ce este urmeză acelaș principiu ca eca pentru ștergerea unui mesaj.

Interfața dedicată utilizatorului de tip supervizor

Această secțiune este destinată utilizatorilor ce au primit permisiune de la administrator pentru a putea săvârși anumite acțiuni asupra aplicației. Scopul acestor utilizatori este de a ajuta administratorul în gestionare aplicației. Supervizorii au aceleași drepturi ca și administratorul, mai puțin managementul utilizatorilor. Avănd aceleași drepturi, am creat o interfață asemănătoare cu a administratrului, urmând aceeași structură: în dreapta dashboard-ul cu instrumente, în restul paginii conținutul specific. Dashboard-ul este preluat din secțiunea destinată administratorului și este editat prin schimbarea adreselor paginilor, care de data aceasta fac trimitere către metodele din controller-ul „Supervizor”, eliminarea tab-ului „Management utilizatori” și schimbarea clasei „selected” în „selected1”, deoarece am dorit ca interfața supervizorului să aibă culoare diferită de cea a administratrului.

Figura 3.23 – Diagramă de funcționare a secțiunii dedicate supervizorului

(creată pe site-ul http://yuml.me/ )

Pagină supervizor

Pagina de supervizor este singura din această secțiune care prezintă mai multe schimbări față de ceaa a administratorului, ci nu din punct de vedere al funcționalității, care a rămas aceeași (s-a schimbat doar controller-ul ), ci din punct de vedere al design-ului.

Figura 3.24 – Interfață Pagină supervizor

O primă schimbare a fost construirea clasei „alert-danger”, pentru modificarea benzii în care se găsește mesajul de bun-venit.

Schimbarea majoră s-a produs în cadrul meniului animat, pe care de această data l-am dorit să fie sub formă de cercuri ce se rotesc față de axa Y(transform: rotateY(180deg);) în spațiul 3d .

.meniu_animat1 {

width: 100%; //lățime

height: 100%; //înălțime

border-radius:50%; //margini rotunjite

text-align:center;//aliniere text

transform-style: preserve-3d; // rotire în spațiu 3d

transition: all 0.5s linear; // timp tranziții

}

Această clasă prezintă aceleași proprietăți ca cea a pătratelor din pagina administratorului, diferența fiind setarea spațiului 3d. Pentru a obține margini rotunjite ale meniului, am folosit proprietatea „border-radius”, care setată la valoarea de „50%”, a dus la construirea unor cercuri.

Pagini administrare aplicație

În acest paragraf sunt incluse trei pagini: Pagină mesaje, pagină Adăugare obiectiv și pagină Editare obiective. Aceste pagini au aceleși design și funcționalitate ca cele din secțiunea dedicată administratorului, rolul supervizorului fiind acela de a ajuta administratorul la gestionarea aplicației.

Concluzii și direcții viitoare

Această aplicație își atinge scopul de a oferi funcționalitățile de bază ale unui sistem de gestiune arheologică. După cum am specificat și în introducerea lucrării, rolul meu este acela de a crea interfața web, adică acea parte a aplicației dedicată clienților, utilizatorilor. De aceea am conceput un design ușor și prietenos utilizatorilor (user-frendly ), ce poate fi vizualizat de pe orice tip de dispozitiv.

Drumul parcurs pentru dezvoltarea acestei aplicații nu l-am parcurs singură, ci împreună cu colegul meu de echipă care a creat partea de back-end a plicației, adică metodele pe care eu le-am apelat pentru ca interfața să fie dinamică ( pentru a putea fi o aplicație web). Lucrul în echipă s-a dovedit destul de util, deoarece împreună am planificat, în funcție de scopul aplicației, modul în care aceasta va funcționa, am discutat despre problemele care au apărut pe parcurs, găsind astfel o soluție bună pentru ambele părți (back-end și front-end). Având în vedere aceste aspecte consider că a fost un drum util, din care am învățat lucruri noi ( în special am înțeles legătura dintre back-end și front-end pentru a putea extrage datele necesare părții de client ), am învățat să lucrez într-o echipă și să reuțim să rezolvăm problemele apărute ca o echipă. Astfel, respectându-ne atribuțiile am reușit să creăm o aplicație complexă și unitară, ceea ce reprezintă și cel mai important aspect al acestei lucrări.

În lucrarea de față am oferit informații teoretice despre alegerile făcute pentru dezvoltarea interfeței, am detaliat fucționalitatea acesteia, dar și modul în care a fost implementat desig-ul. Aplicația se poate adapta destul de ușor unor posibile schimbări ulterioare, deși în momentul de față paginile în care se pot face schimbări sunt create ca template-uri cu informații ce sunt preluate în mod dinamic, pentru a nu fi necesară o formatare HTML a codului aplicației, ci doar pe partea de server.

Aplicația RM360 poate fi extinsă și pentru noi funcționalități cum ar fi:

dezvoltarea unei secțiuni destinate obiectivelor naturale din zonă

introducerea unor hărți georeferențiate pentru o mai bună localizare a obiectivelor

introducerea unei secțiuni privind starea de conservare și prioritățile de intervenție în situațiile de degradare a obiectivelor și implementarea tuturor paginilor rămase.

Consider că aplicația în formatul actual, este utilă pentru gestionarea siturilor arheologice, ce reprezintă scopul principal al acesteia, implementările viitoare menționate constituind un plus.

Bibliografie

[1] HTML, XHTML, AND CSS BIBLE, Fifth Edition , Steven M. Schafer, capitolul 3

[2] http://www.w3schools.com/

[3] https://programatinromania.wordpress.com/tag/microsoft-visual-studio/ accesat la data de 29.07.2015

[4] https://ro.wikipedia.org/wiki/Cascading_Style_Sheets accesat la data de 29.07.2015

[5] http://dana-damoc.eu/blog/introducere-la-bootstrap-3/ accesat la data de 29.07.2015

[6] https://ro.wikipedia.org/wiki/JavaScript accesat la data de 30.07.2015

[7] https://en.wikipedia.org/wiki/JQuery accesat la data de 30.07.2015

[8] https://ro.wikipedia.org/wiki/JSON accesat la data de 30.07.2015

[9] https://ro.wikipedia.org/wiki/Adobe_Photoshop accesat la data de 03.08.2015

[10] https://en.wikipedia.org/wiki/Google_Maps accesat la data de 03.08.2015

[11] http://www.scribd.com/doc/17108948/SISTEME-INFORMA%C5%A2IONALE-DE-GESTIUNE-licenta , cartea Sisteme Informaționale de Gestiune accesat la data de 04.08.2015, capitolul 4

[12] https://developers.google.com/maps/documentation/javascript/tutorial accesat la date de 3.09.2015