oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: symfony

Jornades #decharlas sobre #symfony

Reading time: 4 – 6 minutes

symfony logo

Com deia a l’anterior article, el dilluns i dimarts vaig ser per la zona de Castelló per assistir amb el Benja a les jornades de Symfony organitzades per la Universitat de Jaume I de Castelló. Doncs bé, comentar que les jornades em van sorprendre molt positivament, realment hi havia gent amb força o fins hi tot molt nivell en la materia i això sempre és d’agraïr en aquest tipus d’events.

El programa de les xerrades era molt interessant i tret d’algunes xerrades puntuals totes eren del màxim interés per mi. Com molts esteu cansats de sentir jo no sóc programador, però en aquesta vida he picat força codi i concretament amb Symfony vaig començar-ho a fer en la versió 0.6.4, o sigui, molt abans que fos estable. Però de la mà de l’Oriol M. varem fer un projecte amb uns quants megues de codi font per fer recàrregues de mòbil a una cadena de botigues de fotografia, un dels codis dels que estic més orgullós.

Tornant a les jornades, volia destacar el meu ranking particular de ponents, es tracta d’un petit TOP 3 que des de la meva més extrema modèstia preten classificar en base a uns criteris totalment subjectius les persones que van saber transmetre els valors més importants que jo busco en una xerrada:

  • Javier Eguíluz (Symfony 2) – a destacar la gran capacitat d’enfocar la conferència cap als items més importants a resaltar, sense oblidar els detalls rellevants en cada moment, tot això sense perdre un fil conductor clar en tota la xarrada. També s’ha de dir que el tema li donava molt de joc per fer embadalir a l’audiència; però va saber com treure-li el suc i tenir-nos a tots ben enganxats malgrat estar molt cansats després de dos dies de conferències sense parar, aquesta va ser l’última conferència.
  • José Antonio Pío (Vistas y sfForm) – cal deixar-ho clar, una màquina té tota la pinta de ser un programador com la copa d’un pi i els típics defectes i virtuts de ser un professor (ho és?). Malgrat sembla que és molt bo i sap explicar-se la densitat del seu contingut i complexitat del mateix, feien complex seguir-lo tota l’estona ja que exigia molt a la concentració. Cosa gens senzilla en una marató de conferències com el que ens ocupa.
  • Jordi Llonch (Plugins) – aquest representant de les nostres terres diria que també ha fet una molt bona feina explicant-nos la potència dels plug-ins de Symfony, potser a nivell personal no m’ha aportat tan com les altres dues xerrades però la qualitat de les transparències, l’oratòria i la bona organització dels continguts diria que l’han convertit en una referència de com fer les coses, sota el meu punt de vista, és clar.

Comentar que la resta de ponències també han estat molt bé, obviament algunes amb més qualitat que d’altres i amb temes que per mi tenien un major interés que altres. Però en conjunt dono una nota altíssima al contingut de les xerrades. Pel que fa a la organització i les instal·lacions un 9, més que res per donar-los marge a millorar. Impresionant el complexe universitari, res a envejar a d’altres que he vist.

Abans de tancar aquest article tan poc ortodoxe per descriure les jornades comentar en forma de punts algunes notes mentals que me n’he emportat:

  • Hauria de posar-me amb Doctrine, però al coneixer Propel mai trobo el moment.
  • Mirar-me a fons referències sobre integració continua amb PHP i eines de gestió de projectes
  • Dona gust adonar-se que moltes pràctiques que has adoptat unilateralment també es comparteixen en la comunitat: temes d’sfForm, vistes, pugins, web escalables, cloud computing, etc.
  • Pel que fa al tema de la web escalable, m’agradaria agafar els ‘slides’ del ponent Asier Marqués i fer el meu propi screencast del tema, comparteixo quasi tot el que va dir a la conferència però em quedo amb les ganes d’aportar-hi el meu granet de sorra.
  • Mirar-me el tema d’ESI que ja l’havia oblidat.
  • MongoDB, com dic cada dia… una passada! i si a sobre es soporta a Doctrine això ja no té preu. Interessant el tema de Mondongo.
  • i l’estrella de tot plegat!!!! Symofny2… estic impacient!!!!

UPDATE: presentacions de les jornades.

Symfony+Propel: usar múltiples schemas en un sol projecte

Reading time: 2 – 3 minutes

La idea que es persegueix al usar múltiples esquemes en un sol projecte és la de poder usar múltiples bases de dades en un sol projecte. La idea sembla molt senzilla, però a través de la documentació oficial del projecte Symfony la veritat és que no he sabut trobar la solució. En l’explicació per portar a terme aquesta funcionalitat hem referiré tota l’estona als fitxers .yml i no als .xml equivalents, però suposo que la idea és totalment exportable.

Es tracta de deixar d’usar el fitxer schemal.yml i passar a usar diferents fitxers anomentats nomarbitrari_schema.yml, si encomptes d’un nom voleu usar un número tampoc hi ha problemes per fer-ho, per exemple, 1_schema.yml i successius.

Pel que fa al contingut d’aquests fitxers és el de sempre, tot i que jo ús recomanaria usar petites ajudes com aquesta:

nombasededades:
  _attributes:
    package: lib.model.nombasededades

Aquest nombasededades l’usarem després per especificar les dades de connexió al fitxer databases.yml, però potser el més interessant és fixar-se en el paràmetre package que ens permet que tot el model de dades quedi guardat dins de lib/model/nombasedades. O sigui, que tot queda molt més ben organitzat i fàcil d’accedir.

Cal que vigileu si dues bases de dades tenen dues taules que s’anomenen igual, ja que si això passa llavors hi haurà un conflicte en els models de dades que es generen, perquè aquestes tindran el mateix nom. Això és fàcilment solucionable simplement a l’schema heu de dir-li que el nom de la classe que representa les dades d’aquella taula de la base de dades és un nom diferent al de la taula, o sigui, el nom escollit per defecte.

Pel que fa al fitxer databases.yml el seu contingut és el de sempre, simplement cal que penseu que cal descriure la connexió de cada una de les bases de dades que heu anat declarant als diferents fitxers d’schema.yml, un exemple:

all:
  nombasededades1:
    class:                sfPropelDatabase
    param:
      ...
  nombasededades2:
    class:                sfPropelDatabase
    param:
      ...

Un cop ben configurat tot això ja podem fer un típic symfony propel-build-model i llestos.

Reddit open source: aplicacions que destaco…

Reading time: 4 – 6 minutes

reddit logoAquest matí l’Alfredo m’ha informat que reddit ha obert el seu codi. Doncs bé després de mirar-me cada un dels components que ha explicat que esta usant m’ha faltat temps per passar-me per cada una de les pàgines web de les aplicacions per mirar-me a veure què tal. A continuació ús faig una llista del que més destaco, obviament són les aplicacions més inusuals i menys conegudes.

  • HAProxy: és un aplicatiu molt semblant al Pound, la seva finalitat es balacejar les peticions HTTP entre diferents servidors. Malgrat són aplicacions similars Pound i HAProxy poden treballar de forma combinada. Diguem que HAProxy esta molt més orientat a grans infraestructures i Pound és per entorns de carrega mitjana. El bo és que podem usar HAProxy i darrera usar Pound per fer redireccions més refinades en funció da la URL o certs paràmetres de les HTTP headers. També és diferencien bàsicament amb el tractament que fan dels paquets HTTPs, la qual també convida a treballar amb les dues eines a la vegada. Ja que podriem montar un sistema per escalar peticions HTTPs de forma segura i simple.
  • Slony-l:és un sistema de replicació master-slave que suporta treballar en cascada i amb failover. A més esta pensat per treballar amb bases de dades grans. Bàsicament usat pel PostgreSQL que usa reddit, això els permet tenir molts servidors de bases de dades de lectura que són les peticions que bàsicament tenen a la base de dades.
  • Pylons: es tracta d’un framework MVC que usa Python, és realment lleuger i combina idees del món Ruby, Python i Perl. Potser una de les coses que més sobte és que els projectes de Pylons no requereixe servidor web sinó es vol, ja que ells mateixos ja n’implementen un amb Python, a més de tenir un instal·lador del projecte que creem només pel sol fet de crear el projecte. Si ja controleu algún tipus d’MVC i esteu una mica familiaritzats amb la sintaxis de Python podeu veure l’screencast: Special Edition Screencast: Pylons with Tesla. Amb aquest screencast ús podreu fer una molt bona idea de com funciona aquest MVC i de la seva potència. S’ha de reconeixer que promet molt no ús perdeu el sistema de debug, realment m’ha agradat moltíssim pensava que el debug de Symfony era bo, però aquest encara el supera.
  • Slor: es tracta d’un servidor d’indexació d’informació web implementat sobre Tomcat i que ofereix serveis de consulta via JSON i d’altres sistemes webservice que simplifiquen moltíssim la seva integració amb d’altres arquitectures. A més disposa d’una llista de funcionalitats molt atractives.
  • Daemontools: una eina realment senzilla i potent, bàsicament només serveix per llençar processos com a dimonis o directament dimonis en si mateixos. El bo és que controla aquests dimonis per si aquests cauen tornar-los a aixecar. La veritat és que malgrat ser una mica més gran diria que és millor monit. Tot i que s’ha de dir que es triga molt mé  montar monit que no pas daemontools i com que la gent de reddit ja usen Ganglia com a sistema de monitorització no s’han complicat amb el monit.

S’ha de reconeixer que han fet molt bones eleccions aquesta colla, a més s’ha demostrat que són realment escalables i que la seva disponibilitat és envejable. Un bon exemple de com fer les coses bé i senzilles des del principi. La gent de twitter en podrien prendre bona nota. Si ús fa il·lusió un dia d’aquests ús explicaré les meves idees de com fer que twitter sigui molt escalable i no s’enfosi amb els 2M d’usuaris que té diariament, la qual cosa no em sembla cap exageració amb un bon disseny darrera segur que en Pau pateix molt més amb els seus milions de megues a indexar diarimant.

SOAP amb Symfony

Reading time: 2 – 3 minutes

symfony.gif

Fa uns mesos vaig implementar una aplicació amb força connexions SOAP tan a nivell de client, com de servidor contra aplicacions .NET i aplicacions SOAP fetes en Symfony mateix. Malgrat funcionen prou bé, he de reconeixer que la implementació SOAP de PHP fins a la versió 5.2.0 que és la última que he provat dona alguns problemes. Ja no quan es comunica amb .NET sinó quan parlo amb ella mateixa. Puc assegurar que no és culpa del codi, perquè l’estructura client servidor de la que parlo feia més de 200 transaccions diaries de les quals unes 10 o 20 fallaben, per errors de l’estil Error Fetching http headers. De fet, investigant vaig trobar algún que altre BUG intern de PHP que comentava el problema, però segons deien a PHP ja estava solucionat. Doncs a mi em continuaven donant. Finalment el que vaig fer per solucionar-ho va ser eliminar SOAP a tot arreu d’on vaig poder, ara mateix no tinc ni un error d’aquest estil i es continuen fent unes 200 transacions diaries o més.

Malgrat aquesta no massa bona experiència, continuo pensant que la idea és boníssima i que cal seguir treballant amb ella. Doncs bé, quan vaig implementar el servidor SOAP via Symfony no vaig trobar cap tipus de documentació que parles de com fer-ho bé. Així doncs vaig improvisar i vaig repartir el codi entre les actions i els templates amb tan bon criteri com vaig saber, tan per publicar el fitxer WSDL com per publicar el servei SOAP. Ara esta apunt de sortir la versió 1.0 de Symfony i curiosament també s’ha publicat un snippet on es parla de com publicar un servei SOAP desde Symfony. Així doncs, he de reconeixer que la implementació que es fa de la idea en aquest snippet és molt millor que la meva. Per tant, el recomano: Code Snippets: Soap server (local).

Yahoo! bookmarks usa symfony

Reading time: 2 – 2 minutes

yahoobookmarkslogo.jpg

Fa força dies que no parlo de res relacionat amb el symfony, de fet, això és el que té la meva feina que m’he de moure molt ràpid entre tecnologies depenent del projecte. Doncs bé, ni molt menys m’he oblidat d’ell. Però ara més que PHP estic tocant temes de Python, a nivell de programació. De totes formes el que volia comentar aquí és una notícia que he trobat al blog de symfony concretament es comenta que la gent de Yahoo! bookmarks ha escollit aquest framework que l’Oriol i jo ja varem escollir fa uns mesos per un projecte de recàrrega de telèfons mòbils i venta de targetes internacionls que encara tinc pendent de comentar a la web de movilpoint.

Així doncs, notícies com aquestes són les que et fan anar a dormir amb la consciència ben tranquila per les teves decisions. Realment és un plaer veure com gent de nivell tècnic tan contrastat com és l’equip de Yahoo! ens confirmen el que nosaltres ja varem opinar fa una bona colla de mesos. Tot això fa que encara tingui més ganes de que arribi la esperada versió 1.0 d’aquest framework malgrat suposarà força canvis profunds en algunes parts importants del funcionament del mateix i potser haurem de reprogramar parts importants de les nostres aplicacions. Però segur que valdrà la pena fer-ho.

symfony: protegint els entorns de desenvolupament, integració i producció

Reading time: 7 – 12 minutes

A l’article symfony: entorns de desenvolupament, integració i producció es pot entendre el perquè de treballar amb aquests tres espais de noms (environment) així doncs el que es preten explicar és:

  • Impedir accés a les aplicacions en entorns de ‘dev’ i ‘int’ des de llocs no controlats. O sigui, que una IP d’internet no pugui executar myapp_dev.php o myapp_int.php però encanvi una IP de la xarxa del desenvolupador si que pugui.
  • Impedir accés a aplicacions de backend des de l’entorn de producció. Si hem desenvolupat alguna aplicació per tal de fer el manteniment de l’aplicació principal, una part d’administració o backend aquesta no sigui accessible des d’IPs no controlades.
  • Separar el fitxer de configuració config/cofnig.php per cada un dels entorns. Així podem definir constants o d’altres tasques de forma particular per cada un dels entorns.

Per tal d’aconseguir aquests objectius he creat el fitxer config/config.lib.php:

<?php
/**
 * Comproba si la IP amb la que s'accedeix a l'aplicació permet connectar en aquest environment
 *
 * @param string $env nom de l'environment
 * @param array $ips ips des de les que podem accedir a l'environment
 * @param string $clientip ip del client que vol accedir al recurs
 */
function envCorrecte ($env,$ips,$clientip)
	{
	if (SF_ENVIRONMENT==$env)
	{
		$acces=0;
			foreach($ips as $ip)
		{
			$ipclient=substr($clientip,0,strlen($ip));
				if ($ipclient==$ip)
			{
				$acces=1;
				}
		}
		if ($acces==0)
			{
			echo "You are not in '".$env."' environment! (".$ipclient."<>".$ip.")";
				exit;
		}
	}
}
/**
 * Comproba si l'aplicació amb la que s'accedeix al projecte és publica o no
 *
 * @param array $apps llista d'aplicacions no públiques
 * @param array $ips llista d'IP amb les que es pot accedir a les apps no públiques
 * @param string $clientip ip del client que vol accedir al recurs
 */
function appCorrecte ($apps,$ips,$clientip)
	{
	// solucionem problema de la clau '0'
    	$apps_aux[0]='';
		$apps = $apps_aux + $apps;
	//
	if (array_search(SF_APP,$apps)!=false)
		{
		$acces=0;
		foreach($ips as $ip)
			{
			$ADR=$HTTP_SERVER_VARS['REMOTE_ADDR'];
			$ipclient=substr($clientip,0,strlen($ip));
				if ($ipclient==$ip)
			{
				$acces=1;
				}
		}
		if ($acces==0)
		{
				echo "Keep away! ".SF_APP." is not a public application!";
			exit;
		}
		}
}
?>

Llavors des del fitxer config/config.php cal que cridem aquesta petita llibreria de funcions que he creat. La resta és més que lògica, aquí en teniu un exemple:

<?php
include("config.lib.php");
/**
 * Controlem accés als 'environments' de 'env' i 'int'
 */
$ip_dev=array("10.138.0.","192.168.");
$ip_int=array("10.138.0.","192.168.");
envCorrecte('env',$ip_env,$HTTP_SERVER_VARS['REMOTE_ADDR']);
envCorrecte('int',$ip_int,$HTTP_SERVER_VARS['REMOTE_ADDR']);
/**
 * Controlem accés a les 'apps' d'ús privat
 */
$ip_apps=array("10.138.0.","192.168.","w.x.y.z");
$apps=array('myapp_1','myapp_2','myapp_n');
appCorrecte($apps,$ip_apps,$HTTP_SERVER_VARS['REMOTE_ADDR']);
/**
 * Carreguem el fitxer de configuració propi de l'"environment".
 */
include("config.".SF_ENVIRONMENT.".php");
/**
 * Part comú en els 3 entorns
 */
?>

Com podeu veure el codi és molt senzill i la potència i el dinamisme, excepcionals.

Aquest codi també l’he publicat com un snippet a Access control to environment and applications and custom global config file for an environment.

symfony: entorns de desenvolupament, integració i producció

Reading time: 3 – 4 minutes

Al desenvolupar un projecte de software m’agrada treballar en 3 entorns. Mentre s’esta desenvolupant el projecte esta bé tenir un espai de variables (o entorn de noms) a l’aplicació que correspongui als ajustaments del servidor de desenvolupament (normalment una màquina pròpia), per exemple, els path, urls, dades de la bbdd, etc. tot això ha d’estar el màxim separat possible del codi per tal de poder crear les configuracions pels entorns d’integració i producció.

L’entorn d’integració és una màquina en l’entorn de desenvolupament del client, amb les característiques el més semblants possibles a l’entorn de producció. O sigui, les dades de configuració de l’espai de noms han d’apuntar a serveis si pot ser de la mateixa versió que l’entorn de producció. Així podem provar l’aplicació i millores de l’aplicació abans de passar-la a producció. Finalment hem de tenir l’entorn de noms per producció amb les dades de treball.

Per tal de suportar tot això symfony suporta en moltíssims fitxers de configuració la possibilitat de definir l’environment, en el cas que plantejo, ‘dev’, ‘int’ i ‘prod’. En el front controller de cada aplicació podem definir aquest entorn de noms així després s’accedirà a la part dels fitxers de configuració que pertoca.

Per exemple, si mirem el fixer config/databases.yml on symfony defineix els sistemes de BBDD que usa la nostre aplicació en cada un dels environments podriem tenir algo així:

dev:
  nombbdd:
    class:           sfPropelDatabase
    param:
      phptype:       mysql
      hostspec:      localhost
      database:      nombbdd
      username:      userbbdd
      password:      passbbdd
int:
  nombbdd:
    class:          sfPropelDatabase
    param:
      phptype:      oracle
      username:     nombbdd
      password:     nombbdd
      hostspec:     hostint
      database:     NULL
prod:
  nombbdd:
    class:          sfPropelDatabase
    param:
      phptype:      oracle
      username:     nombbdd
      password:     nombbdd
      hostspec:     hostprod
      database:     NULL

Al cridar el front controller és quan symfony diu amb quin environment treballarem, per exemple, per una aplicació anomenada myapp podriem tenir aquests tres front controllers un per cada entorn:

Entorn de desenvolupament web/myapp_dev.php:

<?php
define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
define('SF_APP',         'myapp');
define('SF_ENVIRONMENT', 'dev');
define('SF_DEBUG',       true);
#
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
#
sfContext::getInstance()->getController()->dispatch();
?>

Entorn de integració web/myapp_int.php:

<?php
define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
define('SF_APP',         'myapp');
define('SF_ENVIRONMENT', 'int');
define('SF_DEBUG',       true);
#
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
#
sfContext::getInstance()->getController()->dispatch();
?>

Entorn de producció web/myapp.php:

<?php
define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
define('SF_APP',         'myapp');
define('SF_ENVIRONMENT', 'prod');
define('SF_DEBUG',       false);
#
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
#
sfContext::getInstance()->getController()->dispatch();
?>

Com es pot veure, tan desenvolupament com integració ens mostraran informació de debug i producció amagarà els missatges d’error i reportarà sempre l’error “internal server error”. A més podem veure que tots tres entorns criden el mateix fitxer de configuració global config/config.php.

Si voleu més informació sobre aquest tema us recomano els següents enllaços de la documentació de symfony:

symfony: interficies amb tabs de forma molt senzilla

Reading time: 1 – 2 minutes

L’últim snippet que han pujat al repositori de symfony és un somni fet realitat. Sempre m’ha fet molta ràbia haver de montar-me un sistema de tabbing per una interficie web (UI web) i el que ens proposa aquest snippet és un helper que permet cridar una llibreria anomenada Tab Pane (llicència web 2.0) que a través de javascript modifica els objectes DOM de la pàgina web i ens permet treballar amb uns tabuladors molt ràpids. A més fins hi tot suporta diferents aspectes. Realment una forma molt còmode i senzilla de treballar amb interficies tabulades.

tabs.png

Doncs tornant a l’snippet de symfony podem cridar el helper i començar a usar el codi de forma ben senzilla, a la pròpia descripció en podeu veure un exemple. Doneu-hi un cop d’ull a Helper for Javascript Tabbed Panes. Com és obvi recordeu que aquest helper s’ha d’invocar des de la vista (template).

symfony: cridant funcions i18n des de les actions

Reading time: 2 – 4 minutes

Una eina molt potent de symfony és la d’internacionalització (i18n), concretament la funció __() es converteix en una de les més usades i indispensables en la capa de vista de les nostres aplicacions. Ja que permet després de forma molt senzilla traduir la nostre aplicació a l’idioma que sigui. El problema és quan des de la part del model em de carregar informació a objectes que després seràn directament mostrats per la vista. Si volem que aquesta informació sigui fàcilment traudible malgrat trobar-se en el model i no pas en la capa de vista la cosa es complica una miqueta. De fet, fins avui no sabia com es feia i ho he descobert gràcies a un snippet publicat a la web de symfony.

Concretament symfony tracta la funció __() com el que ell anomena un helper que ens permeten dinamitzar i donar moltíssima potència als nostres templates. Si no sabeu el que són els helpers us recomano que repasseu la documentació de symfony concretmanet View chapter. De fet, symfony té molts tipus de helpers: url, javascript, form, i18n, etc. fins hi tot podem programar els nostres propis helpers.

Així doncs el que comentaré serà com usar els helpers de tipus i18n des del model, però la resta de helpers també es poden invocar de la mateixa manera.

Primer cal pensar en incloure des del model el codi on es declaren les funcions del helper:

include_once('symfony/helper/I18NHelper.php');

Per invocar la funció __(), hem de fer:

sfConfig::get('sf_i18n_instance')->__($text, $args, 'messages');

El que no sé és si les eines de traducció que es dediquen a extreure els missatges de les funcions __() són capaces de recorre també els fitxers d’accions definits al model o només passen pels templates. Tot i que no deu ser molt difícil dir-los que també mirin els fitxers del model.

Aprofitant que parlo del tema de la internacionlització us recomano una eina per traduir els fitxers d’idioma (XLIFF) és una eina multiplataforma programada en java: open language tools XLIFF editor. Com podeu veure l’aspecte i la simplicitat és inmillorable. Ideal per persones no tècniques que ens poden fer les traduccions de les aplicacions.

Per generar els fitxers XLIFF des de symfony us recomano: HowToGenerateI18NFiles. És un petit manual que he trobat al wiki de symfony.

symfony: Problemes de javascript

Reading time: 1 – 2 minutes

prototype.png

Symfony usa prototype com a framework de JavaScript. Malgrat la potència del projecte té un petit problema de disseny que ens dona problemes quan intentem integrar el nostre codi fet en prototype/symfony amb codi JavaScript de tercers. De fet, el problema de disseny és molt senzill prototype exten dues classes bàsiques de JavaScript: Object i Array ambdues són classes molt bàsiques i sovint usades en qualsevol script així doncs quan aquest codi intenta usar aquestes classes bàsiques al estar exteses no tenen el comportament habitual, així doncs el codi d’aquestes persones s’ha d’adaptar per suportar les modificacions de prototype. Així doncs, si això no és possible tindrem un problema d’incompatibilitat entre codis.

Si voleu més detalls tèncis sobre el problema l’Oriol m’ha passat un parell d’enllaços es raona el problema: