Relativ de curând am scris despre folosirea librăriei Leaflet ca alternativă la Google Maps API, iar unul din task-urile pe care le-am avut de îndeplinit între timp a fost integrarea acestei librării cu Ext JS. Cu alte cuvinte, a fost necesară scrierea unei componente Ext JS care să permită desenarea unei hărți cu ajutorul API-ului oferit de Leaflet.

Implementarea soluției

Soluția mea se bazează pe extinderea clasei Ext.Component, întrucât aceasta este cea mai simplă clasă care poate fi extinsă oferindu-mi în același timp funcționalitatea necesară (totodată, este și clasa de bază pentru componentele scrise în Ext JS, fie standard, fie custom). În plus, am optat pentru extindere și nu compoziție, pentru a putea profita de management-ul automatizat al ciclului de viață al componentelor, oferit de Ext Js. Pornind de la aceste observații, codul inițial arată după cum urmează:

Ext.define('LVD.panel.LeafletMapPanel', {
	extend: 'Ext.panel.Panel',
	alias: 'widget.leafletMapPanel'
}

Apoi, pentru a putea desena harta, trebuie să implementăm metodele prezentate în continuare, fiecare dintre acestea corespunzând unei etape din ciclul de viață al unei componente.

Mai mult…

Atunci când avem de-a face cu obiecte imutabile, ori cu proprietăți care nu pot fi decât citite, avem nevoie, în mod normal, de un builder pentru a putea construi și hidrata obiectul (spre exemplu, atunci când îl refacem dintr-o bază de date).

Acest tipar de lucru este dificil de susținut deoarece:

- este nevoie de câte un builder pentru fiecare astfel de obiect;

- de fiecare dată când operăm modificări structurale asupra obiectului, trebuie modificat și builder-ul corespunzător.

Avem totuși o alternativă, și anume folosirea API-ului furnizat de System.Reflection pentru a construi o soluție universală. Abordarea sugerată se bazează pe refacerea stării prin accesul direct al câmpurilor (atât a celor care stau în spatele proprietăților, cât și a celor care nu deservesc direct nicio proprietate, deși rareori va fi nevoie de accesarea acestora din urmă).

Mai mult…

Relativ de curând, Google a impus o limită asupra numărului de accesări care pot fi făcute folosind API-ul lor de hărți. Deși acest lucru poate sau nu să pună probleme site-urilor care îl utilizează, în funcție de traficul lor, nu evenimentul în sine este neapărat important, ci faptul că, dacă au făcut acum o mutare de acest gen, pot, și o vor face, și în viitor, fiind astfel necesară existența unei alternative. Una din aceste alternative este Leaflet JS, o librărie JavaScript open-source pentru prezentarea și manipularea hărților digitale, dezvoltată de CloudMade.

Și cum codul sursă vorbește de la sine, în continuare voi prezenta câteva exemple de utilizare ale acestei librării.

Crearea și inițializarea hărții

Pasul 1. Mai întâi includeți fișierele necesare

<link rel="stylesheet" href="leaflet/leaflet.css" />
<!--[if lte IE 8]>
	<link rel="stylesheet" href="leaflet/leaflet.ie.css" />
<![endif]-->
<script src="leaflet/leaflet.js"></script>

Pasul 2. Creați div-ul care va conține harta. În exemplul meu, arată cam așa:

<div id="map-container" style="width: 600px; height: 300px;"></div>

Mai mult…

Sursa: W3C

Ce m-a îndemnat să scriu acest articol au fost sesizările primite de către unul dintre clienții noștri, conform cărora utilizatorii aplicațiilor web dezvoltate pentru ei nu le puteau folosi accesându-le prin intermediul conexiunilor de internet mobil (cel pentru laptop și PC). Observațiile primite nu erau legate doar de un operator anume, ci de toți trei prezenți în România – Orange, Vodafone și Cosmote.

Ce se întâmpla de fapt

Odată investigată situația, problema s-a dovedit în realitate ceva mai gravă decât era raportată de către utilizatori. Pe scurt, iată ce am descoperit:

- imaginile erau servite la o calitate inferioară celei originale, datorită compresiei agresive aplicate de către ISP, de până la 50% din dimensiunea originală;

- fișierele JavaScript erau modificate de către ISP, eliminându-se comentariile și nu numai, probabil cu scopul de a micșora traficul generat de descărcarea acestora și de a optimiza încărcarea, însă această transformare era prost implementată, funcționarea scripturilor fiind grav afectată (spre exemplu, apăreau erori la rularea acestora în browser);

- conținutul HTML al paginii era modificat de către ISP (spre exemplu comentariile și newline-urile erau eliminate, însă uneori link-urile către resursele JavaScript erau compromise din cauza unor modificări greșite);

Mai mult…

Dintre noutățile aduse de iOS SDK5.0, una care mi-a atras în mod deosebit atenția este prezența noii clase UIPageViewController, care permite crearea unei cărți digitale simulând experiența oferită de o carte reală.

UIPageViewController este de fapt un container al cărui rol principal este cel de a gestiona o colecție de view-controllere (care reprezintă paginile cărții digitale), facilitând navigarea între ele.

Opțiuni de afișare

Tranziții

O tranziție reprezintă efectul folosit pentru animarea navigării de la o pagină (adică un view-controller) la alta. Momentan nu este disponibilă decât o singură opțiune – cea care produce un efect asemănător cu cel din iBooks.

Orientarea navigării

Orientarea pe care se face trecerea între “pagini”. Aici există două opțiuni:

- pe orizontală (UIPageViewControllerNavigationOrientation.Horizontal) – trecerea se face de la stânga la dreapta, sau invers;

- pe verticală (UIPageViewControllerNavigationOrientation.Vertical) – trecerea se face de sus în jos, sau invers.

Mai mult…

Substitution API este de fapt un nume mai pompos pentru a descrie funcționalitatea oferită de metoda HttpResponse.WriteSubstitution(callback) care, în loc să scrie un șir de caractere în stream-ul răspunsului, ”scrie” un placeholder (înlocuitor) ce constă din funcția dată ca parametru care, atunci când răspunsul este trimis către client, este executată iar poziția ei în răspuns este înlocuită cu rezultatul execuției. Astfel, acest procedeu răspunde nevoii de actualiza dinamic porțiuni dintr-o pagină (sau dintr-un UserControl – .ascx) cache-uită folosind API-ul de output caching.

Datele problemei

Avem următoarea sarcină de lucru: trebuie să prezentăm o pagină al cărei conținut nu se schimbă foarte des și este același, indiferent de utilizatorul autentificat, fiind astfel un candidat foarte bun pentru output caching. Totuși, există o mică zonă din pagină care poate varia: link-ul de log-in (care apare dacă utilizatorul nu e autentificat), sau de log-out (care apare dacă utilizatorul este autentificat). Problema este că, odată salvat răspunsul în cache, acel link va rămâne același din momentul primei accesări a paginii, indiferent utilizatorul se autentifică sau nu ulterior.

Mai mult…

În ceea ce privește debugging-ul și profiling-ul, PHP oferă un suport standard nesemnificativ, golul fiind umplut însă de o serie de extensii și instrumente precum:

- XDebug – o extensie PHP care oferă facilități precum profiling, code coverage, remote debugging, afișarea stack trace-urilor, afișarea îmbunătățită a rezultatelor produse de var_dump etc.;

- APD – Advanced PHP Debugger – este tot o extensie de PHP care oferă un API pentru debugging;

- DBG – software disponibil atât gratuit, cât și cu plată;

- FirePHP – permite tipărirea mesajelor în consola Firebug, folosind apeluri de funcții executate în scripturile PHP;

- Zend IDE, care vine cu propriul său debugger etc.

Primii pași

Atunci când începem un proiect este bine să avem un mediu de dezvoltare configurat corespunzător, astfel încât să putem fi notificați din timp de eventualele probleme apărute, oricât de nesemnificative ar putea fi. Astfel, când dezvoltăm o aplicație în PHP trebuie să ne asigurăm ca nivelul de raportare a erorilor este cel mai ridicat posibil și că, evident, PHP-ul este configurat să afișeze erorile. Setările necesare ar putea fi făcute dinamic la începutul unui script, după cum urmează:

ini_set('display_errors', 'On');
error_reporting(E_ALL);

Merită menționat faptul că, începând cu PHP5, este disponibilă constanta E_STRICT, care, printre altele, activează emiterea avertizărilor referitoare la metodele deprecated folosite în programul vostru. Astfel, linia 2 ar deveni:

error_reporting(E_ALL | E_STRICT)

Mai mult…

Una din sarcinile pe care le-am avut de îndeplinit recent a presupus, printre altele, și gestiunea unor fișiere aflate pe alte mașini (ex: listarea directoarelor, descărcarea fișierelor necesare, procesarea lor, încărcarea lor pe o altă masină etc.).

Așadar, o soluție bazată pe protocolul SFTP era cea mai indicată, iar singurul proiect open-source pentru platforma .NET pe care l-am putut găsi a fost SSH.NET (SharpSSH nu funcționa corespunzător și nici nu mai este dezvoltat de ceva vreme, iar o soluție platită nu își justifica în nici un fel costurile în cazul de față).

SSH.NET este un proiect complet nou, foarte bine scris care, din câte observ, primește din ce în ce mai multă atenție (paradoxal însă, am dat destul de greu de el). Fiind însă destul de slab documentat (pe undeva e și normal să fie așa, focusul fiind momentan pe dezvoltare) m-am gândit că ar fi bine sa ilustrez într-o serie de două articole modalitatea de utilizare a acestei librării pentru a lucra cu SFTP, respectiv SSH în C#/.NET.

Conectarea

Întâi de toate, trebuie să aflați ce modalități de conectare suportă server-ul la care vă conectați. Odată ce aflați aceste detalii, veți configura o instanță a uneia dintre clasele:

- PrivateKeyConnectionInfo – pentru autentificarea folosind o pereche de chei;

- PasswordConnectionInfo – pentru autentificarea folosind un nume de utilizator și o parolă;

- KeyboardInteractiveConnectionInfo – pentru a folosi modalitatea de autentificare interactivă (care, în particular, poate funcționa asemănător modalității de autentificare cu parolă).

pentru a vă putea autentifica.

Mai mult…

Un subiect interesant pentru orice programator, indiferent de limbajul de programare pe care il folosește, îl reprezintă procesarea documentelor HTML, iar expresiile regulate, deși sunt o abordare destul de întâlnită, nu reprezintă întotdeauna o soluție potrivită.  De multe ori (mai ales atunci când avem nevoie să efectuăm operații complexe sau sensibile, cum ar fi validările) se impune folosirea unui procesor HTML pentru a citi, modifica sau produce un document, unul din aceste procesoare fiind SimpleHtmlDom, despre care am ales să scriu în continuare.

Pentru a nu da acestei expuneri un aer plictisitor de manual școlar, am ales să exemplific conceptele folosind un site aflat în producție, alegând în acest scop www.realitatea.net. Voi extrage din pagina principală a acestui site următoarele elemente:

- titlul paginii HTML;

- toate foile de still incluse;

- toate scripturile externe incluse;

- articolul principal: titlu, fotografie și conținut;

- cele mai noi știri: titlu si link.

Mai mult…

Sau problema lipsei lui MapMoveEnd, ca să fiu mai exact. Mai întâi, însă, permiteți-mi să trasez, în linii mari, contextul acestei probleme. În versiunea 2 a API-ului Google Maps exista un eveniment declanșat de hartă, denumit sugestiv moveend. Acest eveniment semnifica finalizarea modificărilor suferite de suprafața afișată de hartă, modificări produse de oricare din următoarele operații:

- pan de hartă (drag & drop, prin intermediul controlului de pan, sau programatic cu ajutorul metodei GMap2.setCenter);

- zoom de hartă (folosind rotița de la mouse, prin dublu clic, folosind controlul de zoom, sau programatic cu ajutorul metodei GMap2.setZoom).

Nu are rost să menționez cât de util poate fi , și chiar este, un astfel de eveniment. Problema este că acesta a dispărut în versiunea 3, apărând în schimb o serie de alte evenimente:

- center_changed – declanșat de fiecare dată când centrul hărții se schimbă;

- bounds_changed – declanșat atunci când box-ul hărții se schimbă;

- idle – atunci când harta nu mai primește evenimente, după o secvență de pan sau zoom.

Mai mult…