dissabte, 26 de setembre del 2009

Tercer problema: codi sense estructura

Una cosa que considerava, no un problema solament sinó que poc elegant, era el fet que, quan interactuava amb la base de dades, no disposava de cap estructura de dades robusta per treballar amb els valors recuperats o a escriure en ella. Normalment aquestos valors vagaven lliurement pel codi, cadascun en una variable o en una estructura senzilla com un array i eren globals a tota l'aplicació, de manera que es podia accedir a ells i modificar-los fàcilment des de qualsevol part del codi.

Calia buscar una manera més organitzada i eficient d'usar la base de dades i les dades que anaven a guardar-se o recuperar-se d'ella. Mentre investigava sobre el tema per trobar una bona solució van aparéixer alguns conceptes nous, o altres que ja em sonaven de quan vaig conéixer Ruby on Rails, com Mapeig objecte-relacional (o Object Relational Mapping o ORM), que és una tècnica de programació per convertir dades entre una base de dades relacional i un llenguatge de programació orientat a objectes; persistència, que és l'acció de conservar la informació d'un objecte de forma permanent de tal forma que més tard es puga recuperar per poder ser usada de nou; i Abstracció de Bases de Dades (o Database Abstraction Layer o DAL), que és una interfície que unifica la comunicació entre l'aplicació i la base de dades.

Per posar en pràctica tots aquestos conceptes calia abandonar la manera tradicional d'usar PHP i passar-se a la programació orientada a objectes i usar un patró de disseny anomenat ActiveRecord.

continuarà...

dimecres, 16 de setembre del 2009

Exemple de layout

Per si no va quedar massa clara al post anterior l'explicació sobre que és un layout, ací va un exemple:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"...>
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Títol</title>
    <meta http-equiv="Content-Type" content="text/html; ... />
    <link href="./css/estil.css" rel="stylesheet" type="text/css" />
  </head>

  <body>
    <div id="container">
      <div id="header">
        <div id="banner"><?php ?><div>
        <div id="menu_superior"><?php ... ?></div>
      </div>
      
      <div id="contents">
        <div id="esquerra"><?php ... ?>/div>
        
        <div id="central">
          <div id="breadcrumbs"><?php ... ?></div>
          <div id="noticiari"><?php ... ?></div>
        </div>

        <div id="dreta"><?php ... ?></div>
      </div>

      <div id="footer"><?php ... ?></div>
    </div>
  </body>
</html>

Com es pot veure, en aquest senzill layout es defineix l'estructura de la pàgina; en aquest cas una capçalera amb un banner i un menú superior, la secció dels continguts amb una columna a cada lateral i una central amb lloc per als breadcrumbs i altre lloc per al contingut principal, a més d'un peu de pàgina; i es deixa a PHP que siga l'encarregat de plenar cada secció amb els continguts dinàmics usant les vistes del patró MVC.

continuarà...

diumenge, 13 de setembre del 2009

Segon problema: repetició de codi

Hi havia fragments de codi que es repetien constantment. Per exemple, en PHP el codi necessari per establir una connexió amb la base de dades podria ser aquest:

<?php

$link 
mysql_connect("localhost","root","");
mysql_select_db("basquet",$link);

?>

Cada vegada que volguérem connectar amb la base de dades per recuperar qualsevol informació deuríem incloure el fragment de dalt abans de la consulta. Fer-ho així dificultaria el manteniment de l'aplicació si decidírem realitzar algun canvi que afectara a la forma de connectar amb la base de dades ja que deuríem buscar cada aparició d'aquest fragment de codi al llarg de tota l'aplicació per aplicar les modificacions corresponents.

Si tenim en compte la filosofia DRY, que ve a dir, més o menys, que cap part del codi font d'una aplicació mai deuria estar repetida, una solució senzilla a aquest problema consistiria en escriure el codi anterior a un fitxer anomenat, per exemple, connexioBD.php i usar-lo amb la funció include() cada vegada que volguérem consultar la base de dades. D'aquesta manera si necessitàrem realitzar modificacions sobre aquest codi només hauríem de fer canvis en aquest fitxer i no a tota l'aplicació.

Qualsevol altra situació similar en la que existisca codi PHP repetit al llarg de l'aplicació es deuria resoldre seguint el mateix esquema: aïllar el codi en un fitxer i substituir-lo per una crida a la funció include().

En quant al codi HTML, podem distingir dins d'un document d'aquest tipus parts que no varien al llarg de l'aplicació, com poden ser la declaració del DOCTYPE o l'estructura del contingut del document; i parts que sí ho fan, com per exemple les etiquetes <meta>, <title> o <link> i les famoses vistes del patró MVC, que són on estarà la informació relevant per a l'usuari.

Ací apareix el que s'anomena layout, que no és més que un document HTML on es defineixen les parts que no canvien i l'estructura del contingut del document (per exemple, dos columnes amb menú superior o tres columnes amb menú superior i lateral). A més, s'inclou una mica de codi PHP, només el necessari, per tal de col·locar les vistes del patró MVC als llocs correctes.

D'aquesta manera, només cal especificar quin layout s'usarà a l'aplicació web i aquesta s'encarregarà de que dins del layout es col·loquen les vistes necessàries. Així no cal tindre decenes de pàgines HTML amb el mateix layout en totes i cadascuna d'elles ja que podrem usar el mateix cada vegada que siga necessari. Una vegada fet açò, enviarà el layout junt amb totes les vistes necessàries al navegador.

continuarà...

divendres, 4 de setembre del 2009

Primer problema: mescla de codi

Per reanudar les meues aventures amb PHP vaig decidir intentar fer una aplicació web que permetera gestionar campionats de bàsquet. L'aplicació deuria permetre a un administrador crear una competició, inscriure els equips i els seus jugadors, realitzar els sortejos dels partits i introduir els resultats i les seues estadístiques; a la resta de gent deuria permetre visualitzar els resultats i les diferents classificacions.

Em plenava de satisfacció veure com l'aplicació creixia a poc a poc i que tot el que tenia en ment ho podia plasmar en codi però, per altra part, cada vegada resultava més complicat afegir noves funcionalitats o característiques. Hi havia una sèrie de situacions que vaig adonar-me que calia evitar si volia ser capaç de crear aplicacions web d'una manera senzilla i ràpida.

Un dels principals obstacles que m'impedia avançar a un ritme decent era la mescla de codi, també coneguda com codi spaghetti, que es produïa. En només unes poques línies podien barrejar-se fins quatre llenguatges de programació diferents. Per exemple, en aquest simple fragment de codi...

<?php

$link 
mysql_connect("localhost","root","");
mysql_select_db("basquet",$link);
$result mysql_query("select * from categoria order by nom",$link);

echo 
"<table width = '20%' border = '0'>";

while (
$categoria mysql_fetch_array($result)){
  echo 
"<tr>";
  echo 
"  <td width = '15%' bgcolor = '#cccccc'>".$categoria["nom"];
  echo 
"  </td>";
  echo 
"</tr>";
}

mysql_free_result($result);
mysql_close($link);

echo 
"</table>";

?>

...es pot observar que hi ha PHP, SQL, HTML i CSS, aquestos dos últims incrustats dins del document final a base d'usar reiteradament la instrucció echo, cosa que no em convencia massa. A més, si es volguera fer ús de JavaScript, tenint en compte com han estat incrustats l'HTML i el CSS, és lògic pensar que es faria de la mateixa manera, amb echo. Per tant, serien cinc els llenguatges que hi hauria barrejats.

Aquesta barreja dificulta el manteniment en gran mesura, ja que, quan més codi hi ha, més difícil resulta identificar el llenguatge amb el que es vol treballar. A més, si a mi, que treballe a soles, em resulta complicat fer-ho en aquestes circumstàncies, imagineu un equip de desenvolupadors on cadascun d'ells fóra responsable d'un llenguatge diferent. Si el codi que generaren fóra en un estil similar al de més amunt, amb tots els llenguatges barrejats, el desenvolupament d'una aplicació web pense que seria impossible. Necessitarien treballar sobre el mateix fitxer diverses persones, per exemple, un d'ells per insertar codi HTML, un altre per insertar codi PHP i, pot ser, un altre per al JavaScript; sense que cadascun d'ells haja d'entendre el codi que ha escrit un dels altres o, pitjor encara, permetent la possibilitat de que algú puga eliminar-lo o modificar-lo.

La solució més extesa a aquest problema passa pel que s'anomena Model Vista Controlador o MVC.

MVC és un patró de disseny que separa les dades d'una aplicació, la interfície d'usuari i la lògica de control en tres components distints. A una aplicació web, el model és el sistema gestor de bases de dades; les vistes són els fitxer HTML, on es descriuen els documents que han de mostrar-se al navegador (aquestos documents poden tindre PHP al cas que s'usen estructures de control com bucles, per exemple, per escriure dades a les fileres d'una taula), i el fitxer CSS, usats per donar format als documents HTML; i el controlador el responsable de processar la interacció de l'usuari, obtindre les dades dels models, processar-les i tornar l'eixida a la vista per mostrar-la al navegador.

Doncs ja tenim identificat un dels problemes típics en el desenvolupament d'aplicacions web i una possible solució que implementaré més endavant.

continuarà...

diumenge, 28 de juny del 2009

Els meus inicis a la web

Ja fa uns anys, quan vaig interessar-me per la creació de pàgines web, aquestes eren totalment estàtiques. És a dir, tota aquella informació que devia mostrar-se a l'usuari no estava en cap base de dades ni res semblant d'on obtindre-la sinó que devia estar explícitament al document que es mostrava pel navegador. Per tant, cada vegada que es volia actualitzar una pàgina web es devia editar el codi que contenia per realitzar les modificacions corresponents.

Aquest codi solia ser una barreja de tres llenguatges: HTML per descriure l'estructura de la informació al document a mostrar pel navegador, CSS per descriure la presentació de l'HTML i, en alguns casos, javascript per dotar la pàgina web de cert dinamisme una vegada carregada al navegador.

La primera pàgina web que vaig fer fou una que estava dins d'un CD on hi havia una recopilació discogràfica en format MP3 i permetia navegar pels discos, veure les lletres de les cançons i reproduir-les. Era completament estàtica, només funcionava amb el contingut d'aquest CD en concret i no podia ser aprofitada per a un altre diferent sense haver de modificar el codi font.

Després vaig col·laborar en les pàgines web que féiem els companys de la universitat. Inclús vaig crear la meua personal, no oferia res extraordinari, alguna noticia del que passava al meu entorn i algunes descàrregues de programes que algun amic o jo havíem fet, però m'aprofitava per practicar. Per actualitzar-la, com he explicat abans, calia modificar el codi font, la qual cosa era tediosa. Imagineu el que passaria cada vegada que, per exemple en una pàgina web de notícies, es volguera afegir una nova...

Va ser en aquest instant quan, sense adonar-me, em vaig començar a preocupar pel dinamisme a les pàgines web, volia saber com fer que el contingut d'una es poguera modificar sense haver d'editar el codi font. "No hi ha cap manera de fer que les notícies es publiquen a través d'un formulari o alguna cosa pareguda sense haver de modificar el codi font?" vaig preguntar al JailWebmaster. "Sí, hi ha llenguatges que permeten recuperar dades d'una base de dades i mostrar-les a les pàgines web, com per exemple PHP, però necessites tindre un servidor instal·lat per poder usar-lo." fou la seua resposta.

En aquells moments no em veia capaç d'instal·lar un servidor de PHP i la resta de programes necessaris (encara que després vaig descobrir que és realment senzill) però vaig descobrir uns programes que ho feien per tu automàticament. Aquestos instal·laven el servidor HTTP Apache per transferir pàgines web al client, l'intèrpret del llenguatge PHP i el servidor de bases de dades MySQL.

Usar PHP era d'allò més senzill. En un fitxer amb extensió php s'escrivia el codi en llenguatge HTML i, quan es necessitava informació de la base de dades o bé dinàmica (per exemple, l'hora actual), es ficava codi en llenguatge PHP. D'aquesta manera es podia construir qualsevol portal o aplicació web, només caldria tindre en compte el disseny de la base de dades, quantes pàgines devia tindre el portal i quina informació devia anar a cadascuna d'elles.

Practicar amb aquesta tecnologia m'agradava tant fins el punt que vaig començar a freqüentar alguns fòrums i altres pàgines web dedicades a ensenyar PHP i altres llenguatges de programació a la gent. Una de les vegades que vaig visitar un d'aquestos fòrums per buscar solució a un dels problemes que em podien haver sorgit intentant programar alguna coseta, vaig adonar-me que en una gran quantitat de posts s'anomenava una cosa que es deia Ruby on Rails. Vaig decidir buscar més informació sobre açò, potser descobrira coses noves. Vaig estar llegint al lloc web oficial i, com semblava interessant, el vaig descarregar per provar-lo.

Això de Ruby on Rails semblava estar bé, ja que en teoria permetia el desenvolupament d'aplicacions web d'una manera senzilla i sense haver d'escriure apenes. Però em donava la sensació que això era massa per a mi, els conceptes que introduïa, tals com MVC, ORM o Patrons de Disseny, em resultaven totalment desconeguts i em donava la sensació que passaria més temps aprenent nous conceptes que ficant-los en pràctica. També pensava que mai assoliria els coneixements de programació dels gurus que rondaven aquells fòrums i webs sobre llenguatges de programació. Així que vaig continuar trastejant amb PHP a la meua manera per veure fins on podia arribar.

continuarà...

dissabte, 20 de juny del 2009

El propòsit d'aquest bloc

Aquest bloc pretén ser un quadern de bitàcola de la construcció d'un framework per crear aplicacions web amb PHP i algun sistema gestor de bases de dades que li vaja bé, en un principi MySQL.

Però... per què perdre el temps creant una cosa que ja està inventada i de la qual existeixen una gran quantitat de productes similars?

Doncs és molt senzill, simplement per aprendre com funciona un d'aquestos frameworks i, sense pretendre millorar cap dels ja existents, construir un que s'ajuste a les meues necessitats.

Però... per què no aprendre com funciona un dels ja existents en compte de construir un de nou?

Doncs també és molt senzill, per que la documentació interna de la majoria dels frameworks que hi ha és escassa o inexistent; només existeix documentació per a l'usuari final, i jo vull saber com funciona cada línia de codi d'aquestes coses. A més, per que construir un producte de certa complexitat em pot fer adquirir certes habilitats a l'hora de dissenyar qualsevol altre sistema informàtic.

Un dels altres propòsits d'aquest bloc és forçar-me, per dir-ho d'alguna manera, a desenvolupar alguna característica del framework amb certa freqüència i no deixar-lo en l'oblit, que és el que m'ha passat altres vegades que he intentat construir-lo.

Al proper post explicaré els principals problemes que em sorgien quan volia fer alguna pàgina web i que em van fer adonar-me de que realment necessitava enfocar el desenvolupament d'aquestes des d'un altre punt de vista.

continuarà...