Directoris inicials

Abans de continuar amb tot açò diré que els noms de directoris, fitxers, variables, constants, classes, objectes, mètodes, comentaris i demés coses, seràn en anglés, però només per que així ho preferisc jo.

Com ja vaig dir, desenvoluparé paral·lelament un bloc i el framework. La primera cosa a fer serà crear els corresponents directoris. Com la idea del framework és que puga ser aprofitat com a suport per a diverses aplicacions web a la vegada, separaré les aplicacions i el framework en directoris diferents.

Suposaré que el directori public del servidor web es troba al directori /websites. Crearé doncs, el directori /websites/simplebloc per al bloc. Em sembla que també podria situar el directori simplebloc fora del directori arrel del servidor, però necessitaria crear en aquest un enllaç simbòlic a aquell per a poder accedir al seu contingut. Aquesta possibilitat potser la considere més endavant.

En quant al framework, podria ficar-lo dins del directori public del servidor, en /websites/framework, per exemple, però com no és necessari que estiga ací dins el situaré fora en /framework. No és necessari que el framework estiga dins del directori públic del servidor perque no serà una aplicació web sinó, per dir-ho d'alguna manera, unes llibreries utilitzades per les aplicacions que poden estar a qualsevol punt del sistema de fitxers.

Una cosa que pense que deuria aprendre a fer seria utilitzar hosts virtuals per a les diferents aplicacions web que puga allotjar en un mateix servidor. Però com, de moment, passe de tocar els fitxers de configuració del servidor i, a més, no està directament relacionat amb el funcionament del framework sinó amb el del servidor, ho deixaré per a una altra ocasió.

En definitiva, el que he fet ara ha sigut crear un directori per a cada cosa.

Per a l'aplicació web: /websites/simplebloc

Per al framework: /framework

Al proper post parlaré del punt d'entrada de l'aplicació o FrontController

continuarà...

Ja puc començar amb el codi...

Primer post des d'Irlanda... anem allà...

Una vegada identificades les característiques que ha de tindre el framework, tal i com ho vaig fer als posts anteriors, ja estic en condicions de començar a construir el meu propi. Si estàs interessat tu també pots construir el teu propi paral·lelament amb mi.

L'estructura d'aquest post i dels que vindran a continuació serà de la següent manera, o almenys tinc eixa intenció: a cada nou post tractaré un punt dels llistats al post anterior i intentaré convertir eixes explicacions teòriques en codi font. Si conforme vaig avançant en la construcció del framework em veig en la necessitat d'ampliar o modificar el contingut d'algun d'aquestos posts el que faré no serà escriure un nou post amb les noves modificacions o addicions sinó crear-ne un nou on diré que he afegit o modificat el contingut del post en qüestió i un enllaç al mateix.

Amb aquestes aclaracions prèvies ja puc continuar...

EDIT 29/01/2011

Oops... ara que pense encara no puc continuar... Em falta dir que el codi font que generaré correspondrà a una senzilla aplicació web d'exemple per a així veure que tot funciona correctament. En concret tractaré de crear un simple blog.

continuarà...

Característiques internes dels frameworks

Lamentablement no he tardat mig any en publicar aquest post, com vaig pronosticar a l'anterior, sinó més temps... anem allà...

A l'anterior post vaig fer una llista d'aquelles característiques dels frameworks que es podrien observar des de fora, és a dir, les que aprofitarien per vendre el producte a un usuari que, com jo, s'ha adonat de que realment necessita d'alguna estructura complementària per construir aplicacions web. En aquesta ocasió tractaré d'enumerar aquelles que no són visibles des de l'exterior, en altres paraules, que fa el codi del framework, com està construit per dins, com són les diferents peces que formen part de la maquinària, com és allò que passa desapercebut per a qui veu l'aplicació web al navegador però que fa que tot funcione de manera eficient.

Les característiques de les què parle són aquestes:

• Estructura de directoris ben definida: tots els fitxers de codi font del framework estaran organitzats en directoris, com sembla evident en qualsevol aplicació amb un mínim de complexitat. També sembla evident que els fitxers de qualsevol aplicació web que es construisca amb o sense framework també ho estaran. El que resulta més interessant d'aquest punt és que aquestos fitxers estaran organitzats conforme a una estructura impossada pel propi framework. Així a aquest li resultarà senzill trobar cada cosa al seu lloc sense que el programador haja de preocupar-se de definir els directoris manualment.
• MVC: com ja vaig comentar a un post anterior, el paradigma Model-Vista-Controlador é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 els models els tenim al sistema gestor de bases de dades; les vistes es corresponen amb els fitxers HTML, on es descriuen els documents que han de mostrar-se al navegador, i el fitxers CSS, usats per donar format als documents HTML; i el controlador seria el codi responsable d'acceptar les ordres de l'usuari, obtindre les dades del model, processar-les i tornar l'eixida corresponent a la vista per mostrar-la al navegador.
• URLs amigables o semàntiques front a URLs extenses o tradicionals. Consisteix en que les URLs del lloc web estan formades d'una manera que permeta als buscadors indexar-les correctament i als usuaris recordar fàcilment el seu contingut.
• Router: de la mateixa manera que el router amb què podem tindre connectat(s) el(s) ordinador(s) de casa o la oficina a Internet tradueix els noms de les webs a les què volem navegar en les corresponents adreces IP per fer la búsqueda, aquest router traduirà les URLs del nostre lloc web en els corresponents noms de model, vista i controlador
• ORM: aquesta característica també la vaig comentar a un post anterior, consisteix en una tècnica de programació per convertir dades entre una base de dades relacional i un llenguatge de programació orientat a objectes.
• Autocàrrega de classes: gràcies a la tècnica de l'ORM tindrem que a cada taula de la base de dades que hajam dissenyat per a la nostra aplicació web li correspondrà una classe en PHP. És fàcil pensar que haurem d'afegir la funció include() cada vegada que vullgam treballar amb alguna d'aquestes classes però no, un framework d'aquest estil deu permetre al programador oblidar-se per complet d'aquest detall, i per això comptem amb la funció màgica __autoload().
• DAL: una tècnica també comentada al mateix post que l'ORM, consisteix en una interfície que unifica la comunicació entre l'aplicació i la base de dades i permet al(s) desenvolupador(s) oblidar-se de l'SQL.
• i18n (o internacionalització) i L10n (o localització): consisteixen en els mecanismes necessaris per fer que una aplicació software puga adaptar-se a diversos idiomes o regions sense haver de modificar el codi font ni tornar-lo a compilar.
• Validació de dades: també disposarem d'un mecanisme que, quan treballem amb formularis, permetrà verificar les dades que l'usuari introduisca per assegurar que compleixen certs criteris com, per exemple, que la dada siga un número, o que la data final siga superior a la inicial.
• Codi optimitzat: totes aquestes característiques estaran cuidadosament construides amb patrons de disseny adequats i amb un codi el més optimitzat possible.

Doncs aquestes són les característiques principals que ha de tindre un framework senzill per desenvolupar aplicacions web amb PHP. A partir del proper post començaré amb el codi del meu propi i a cada post tractaré cadascuna d'aquestes característiques d'una manera més àmplia.

continuarà...

Característiques superficials dels frameworks

Vaig arribar a un punt en què vaig adonar-me que les situacions descrites als posts anteriors no m'ajudaven a fer aplicacions web d'una manera ràpida, còmoda i eficient. Estava clar que devia canviar la manera d'afrontar la creació d'aquest tipus d'aplicacions i vaig decidir buscar frameworks per PHP per investigar una mica el seu funcionament i veure fins on era capaç d'arribar.

Frameworks d'aquest estil per PHP hi ha per donar i vendre, hi ha una gran quantitat i sovint apareixen de nous. Triar-ne uns quants per guiar-me en la construcció del meu fou senzill, vaig buscar el Top 10 i em vaig quedar amb uns quants, en especial aquells tenen una pàgina web completa, amb documentació i fòrums i wikis, ja que probablement això vullga dir que els desenvolupadors treballen constantment en el framework i hi ha una quantitat important de gent que l'usa. Els escollits per estripar van ser CakePHP, Symfony, Madeam, CodeIgniter i Kohana.

A la pàgina principal de cada framework dels seleccionats hi ha una breu descripció del mateix on s'enumeren les principals característiques i les contribucions que al benestar i evolució de la humanitat aporten cadascun d'ells. Aquestes són les característiques superficials, és a dir, les que es poden observar des de fora, les que els creadors dels frameworks usaran per vendre't la moto i amb les que quedaràs bocabadat si no has programat mai. Si fem una llista veurem que moltes d'aquestes són comunes a tots ells i que es poden tindre en compte per construir-ne un. Aquestes són:

• Són frameworks per a PHP (evident!), però el més interessant és que ho són per a versions superiors a la 5, que és a partir de la qual PHP suporta la programació orientada a objectes. El motiu d'açò és la següent característica.
• El framework a construir ho estarà fet amb aquest paradigma de programació ja que afavoreix les bones pràctiques com l'ús de patrons de disseny, com per exemple MVC, o tècniques com ORM. A més, estarà construït de manera que espere que el codi escrit pel desenvolupador siga orientat a objectes, per tant, sembla bona idea la característica anterior de restringir als desenvolupadors a que usen la versió 5 o superior de PHP.
• El framework permet crear i mantindre aplicacions web ràpidament escrivint menys codi que fent-la des de zero. D'aquesta manera es pot aconseguir tindre una versió per al client, o per a nosaltres, més prompte que de la manera tradicional.
• Arquitectura fàcilment ampliable o arquitectura de plugins: el framework ha d'estar construït de manera que afegir una nova funcionalitat no implique modificar el codi.
• Convenció sobre configuració. És un aspecte prou important; aquest paradigma de disseny software pretén alliberar al(s) desenvolupador(s) de certes tasques simplement fent ús d'unes regles establertes.
• Configuració mínima. Els preparatius per poder usar el framework i crear una aplicació així com els fitxers de configuració han de ser pràcticament inexistents.
• Compatibilitat amb hostings estàndard. El framework deu funcionar sense que el servidor web haja de configurar-se de cap extranya manera i pràcticament a qualsevol dels que es puguen contractar per allotjar una aplicació web.
• Open Source. Tots aquestos frameworks per PHP (imagine que els demés també) són de codi obert, de manera que aquest està disponible a tothom i estan lliberats baix alguna llicència que permet modificar-lo i adaptar-lo a les necessitats concretes de l'usuari.

A més de les característiques comunes hi ha d'altres que entren en contradicció entre els distints frameworks, com poden ser:

• Llibreries de tercers. Hi ha algun framework que està construit a base de llibreries de tercers, altres que només en fan ús d'algunes i altres que no les permeten. Jo pense que una bona opció és, per cada nova funcionalitat, crear una interfície i, per cada llibreria (bé de tercers o pròpia) que suporte aquesta nova funcionalitat, crear una classe que implemente aquesta interfície i faça ús de la llibreria en qüestió.
• Ús de l'intèrpret d'ordres. Hi ha frameworks que no fan cap menció al respecte d'aquesta característica dels sistemes operatius i n'hi ha que explícitament asseguren a l'usuari (al programador que farà ús del framework) que no la van a necessitar potser perquè consideren que usar l'intèrpret d'ordres s'escapa a usuaris d'un cert nivell i usar un framework per crear aplicacions web deuria estar a l'abast de qualsevol (personalment considere que NO deuria ser una ferramenta per a qualsevol). També hi ha altres frameworks que sí fan ús d'aquesta opció recalcant que és una ferramenta poderosa. Particularment considere que és una bona opció per tal d'agilitzar algunes tasques senzilles com pot ser crear una estructura de directoris estàndar on allotjar l'aplicació web.

Al proper post (espere que no siga dins de mig any) descriuré les característiques funcionals (no sé si aquesta paraula és l'adequada però queda be...) que deuria tindre el framework que vull construir.

continuarà...

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à...

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à...

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à...