Indalcasa

Esta a punto de llegar una gran noticia para los programadores de PHP. La versión actual de desarrollo y que saldrá oficialmente en breve, ademas de otras muchas mejoras, incorpora el tan ansiado espacio de nombres (namespace) que permite definir varios espacios donde puede existir una misma clase del mismo nombre en lugares diferentes, ademas de estructurar mucho más y mejor el código.

Con el desarrollo de los namespaces, PHP da un gran salto hacia lenguajes de programación mas complejos y de mayor calidad. Salvo algunos detalles, a partir de la versión 5.3 de PHP, ya casi se puede equiparar a este con .Net o Java en cuanto a sintaxis y funcionalidad, aunque aún le queda mucho por desarrollar.

Para usar los namespaces es tan sencillo como declarar el namespace y dentro de este declarar todas las clases o funciones

  namespace NombreDeEspacio;  Class Ejemplo {
 
    public function metodoDePrueba() {
 
  }

Y para importarlo tan sencillo como

  use NombreDeEspacio;

Espero poder decir al igual que ahora con los namespaces, que pronto habrá una solución real para crear hilos (Thread) con PHP.

Tengo instalada aunque no la uso la libreria de SQLite para PHP en el trabajo. Como estoy viendo que esta empezando a coger fama y según lo que he leído es como un Access pero bien hecho, me llamo la atención y me puse a instalarlo en casa. Como de costumbre a la hora de añadir una nueva extensión de PHP, abro el php.ini para descomentar la linea de la extension.

   extension=php_sqlite.dll

Cual es mi sorpresa que la extensión no funciona pero no me aparece ningún error. Hago un phpinfo pero no me muestra la extensión ni sus funciones, pruebo con get_loaded_extensions, y la extensión no aparece. Como me ha pasado otras veces, he probado a quitar alguna extensión por si no estuviera editando el php.ini correcto asi que al quitar extensiones, se quitan correctamente.

Como no encuentro información en internet acerca de este problema, habilito algunas extensiones mas y de repente funciona la extensión de SQLite, así que empiezo a descartar extensiones y me encuentro con la extensión extension=php_pdo.dll, y es que al parecer, a partir de cierta versión de PHP5 para hacer funcionar la librería de SQLite, es necesario tener habilitada la librería PDO.

Finalmente las extensiones cargadas en el php.ini para poder usar la extensión de SQLite debe de ser:

   extension=php_sqlite.dll
   extension=php_pdo.dll

Es algo que me ha sorprendido y me he visto en la necesidad de escribir sobre esto, ya que es la primera vez que me encuentro que una extensión de PHP compilada en C requiere de otra extensión.

Hace ya algunos años que me dedico a la programación en exclusiva de PHP en entornos web, pero a pesar de tratarse de entornos web, no son páginas web, sino webservices, donde la presentación gráfica esta de sobra porque todo se transmite por XML. Durante este tiempo he pasado por diferentes IDE's de programación, terminando en el Zend Studio 5.2 y 5.5, ya que para entornos de desarrollo complejos donde el numero de clases, interfaces, variables, etc. es enorme y se mueven multitud de datos, es el mejor con diferencia.

Es cierto que el Zend Studio es maravilloso si lo comparamos con el resto de IDE's de PHP que hay en el mercado, sobre todo y algo que los demás no tienen es el reconocimiento de las clases que nosotros mismos desarrollamos y su documentación al estilo PHPDoc. Hace algunos meses, redescubrí el plugin PDT de Eclipse, que había dejado de estar verde, para tener un autocompletado del código casi equiparable con el del propio Zend Studio, pero con la gran ventaja de ser mas ligero a pesar de que Eclipse consume más memoria  RAM.

Hace un par de días, vi por primera vez Aptana, un IDE basado en Eclipse que incorpora interesantes funcionalidades como una mejor cobertura del autocompletado de código en cuanto a HTML y CSS se refiere y algo que me ha maravillado, un autocompletado y reconocimiento de clases y funciones de Javascript. Esto me ha maravillado porque para desarrollar una web gráfica, es lo mejorcito que he visto.

Lo que había pensado y efectivamente se puede hacer, es que si PDT es un plugin de Eclipse y Aptana es otro plugin de Eclipse, quizás se pudieran mezclar creando un conjunto realmente bueno por no decir el mejor para el desarrollo web.  Lo más curioso, es que analizando un poco las funcionalidades de Aptana, me he dado cuenta o eso me ha parecido, que la parte de PHP usa el plugin PDT (al menos es igualito) pero de una versión vieja, que por mi experiencia creo que se trata de la 0.7. Así que aventurandome a mezclar los dos plugins y cruzando los dedos para que los apartados de PHP no se den de ostias, los instale.

El resultado de mi experimento es un Eclipse con el plugin de PDT y Aptana instalados a la perfección, si creo un nuevo proyecto de PHP con la vista de PHP (PDT) utiliza todo el entorno de PDT para las páginas PHP y el sitema de Aptana para todas las paginas de Javascript, HTML, CSS, etc. por lo que podemos tener el que sería para un profesional, el mejor IDE de desarrollo para PHP, HTML, CSS y Javascript que podemos encontrar, completamente gratuito y multiplataforma.

Llevo ya bastante tiempo utilizando PHP-GTK 2 para hacer alguna que otra aplicación. En Windows me va de maravilla, ya que tienes Gnope que es autoinstalable y es de agradecer porque las primeras versiones de PHP-GTK 1 para mi eran un infierno. Otra alternativa son las últimas versiones compiladas de PHP-GTK para Windows, ya que es copiar y pegar, no hay que hacer nada para hacerlas correr.

Al dar el paso de Linux me encontre con un problema, y es que por mas que buscara, no había o no encontraba ningún paquete instalable de PHP-GTK. Buscando por internet veia como todo el mundo que lo utilizaba simpelemente hacia un:

  ./configure
  make
  make install

Al intentarlo yo, ingenuo de mi por ver la facilidad con que lo hacia el resto de la gente, lo intente, y lo único que consegui fue una consola llena de errores por todos lados.

Como me paso al compilar Wine, pense que podría ser que necesitara los sources de las diferentes librerias que quería instalar. Fui en busca de Synaptic e instale los paquetes dev de Gtk, SourceView, Mozilla Firefox, GtkHtml, GtkExtra, GtkExtra y LibSexy.

Una vez tengamos instalados todos estos paquetes dev (para el desarrollo), procedi a un configure completo, copilarlo e instalarlo.

  ./configure --enable-php-gtk --with-extra --with-html
     --with-libsexy --with-mozembed --with-sourceview
     --with-spell
  make
  make install

Aparte de esto, me aventure a crear mi primer paquete .deb que he hecho nunca, que a pesar de ser muy chapucero, al menos instala php-gtk en el sistema y funciona perfectamente, salvo por unas modificaciones de configuración que debemos de realizar a manita. Por si alguien se quiere ahorrar compilarlo, se puede descargar el paquete .deb de php-gtk 2.

Para finalizar la instalación deberemos de activar el modulo en el php.ini. En mi instalación de PHP, no hay un php.ini global, sino que hay uno pequeño y muchos, uno por cada extensión. Yo lo he creado donde las extensiones, creando un nuevo archivo que he llamado gtk.ini, pero podeis ponerlo en el php.ini principal. Lo unico que deberemos de hacer es añadir la linea:

  extension=php_gtk2.so

A continuación os detallo las librerias que se pueden encontrar con la instalación de PHP-GTK.

• Gtk: todos los componentes básicos de Gtk, tales como GtkWindow por ejemplo, por decirlo de alguna manera, es lo básico para crear cualquier aplicación.
• LibSexy: no lo he probado y me baso solo en la teoría que he visto por la web. Se trata de clases especiales para poner iconos en los GtkEntry, corrección ortografica, etc. (las pijerias).
• GtkHtml: es un motor de renderización de HTML. El HTML lo pinta bien, pero los enlaces no funcionan, supongo que habrá que programar todos los posibles eventos que puedan surgir.
• GtkExtra: tampoco lo he podido probar, pero supuestamente da Widget extra como los GtkSheet al estilo excel o algunos de diseño lineal que creo que no estan incluidos en PHP-GTK.
• MozEmbed: se supone que es el motor de renderizado de HTML de Gecko (el de Mozilla Firefox), pero no he conseguido hacerlo funcionar ya que me da un error en el nucleo de GTK, que creo que es debido a que necesita unas cuantas librerias que utiliza el propio Firefox para que funcione.
• SourceView: es una parte bastante interesante de Gtk, ya que se trata de un Widget que hereda directamente de GtkTextView pero que provee de un coloreado de sintaxis para multitud de lenguajes de programación, incluidos por supuesto PHP, C#, C, Java, Ruby, Xml, etc. Tambien provee de algunas mejoras al GtkTextView como una regla para marcar el número de linea o algunos eventos como el coloreado de la llave enlazada por ejemplo cuando es una función o clase. Este modulo funciona a la perfección.
• GtkSpell: un corrector ortografico que subralla de una linea roja las palabras mal escritas. Lo he probado y funciona a la perfección, supongo que tendra soporte de lenguajes.

Si alguien quiere ver algo más de información sobre el tema, que le eche un vistazo a la página del proyecto PHP-GTK.

Voy a explicar la diferencia entre estas dos funciones propias de php para evaluar y extraer información sobre cadenas mediante el uso de expresiones regulares o patrones.

Aparentemente estas 2 funciones son aparentemente iguales. Las diferencias entre ellas son mínimas, como por ejemplo que en preg_match es obligatorio establecer unas barras que delimitan el patrón, o que esta función devuelve un entero (int) de 0-n, en función de las coincidencias encontradas, mientras que ereg devuelve un booleano en función de si ha encontrado o no coincidencias.

Entonces. ¿Dónde radica la diferencia entre preg_match y ereg? Pues la principal diferencia ya que ambos también devuelven un array con las coincidencias por referencia, es la potencia. La función preg_match es muy potente y muy útil al igual que ereg, generalmente se suelen utilizar preg_match para extraer información de un texto y la función ereg para evaluar si un texto cumple un patrón o no, como es el caso de un email [a-zA-Z0-9]{1,}@[a-zA-Z0-9]{1,}\.[a-zA-Z]{2,3}. El problema viene cuando realizamos un patrón relativamente complejo sobre un texto extenso, es ahí cuando vemos la verdadera diferencia de potencia entre preg_match y ereg, ya que el preg_match podría llegar a tardar 60 segundos en analizarlo (hablo por propia experiencia) mientras que el mismo patrón evaluado con ereg, tardaría unos 5 o 6 segundos.

En conclusión podríamos decir que preg_match es una función ideal para analizar y realizar patrones sobre textos relativamente pequeños, tal como el contenido de una pagina web por ejemplo, y ereg es para evaluar patrones rápidos como palabras o emails y cuando el patrón a evaluar es muy muy grande.