Mostrando las entradas con la etiqueta zend. Mostrar todas las entradas
Mostrando las entradas con la etiqueta zend. Mostrar todas las entradas

Zend Framework 3 disponible!




We are excited to deliver the latest release of Zend Framework, the first major release in four years.

Zend Framework 3, along with recent releases of Zend Server 9 and Zend Studio 13.5, makes it easier for you to develop, debug, monitor, and deploy modern web and mobile apps in PHP 7.

Zend Framework 3 includes:
  • Increased performance – up to 4X faster applications under PHP 5, and even better using
    PHP 7
  • PHP 7 support
  • Improved documentation for each component repository
  • Expressive, a PSR-7 middleware microframework that focuses on simplicity and interoperability
Create PHP applications simpler and faster with Zend Framework 3.
   
  

Happy PHPing,

http://info.zend.com/P000r0jLAX0H540U0zUC6R0

https://framework.zend.com/blog/2016-06-28-zend-framework-3.html

https://docs.zendframework.com/tutorials/migration/to-v3/overview/



PHP7 final ya está aquí!

 Lo anuncian con bombos y platillos, sitio oficial y la empresa Zend








Fuentes



Nueva versión: Zend Framework 2.0.3!

Nueva versión de Zend Framework 2 disponible (la cual incorporaremos en los cursos que iniciaremos en breve):

Zend Framework 2.0.3 Released!

The Zend Framework community is pleased to announce the immediate availability of Zend Framework 2.0.3! Packages and installation instructions are available at:

Changelog

This release included 115 changes, ranging from minor docblock improvements to bugfixes. The full list is as follows:

Thank You!

Many thanks to all contributors to this release!

Reminder

Maintenance releases happen monthly on the third Wednesday. Additionally, we have the next minor release, 2.1.0, slated for sometime next month.

Fuente: ZF Blog

[SURFORCE]: ¡Últimos cursos del año!


¡Estimados lectores, se vienen los últimos cursos del año! Hace unas semanas que se están recibiendo los pagos de las inscripciones:
  • Fecha de inicio de los cursos: Lunes 5/Octubre
  • Fecha límite para hacer los pagos: Viernes 2/octubre
Y como novedad para todos los alumnos que ya hicieron el curso de Introducción a Zend Framework, estamos iniciando el primer Taller de Desarrollo en Zend Framework, donde aplicaremos todo lo visto en el curso (y más), trabajando de principio a fin un proyecto completo de desarrollo a distancia (incorporando versionado con svn, instalación en servidores, gestión ágil de proyectos, etc)

¡No pierdas tu lugar! ¡De lo contrario, hasta el año que viene! ;-)

Para poder realizar la inscripción empieza por registrarte como usuario en SURFORCE

PD: cualquier duda o asesoramiento puedes enviarnos un email a info en surforce.com

Polémica / discusión: ¿Debemos usar "null == $var" ó "$var == null"?

Algunos de mis lectores y colegas se quejan que gracias a los cursos el blog quedó un poco vacío de contenidos, así que voy a compartir una discusión interesante que se dió en el foro de uno de los grupos del curso "Introducción a Zend Framework" ;-)

Se presentó un ejemplo donde se usaba un if con "null === $var", en vez del tradicional "$var === null" (el orden invertido).

Aquí mi explicación:

Imagen de Enrique Place
Re: Pagina 13 Correccion
de Enrique Place - viernes, 27 de marzo de 2009, 19:57


Mmmm ... en lo personal no soy partidario de usar null === dato, prefiero el estándar dato === null, ya que es más claro y natural su lectura:

Leyendo de izquierda a derecha, "si el dato es exactamente igual a null" en oposición a "si null es exactamente igual al dato" guiño

Aunque conozco la seudo-ventaja de evitar un accidente de asignación, no creo que exista un IDE que no te marque el error.

Prefiero siempre pensar que debemos codificar para otros y cuanto más claro, simple y natural, más fácil será que nos sigan.

Es una opinión, podemos definir con un "si el estándar Zend lo dice, lo acatamos" guiño

Hablando con un colega sobre este tema (lo bueno de tener colegas desarrolladores / docentes es que podemos tener formas distintas de ver las cosas y podemos discutirlas de manera constructiva y hasta corregirnos entre nosotros), me comentaba que en todo el código fuente de ZF se usa la forma "null == $var", por lo que me decía que era un "estándar" de ZF.

En su momento no tenía tantas horas recorridas dentro del código de ZF, por lo tanto no estaba seguro si realmente se usaba en el 100% del código o sucedía en algunas partes del mismo, así que me puse a volver a revisar los documentos donde especifican el estándar de Zend (no sería la primera vez que me olvide de algún detalle del mismo, por eso siempre RTFM):

El borrador que supuestamente se va actualizando y discutiendo hasta pasar al documento formal
http://framework.zend.com/wiki/display/ZFDEV/PHP+Coding+Standard+(draft)

Documento formal

http://framework.zend.com/manual/en/coding-standard.html

En ambos casos no encontré ninguna sugerencia o referencia al respecto. Así que podríamos llegar a la siguiente conclusión:
  • Esta práctica o técnica no es parte (actualmente) del documento de estándar de codificación (no se sugiere en ningún momento).
  • Pero, aparentemente es un "estándar de facto" ("de hecho") o directamente "una práctica de facto" (más que un estándar de codificación) que los desarrolladores de ZF hacen uso (se puede ver en el código).
Por lo tanto, en mi opinión, si no hay evidencias que en ninguna parte del código de Zend exista el uso inverso, es decir "$var == null", podríamos llegar a la conclusión que es una práctica que deberíamos seguir (aunque yo no lo haya hecho hasta la fecha).

Los Estándares

Los estándares solo sirven si los seguimos todos, de lo contrario no son estándares y se pierde su efecto, y deberíamos dar el ejemplo, por lo que su adopción nos beneficia a todos los desarrolladores (ya que codificaríamos con las mismas reglas, facilitando el entendimiento y dejando un código más "uniforme").

Le comentaba a este colega que hace unos años cuando empecé a adoptar el primer estándar de codificación de Zend (cuando ZF ya se podía empezar a usar en su primer versión) me "dolió bastante" tener que adoptar las llaves iniciando a la izquierda (al estilo C++) y el uso de "_" para todo lo que es "elementos privados", de la misma forma me sucede con el nombre con separación "_" (ej: Zend_Db, Zend_View, etc), ya que estamos modificando los nombres de las clases por un problema de PHP de no tener resuelto el manejo de ubicaciones de directorios y namespaces.

Cabe acotar que muchas tecnologías, como Java o .Net, vienen siempre de la mano de una empresa que a su vez vende su IDE y este ayuda a resolver todos estos problemas (de cómo ubicar los archivos / directorios) y en sí no es tanto problema del lenguaje, aunque ayuda que este maneje conceptos como paquetes / namespaces, y que nosotros nunca tuvimos desde PHP esa relación con ningún IDE (donde muchos desarrolladores aún usan editores de código).

Pero, como acotaba antes, si no adoptamos todos el estándar y tratamos que los demás lo usen, el estándar carece de efecto y no sirve, a ningún desarrollador Java o .Net se le ocurre cambiar la forma de indentar el código por una propia. Por ejemplo, el IDE de .Net (Visual Studio .Net) no te permite cambiar la indentación, él te indenta automáticamente. La primera vez que lo usé dije "¡qué es esto!" pero luego me di cuenta que en realidad era una muy buena idea, no te dejaba lugar a "inventar" estándares y a preocuparte en lo funcional (de todas formas si creas atributos, métodos o variables de un solo carácter, hasta donde sé, te lo sigue permitiendo ;-))

En Resumen

Como docente y como "desarrollador que codifica pensando en los demás", esta práctica no es de mi agrado (por un tema de claridad), y tampoco aparece explícitamente en el documento de estándar de codificación (se podría hasta pensar que es una técnica para evitar un error y no una forma de codificación, aunque lleva a cambiar todo el "paisaje" de nuestro fuente), por el momento no puedo adoptarlo a menos que así explícitamente esté discutido y comunicado como un estándar formal, más allá de si es un "estándar/práctica/técnica de facto" del equipo de desarrollo de Zend Framework.

Si alguno de vosotros encuentra más argumentos o documentación que hable que debemos seguirlo (como estándar), me avisa, y a los 5 minutos estoy cambiando mi forma de codificar ("la cabeza es redonda para que las ideas puedan cambiar de sentido").

Pero... (segundos antes de publicar este post)

Cuando este post ya estaba casi terminando y reconociendo mi falta de no cumplir algo que era "estándar de facto" y hacer público que aún así no iba a seguir esta práctica (ya que no aparecía en los documentos de estándares), empecé a hacer una investigación en el código de Zend y me llevé una gran sorpresa ;-)

Como soy un poco necio, pero mayormente curioso y metódico, me puse a sacar números reales del uso de una y otra práctica en el código de Zend a través de la siguiente búsqueda (buscar la cadena de forma recursiva dentro del directorio de ZF):

grep -i "null ==" * -R

Ingresé a uno de los servidores en GNU/Linux y tomé el directorio de Zend actualizado a la fecha y realicé las siguientes comprobaciones:

Aquí busqué todas las líneas de código en todos los fuentes de Zend y me encontré con el uso extendido de "null ==" algo.


Pero hice la búsqueda opuesta (pensando que no iba a encontrar nada) y veo que aparecen muchas líneas con "== null" (¿eh?)



Entonces, el pulso me temblaba e hice la siguiente prueba, para cada una de las sentencias antes ejecutadas, conté las lineas de ocurrencia ("wc -l") y llegué a la siguiente conclusión:

  • "null ==" aparece en 546 líneas
  • "== null" aparece en 2444 líneas!
Conclusión Final

Listo, no dije nada, tengo razón, no usen "null ==" por que yo lo digo y se acabó la discusión hasta nuevo aviso ;-)

PD: Esto en sí no es un tema de si mi colega se equivoca o yo, me pareció importante discutir todo el asunto de estándares y técnicas, y particularmente, esta tan controvertida forma de "evitar errores" (que parece está de moda) que en mi opinión lo único que hacen es ofuscar el código.

Además, para quebrar una lanza por mis colegas / amigos, muchas veces me han corregido errores más de los que yo pude encontrarles, sin olvidar que me considero eterno alumno de todo y aún dudo y me equivoco ;-)

Por qué no deberíamos usar los "short tags" <? y <?=

Recientemente en una discusión en un foro uno de los tantos "expertos" que pueblan la comunidad PHP se mostraba contrario a mi explicación de qué cosas debía corregir en su código otro usuario.

Puntualmente la situación era la siguiente:

---Cita (Autor enriqueplace)---

[...]Sustituye los <?= por <?php echo, lo mismo que <? por <?php, está en desuso (por más que veas algunos ejemplos en el manual de Zend, eso es error de algún programador descarriado ;-))[...]

---Fin de Cita---


Y el usuario respondía:

"Che guru, fijate que lo que esta mal es usar el tag como "<?", pero no esta depcrecated el uso de "<?="

Chau guru."


En lo personal puedo aceptar (y me parece obvio) que desarrolladores duden y vuelvan a preguntar, pero no que contradigan sin fundamentos por el simple hecho que "ellos lo usan".

Dado que la discusión se trasladó al ámbito personal (la idea de esta persona era simplemente descalificar), nuestros aportes fueron borrados por el administrador del foro. Como considero que vale la pena la explicación sobre por qué no debemos usar los "short tags" o "etiquetas cortas" de apertura y cierre de PHP (en lo personal hace años evito esta práctica, pero he visto que algunos desarrolladores aún siguen usando).

Aquí la copia de la respuesta dada en el foro:

"Me remito al manual de PHP (que este capítulo está escrito hace mucho tiempo):

Sintaxis básica del lenguaje
http://www.php.net/manual/es/languag...ax.phpmode.php

Donde da ejemplos de todos los tags posibles para PHP, y el segundo dice:

2. <? echo ("esta es la más simple, una instrucción de procesado SGML \n"); ?>
<?= expression ?> Esto es una abreviatura de "<? echo expression ?>"


Este ejemplo hacer referencia al "formato corto de etiquetas" o "short tags", por lo cual el manual aclara:

"El método segundo no siempre está disponible. El formato corto de etiquetas está disponible con la función short_tags() (sólo PHP 3), activando el parámetro del fichero de configuración de PHP short_open_tag, o compilando PHP con la opción --enable-short-tags del comando configure. Aunque esté activa por defecto en php.ini-dist, se desaconseja el uso del formato de etiquetas corto."

Aunque esto pudiera no ser suficiente, el manual vuelve a reiterarlo un poco más abajo y ampliando otras situaciones donde además no es conveniente:

"Note: No se debe usar el formato corto de etiquetas cuando se desarrollen aplicaciones o bibliotecas con intención de redistribuirlas, o cuando se desarrolle para servidores que no están bajo nuestro control, porque puede ser que el formato corto de etiquetas no esté soportado en el servidor. Para generar código portable y redistribuíble, asegúrate de no usar el formato corto de etiquetas."

No recuerdo ahora (tampoco vale la pena buscarlo en este contexto) pero creo haber leído que en la versión 6 o 7 de PHP estos tags serán eliminados.

PD:
ahh, casi me olvido, en el manual de Zend Framework dice claramente "Short tags are never allowed" ("las etiquetas cortas nunca son permitidas"), de ahí mi expresión que "a pesar de ver ejemplos en el manual de Zend, no usarlos como excusa para decir "que no están en desuso / permitidos"".


Nota: Si se toman el tiempo para investigar un poco verán que las fuentes pueden ser contradictorias con sus sugerencias: el manual de PHP dice no usarlos, la guía de buenas prácticas del wiki de los desarrolladores de Zend Framework recomienda por un lado tampoco usarlos, pero por otro lado sí (en determinadas condiciones), y luego se pueden ver ejemplos de código en los dos sentidos (con y sin "short tags").

Claramente la respuesta válida no es "los short tags se pueden usar porque PHP lo permite usar" (de esa forma validaríamos muchas prácticas erróneas) o porque simplemente "yo lo uso hace tiempo" o porque "nunca leí nada que dijera lo contrario" (y ni siquiera han consultado el manual oficial).

En conclusión

Mi recomendación es que no uses los "short tags", usa siempre <?php y <?php echo, solo tienes que escribir unos caracteres más y usas una sintaxis que no te trae problemas en ningún contexto y es la versión "oficial" de los tags de PHP (lo otro es una abreviación).

Ejemplo de excepciones desde Zend Framework

Siguiendo con el post anterior sobre el tema, quería mostrarles otro ejemplo de cómo se manejan las excepciones desde Zend Framework, donde la diferencia principal radica en que obtenemos una lista enorme de clases preestablecidas para el manejo de excepciones (como sucede en lenguajes como Java), lo que nos permite usarlas de forma directa sin tener que implementar nada más que el try/catch.


try{

$this->view->clientes = Models_Clientes::getAll();

}catch(Zend_Db_Statement_Exception $e){

$this->view->mensajeError =
'Se ha producido un error interno al intentar recuperar datos.'
.' Por favor envíe un email a sistemas@surforce.com' ;

}catch(Zend_Db_Adapter_Exception $e){

$this->view->mensajeError =
'Se ha producido un error al conectar a la base de datos.'
.' Por favor reintente en unos minutos';

}catch(Zend_Exception $e){

$this->view->mensajeError =
'Se ha producido un error inesperado.'
.' Por favor reintente en unos minutos';
}

$this->render ();


Repasando: las excepciones deben ordenarse como si fueran reglas de un firewall, la regla más específica debe ir al principio y la más general al final (ya que si lo hacemos al revés siempre entrarán por la primer coincidencia en la regla).

Con Zend_Db_Statement_Exception entrarán todas las fallas que ocurran por errores de sintaxis en el ejecución de sentencias SQL (error bastante grave), en el segundo caso con Zend_Db_Adapter_Exception cualquier falla en la conexión al motor de base de datos y en el último, ya una excepción genérica como Zend_Exception, capturamos cualquier otro error que no pudimos especificar con detalle (algo así como la "pantalla azul de la muerte" de Windows ;-)).

Si no agregamos este try / catch en el momento de la falla enviará directamente en pantalla todo el "volcado" de la Excepción y concluirá la ejecución de la aplicación de forma abrupta.

Pero, si además de esto agregamos en la vista un código como el siguiente, podremos enviar un mensaje al usuario sin distorsionar la interfaz de nuestra aplicación.

En este ejemplo, el código para desplegar el mensaje de error se encuentra en el layout de la aplicación:

< ?php if(!is_null($this->mensajeError)): ?>
< ?php echo $this->mensajeError ?>
< ?php endif ?>

Y con un poco más de trabajo, puede quedar más estético y hasta con una animación (moviendo lateralmente el cuadro un par de veces, como para alertar al usuario) y se vería de esta forma:


Las excepciones son la única forma de tener un manejo uniforme de errores (algo que tienen todos los lenguajes POO modernos) y poder controlar mejor cómo responder a situaciones no esperadas y que nuestra interfaz no quede "desarmada" delante del usuario, lo cual podríamos hasta definir en la configuración que cada vez que ocurra un "error general" envíe un email al departamento de sistemas con todos los datos para poder analizar el fallo ni bien sucede.

¿Y ustedes, usan excepciones? ¿qué otras ideas han aprovechado para implementar y mejorar la funcionalidad de nuestros sistemas?

Presentaciones de la ZendCon 08 (PHP)

Visitando el sitio de Crónicas de un Mundo Gris me encuentro con el link a las Presentaciones de la ZendCon 08 (PHP) que sabía se iba a hacer, pero no estaba al tanto de la disponibilidad del material de las presentaciones.

Todas tienen muy buena pinta, pero me quedo con la primera que usaron de apertura del evento: muy buenos ejemplos, frases y argumentos que cuentan el crecimiento y adopción que está teniendo hoy día PHP en el ámbito empresarial.



La verdad que viendo de afuera, la empresa Zend ha hecho mucho por estar donde está, y que el framework oficial haya crecido tan prolijo y rápido, a logrado que este último se haya vuelto un gran apoyo a la valoración del Desarrollador PHP en un mundo que dominan las "plataformas complejas".

Noticia: GeckoToolbox - PHP Toolbox based on Zend Framework

Christopher Valderrama (GatorV), estimado colega mexicano (con el cual intercambiamos regularmente información desde hace años) ha liberado su toolbox basado en Zend Framework.


Como no podía ser menos, los fuentes se encuentran disponibles bajo licencia GPL ("Software Libre").

La lista de funcionalidades es importante y creo que todos requerimos alguna vez disponer de ellas:
  • MVC Router:
    • Template Rendering
    • Config System using Zend_Config
    • DB Singleton using Zend_Db
  • Quick DB Authentification module using Zend_Auth
  • Advanced HTML Form Generation
    • Form Decorators, Renderers and Templates
    • Basic Form Controls
    • Advanced Form Controls:
      • Ajax Dependant Selects
      • Date Picker Control
    • Advanced Form Validation using Zend_Validate
    • Auto Form creation via independent Builders
  • Advanced DataGrid Control
    • Auto Sorting
    • Pagination
    • Cell Renderers
    • Grid Formatters
    • Independent DataSources (can show grid from a XML, Array, DB, Zend_Db_Table, etc.)
  • Request Input Filtering (GET, POST, COOKIE)
    • Filter Plugins:
      • Strip HTML
      • Magic Quotes
      • XSS Filtering
      • HTML Special Chars
  • Template System
    • PHP Code in templates
    • Template Helpers
  • XML Generation
  • HTML Helpers, OO Interface for HTML tags
  • Security checking vs a Access List (Zend ACL)
  • Paginator capable of paginating any DataSource
  • URL Generation Module
Recién estoy bajando el proyecto y en las próximas semanas iré estudiando el código y entendiendo su funcionalidad. Muy probablemente en algún momento lo incorporemos a los proyectos de SURFORCE.

S
ugerencia: que de a poco le vayamos tirando ideas y dudas para que pueda ir armando la documentación inicial y que sea fácil empezar a conocer la herramienta. Obviamente todo quién pueda colaborar será bienvenido.

Este tipo de iniciativas deben servir de ejemplo, ya que "no solo de frameworks vive el desarrollador", también se requieren este tipo de proyectos, de más alto nivel.

En hora buena my friend

Presentación: "Buenas Prácticas de Desarrollo en PHP"

Hace un tiempo que vengo recomendando esta presentación como punto de partida para definir un estándar de desarrollo en una empresa. En ambientes Java no se discute quién define los estándares, es la empresa Sun y a nadie se le ocurriría inventar el suyo propio. Además, en el mundo Java existen estándares para todo, desde la codificación, forma de programar, etc.

Read this document on Scribd: php development best practices



En el lado opuesto del mundo estamos nosotros, los del "Mundo PHP", donde cada cual tiene su propio estándar y programa "como quiere" (con todos los problemas que esto acarrea). Para evitarlo, lo mejor que podemos hacer es seguir los lineamientos generales que se desprenden de los documentos de Zend.

Y esta es una buena presentación por donde empezar.

En lo personal, al principio, me costó usar la "llave inicial" de clases y métodos al mismo nivel que la "llave de cierre" (al estilo programación "C"), pero como bien dice este material:

"No eres tan especial como para crear tu propio estándar"


Así que me acostumbré. Mi consejo es: úsalo! y no pierdas el tiempo en definir cómo se hace tal o cual cosa, pierde el tiempo con "problemas nuevos".

Más material:

SURFORCE-CMS: solicitud de colaboración para hacer testing y refactoring

El proyecto SURFORCE-CMS está en su primera versión "madura" por decirlo de alguna manera (¿1.0?), pero quedan algunos pendientes que me preocupan:

  • El primero, hacer refactoring del código que genera el menú, ya que actualmente es "estructurado" y con mucho "hardcode" (fue uno de los primeros códigos que se implementaron cuando empezamos con el CMS, cuando no teníamos nada de experiencia en Zend).

  • Segundo, hacer el testing de la aplicación en general, reportando bugs para que los solucionemos. Por ejemplo, un colega me reportó que al crear un sub-sitio / sección (ABM Sitios) si no le ingresa la "url home" del mismo (la página por defecto) el sitio no arranca y da un error.

Hay muchos detalles como estos que están para resolver, así como ver qué partes no se entienden o no están del todo correctas (tanto funcionales como internas del código) y mejorarlas.

Cada quien encuentre un bug iré autorizando los permisos para que puedan subir el código al svn y pasar a la fama como parte del proyecto (bueno, por lo menos aparecerán en el listado del proyecto en Google Code ;-)

Espero comentarios al respecto.

Aún estamos lejos de Ruby On Rails... a pesar de Zend

Hace un par de años que escribí un artículo para una revista en donde documentaba mis primeras pruebas con Ruby On Rails, en concreto, la instalación y los primeros pasos. Posteriormente me ofrecieron hacer un artículo más profundo, pero la verdad que me quedé sin tiempo como para seguir investigando, ya que estaba más abocado a profundizar mis conocimientos en PHP (que nos falta mucho comparado con otras tecnologías).

Del poco tiempo que pude invertir puedo decir que me encontré que no es tan fácil como lo publicitan, no se hacen sitios tan fácilmente, o por lo menos, no es tan fácil aprender un nuevo lenguaje y un nuevo framework, ni tampoco es fácil cuando los requerimientos se complican (hay que evaluar los costos, todo tiene su costo).

Luego de pasar algunos años volví a hablar esta semana con algunos colegas sobre RoR y para dejarles un ejemplo bien gráfico les puse el video más famoso y marketinero que puede haber, al autor explicando cómo hacer un blog en 15 o menos minutos ;-)

La verdad que luego de no verlo por mucho tiempo me vuelvo a sentir tan sorprendido como la primera vez y ahora, luego de dos años y más experiencia acumulada en PHP + Zend, vuelvo a sacar la misma conclusión:

"Aún estamos lejos de Ruby On Rails" ;-)

Ya que, aunque Zend es la respuesta a la aparición de RoR, y hemos dado muy buenos pasos "estructurales", aún estamos lejos de la productividad que se ven en esos videos. Zend apunta a que tengamos los famosos "scaffolding" y hacer rápidamente ABMs (que tanto tiempo nos consumen).


Hay que destacar que los videos también pueden ser engañosos, ya que puedo entrenarme por una semana, usar el lenguaje que más domino, preparo un desarrollo en concreto (como un Blog) y luego puedo hacerlo y grabarlo de corrido y parecerá que con PHP + Zend todo es "soplar y hacer botellas".

Pero igual, a pesar de todo, aún nos faltan algunas cosas que RoR tiene y que necesitamos cuanto antes.

Así que sigamos adelante :-)

Empresariales: "Despidos en Zend ¿posible venta de la empresa?"


Me hago eco de la noticia comentada en Vivaphp:

"Zend Technologies, "la Compañía de PHP", despidió al 25% de su equipo de Investigación y Desarrollo (por lo menos 10 personas) y a otros a lo largo y ancho de la empresa, aparentemente, en un intento de recortar gastos. Aunque desde Zend declinaron cualquier comentario al respecto, el sitio TechCrunch cree que esta acción podría deberse a que la empresa israelí está ordenándose y haciéndose más atractiva para una potencial venta.

En el 2006, Oracle quiso comprar Zend por una cifra entre U$S 100 y 200 Millones, y quizás todavía pueda estar interesada. Otros probables compradores podrían ser IBM, que ya es un socio estratégico de Zend y hasta la mismísima Microsoft (!)."


Esto no significa necesariamente que le esté yendo mal a la empresa Zend, puede significar un crecimiento de la misma si esta es adquirida por una empresa mayor (pero por favor, que no sea Microsoft! ;-)).

Surforce-base: primera versión con Zend_Layout

Hacer un rato actualicé el repositorio svn del proyecto surforce-base con la inclusión del manejo de "layout" (diseño) provista por Zend_Layout. Anteriormente teníamos que en cada vista de todos los módulos de nuestro sistema incluir indefectiblemente el código para el cabezal en la parte superior y el pié en la parte inferior.

Algo así:

1  
<?php echo $this->render('header.phtml'); ?>
2  <?php 
echo $this->render('menu.phtml'); ?>
3  

4  <div id="noticias">
5  
6     Hola, son el index de Noticias, 
7     si quieres ingresar al admin debes ir a 
8     <a href="<?php echo $this->baseUrl ?>
9  
      /noticias/admin/">Admin</a>
10  </div>
11  
12  <?php echo $this->render('footer.phtml'); ?>



De ahora en más, simplemente hay que poner el contenido de la vista sin los renders de "header" ni "footer".

El detalle más importante de todo esto es que en el modelo anterior, si tuviéramos que cambiar la estructura base del sitio -por ejemplo- cambiar de lugar el cabezal, el pie, o agregar un menú, o cambiarlo de lado, hay que modificar todas las vistas para hacerlo.

De esta nueva forma todo el esqueleto del sitio se encuentra en el layout.phtml, ubicado al mismo nivel que el código del cabezal y el pie (/html/scripts) y contendrá el siguiente código:


1  
<?php echo $this->render('header.phtml'); ?>
2  <?php 
echo $this->render('menu.phtml'); ?>
3  

4  <?php echo $this->layout()->content; ?>
5  

6  <?php echo $this->render('footer.phtml'); ?>



Y lo único que hubo que agregar fue en el bootstrap (index.php) algo como esto:

1  
<?php
2  
3  
/**
4   * Zend_Layout
5   */
6  
define('APP_PATH', realpath('.'));
7  
8  
Zend_Layout::startMvc(array(
9      
'layoutPath' => APP_PATH . '/html/scripts'
10  
));
11  
12  
$view = Zend_Layout::getMvcInstance()->getView();
13  
?> 
14  



Y listo, luego hay que sacar en todos los módulos las referencias al cabezal y pie para que este no se repita, ya que quedó definido en el "layout".

Más información en el proyecto en el cual pueden bajar sus fuentes y probarlo, y hasta ver las diferencias consultando el log del SVN.

Fuente: Introduction to Zend_Layout (updated for ZF 1.5!)

Actualización (24/04/2008):

Zend: "¡¿donde está mi helper?! ¡¿cómo lo llamo?!"

Estuve un rato teniendo problemas con un helper que había creado y que lo colocaba en el -supuesto- lugar que debía estar y la vista que lo usaba no lo encontraba.

Nota: aviso, "todo", está en el manual, lamentablemente (así que hay que leerlo ;-) )

En la sección sobre "Zend_View", en particular el punto "42.1.4. Utility Accessors", fue bastante revelador, ya que nos da las herramientas para comprender cómo el sistema registra los nombres y las ubicaciones de los helpers y poder revisar si estamos cometiendo algún error de sintaxis o de conceptos.

Aquí algunos métodos que podemos usar desde una vista:

  • getScriptPath($script): nos retorna el camino a partir del nombre de un scripts

  • getScriptPaths(): nos retorna todos los caminos de los scripts registrados.

  • getHelperPath($helper): el camino de un helper dado a partir del nombre de la clase

  • getHelperPaths(): todas las rutas registradas para los helpers


Estos métodos nos permiten hacer un "debug" de nuestro sistema y ver donde nuestro MVC encuentra o debería encontrar los helpers, muy útil para controlar que estemos haciendo las cosas bien.

Estando dentro de la vista podemos hacer

1  
<?php 
2  
3  var_dump
(  $this->getHelperPaths() );
4  
5  
?> 
6  



Y nos tira la lista de rutas que tiene definido para buscar los helpers

1  
<?php 
2  
3  
array(4) {
4    [
0]=>
5    array(
2) {
6      [
"prefix"]=>
7      
string(7) "Helper_"
8      
["dir"]=>
9  
10      
string(32) ".\library\Zsurforce\View\Helper\"
11    }
12    [1]=>
13    array(2) {
14      ["
prefix"]=>
15      string(8) "
_Helper_"
16      ["
dir"]=>
17      string(15) "
.htmlhelpers"
18  
19    }
20    [2]=>
21    array(2) {
22      ["
prefix"]=>
23      string(25) "
Estadisticas_View_Helper_"
24      ["
dir"]=>
25      string(41) "
.application\estadisticas\views\helpers"
26  
27    }
28    [3]=>
29    array(2) {
30      ["
prefix"]=>
31      string(17) "
Zend_View_Helper_"
32      ["
dir"]=>
33      string(57) "
C:\xampp\htdocs\admin\library\Zend\View\Helper"
34  
35    }
36  }
37  
38  ?> 



Varias deducciones interesantes:

  • Que está por defecto buscando en "html\helpers" (algo que no sabía)

  • Que no hace falta decirle dentro de la vista correspondiente donde buscar sus helpers, ya que lo hace solo: \application\estadisticas\views\helpers\ (yo estoy probando dentro de la vista del módulo estadísticas)

  • No veo la ruta hacia los helpers de surforce-library

Tomando en cuenta esto último, agregué en el init del controller genérico de surforce-library:

1  
<?php
2  $this
->view->addHelperPath('./library/Zsurforce/View/Helper/', 
'Helper');
3  
?>



Si volvemos a ejecutar la vista, ahora nos dice:

1  
<?php 
2  
3  
array(4) {
4    [
0]=>
5    array(
2) {
6      [
"prefix"]=>
7      
string(7) "Helper_"
8      
["dir"]=>
9  
10      
string(32) ".\library\Zsurforce\View\Helper\"
11    }
12    [1]=>
13    array(2) {
14      ["
prefix"]=>
15      string(8) "
_Helper_"
16      ["
dir"]=>
17      string(15) "
.htmlhelpers"
18  
19    }
20    [2]=>
21    array(2) {
22      ["
prefix"]=>
23      string(25) "
Estadisticas_View_Helper_"
24      ["
dir"]=>
25      string(41) "
.application\estadisticas\views\helpers"
26  
27    }
28    [3]=>
29    array(2) {
30      ["
prefix"]=>
31      string(17) "
Zend_View_Helper_"
32      ["
dir"]=>
33      string(57) "
C:\xampp\htdocs\admin\library\Zend\View\Helper"
34  
35    }
36  }
37  ?> 




Ya aparece la ruta hacia los helpers de surforce-library.

Otra cosa interesante, que ya me permitió corregir varios problemas al definir los helpers fue el nombre de los mismos con la ruta para encontrarlos. En algunos casos había creado una clase Helper con solo el nombre de la clase y en otra con el nombre con la ruta completa para ubicarlos, pero en varios estaban mal. Si vemos el array, uno de los elementos es "prefix" y justamente, es el nombre "prefijo" que debería tener la clase de nuestro helper ;-)

Por ejemplo, si nuestro helper está en el módulo estadísticas, debemos llamarlo:

class Estadisticas_View_Helper_GoogleChart

Pero si está en surforce library solo "Helper"

class Helper_GoogleChart

¿Interesante dato, no?

Nota: al final cambié el nombre del prefijo de solo "Helper" al que debería corresponder de acuerdo a la ubicación dentro de la estructura de directorios de Zend, así que la clase pasaría a llamarse Zsurforce_View_Helper_GoogleChart.

Esta es la línea que lo define en el init() del controller:

1  
<?php 
2  
3  $this
->view->addHelperPath('./library/Zsurforce/View/Helper/', 
'Zsurforce_View_Helper');
4  
5  
?> 



Por último, estaba probando el método "getHelperPath" que nos dice donde está ubicado el helper que consultamos, y en todos los casos anteriores no daba información, pero cuando arreglé las rutas, ya devolvía la información correcta.

1  
<?php
2  
echo $this->getHelperPath('googleChart');
3  
?> 



Creo que con esta explicación ahora queda un poco más claro cómo encontrarlos. ;-)

¡Zend Framework 1.5 Final disponible!


Ya está disponible la versión final de Zend Framework 1.5, así que es hora de empezar a usar Zend_Layout, Zend_Form, Ajax, etc.

PD: lindo rediseño del sitio web ;-)

¡Primera versión de surforce-base disponible!

La idea de este proyecto es poder contar con una estructura base para construir proyectos usando el framework Zend. De la mano vienen detrás dos proyectos más que son surforce-modules y surforce-library, buscando centralizar todo lo posible e incrementar el reuso de código.

Esta es la primera versión de surforce-base, todavía tiene algunos detalles que iré mejorando en los próximos días, pero es completamente funcional ;-)

Contempla todo lo que vengo hablando hace bastante tiempo en los foros de los proyectos: poder tener módulos independientes que contengan dentro de su estructura todos sus elementos, es decir, sus controladores, modelos y vistas (todo se origina a partir del patrón de diseño MVC).

Me basé en la estructura que arma ZendStudio a partir de su wizard, le ajusté algunos detalles y le agregué el soporte para leer el config.ini y un modelo para poder a su vez conectarse a la base de datos (la estructura de datos es la misma de surforce-cms).

Para instalarlo solo hay que bajarse del svn los fuentes de surforce-base y luego en el directorio library bajar tambien de su svn el framework Zend (solo copiar la carpeta Zend que está en el directorio library del repositorio del framework).

Actualmente si lo probamos, funciona de la siguiente forma:

http://localhost/surforce-base

Responde el controller por defecto que se encuentra en:

application/default

Si ejecutamos un módulo, como noticias:

http://localhost/surforce-base/noticias/

Y esto sigue los siguientes pasos:
  1. usa el controller por defecto del módulo noticias

    /application/noticias/controllers/IndexController.php

  2. pasa a la vista (según el action por defecto)

    /application/noticias/views/scripts/index/index.phtml

  3. como requiere datos, se los pide al modelo

    /application/noticias/models/Noticias.php
Nota: el subdirectorio index de la estructura para la vista corresponde al nombre del controller, no del action, el action es representado por el archivo index.phtml (todo es un tema de convenciones de nombres).

Creo que a partir de ahora se puede estructurar en un repositorio centralizado todos los módulos que puedan ser reusados (noticias, usuarios, etc), y a partir de una estructura base ordenada poder empezar a desarrollar cualquier proyecto.

Los fuentes listos para bajarlos y usarlos

http://code.google.com/p/surforce-base/

También puedes suscribirte al foro para darme una mano.

Si me da el tiempo, ya empiezo a subir módulos básicos en el otro proyecto que se complementa con el anterior:

http://code.google.com/p/surforce-modules/

Y en cascada vendrá luego una librería

http://code.google.com/p/surforce-library/


Documentación
http://framework.zend.com/manual/en/zend.controller.modular.html

Bien, a desarrollar con Zend se ha dicho ;-)

Dos nuevos sub-proyectos: surforce-modules y surforce-library

Este tema lo vengo repitiendo bastante en todos los ámbitos donde me muevo y existe desarrollo PHP + Zend: antes de empezar a desarrollar un proyecto es muy importante saber cómo vamos a reutilizar conocimientos y evitar reinventar la rueda.

Es muy importante definir primero la "arquitectura", adoptarla durante toda la vida del mismo, y al final, poder evaluar los pro y contras para decidir en el próximo proyecto qué herramienta se mantiene o cual se cambia por otra.

Una vez que logremos estabilizarnos, podremos seguir acumulando conocimientos, herramientas, módulos, librerías, código... entre proyectos, evitando tener que reescribir una y otra vez -por ejemplo- un aburrido sistema de noticias, algo que perfectamente podría reusarse entre proyectos, y cualquier mejora, mejoraría a todos los demás proyectos (tu empresa / organización debería tener su propio "framework").

Siguiendo esa filosofía es que abro dos proyectos libres más:
  • surforce-modules para nuclear módulos típicos que puede necesitar cualquier sistema
  • surforce-library, de la misma forma que existe la librería Zend que da soporte a nuestra aplicación, podremos tener una librería que haga uso de Zend pero que incorpore funcionalidades más concretas y que a su vez, sean proclives a reusarse.
Ya lo estamos viviendo con todos los proyectos de surforce, hay muchas funcionalidades que se repiten una y otra vez, en el primer lugar que se desarrollan tienen una versión "borrador" y en el último una versión más terminada.

No importa si el proyecto que participes es abierto o cerrado, no hay duda, liberando estas partes de nuestros desarrollos todos saldremos beneficiados.

¡Contribuye a evitar reinventar la rueda! ;-)

Nuevo proyecto: "surforce-social"


Bien, lanzamos nuevo proyecto y este estará relacionado con las redes sociales de contactos, tan en auge en este momento entre las empresas del rubro "web". Nuestro proyecto comunitario inicial fue suforce-cms, que aunque su desarrollo sigue lento y la participación de los colaboradores es muy esporádica, se mantiene activo y se está usando como base para otros proyectos que necesiten de una estructura inicial para proveer un servicio de tipo CMS y a su vez para empezar a desarrollar con Zend Framework (evitando involucrase en estructuras extremadamente complejas como puede ser Joomla, Drupal o Mambo).

En este caso, tomaremos otro tema para este proyecto, y son la redes sociales. Conozco a muchas empresas que quieren o están embarcadas en proyectos de desarrollo de este tipo de productos (algunas hasta han recibido millones de dólares en inversión), y no son pocas las veces que me han pedido para desarrollar un producto con estas características. Así qué mejor para acaparar la atención de los desarrolladores que involucrarnos en un tema tan interesante como este ;-)

Pablo Morales, un colega uruguayo que está trabajando en Argentina, nos dará una mano con el proyecto: él será el teamleader del mismo y yo lo apoyaré desde el rol de project manager. Se tocarán muchos temas interesantes, como el hecho de desarrollar toda la comunicación interna del mismo entre los usuarios y a su vez la posibilidad de hacer chat entre ellos. Por consiguiente, mucha interfaz, mucho Ajax ;-)

Los últimos meses he venido investigado "desde dentro" varios sistemas, conociendo fortalezas y debilidades. Entre ellos puedo destacar a neurona, xing, wamba, badoo y recientemente contakme. En lo personal, no los veo extremadamente complejos (tampoco soy un experto en el desarrollo de este tipo de sistemas), y a muchos de ellos les faltan muchas funcionalidades que considero básicas, o que directamente tiene uno pero que falta en el otro, y que juntos se complementarían.

Veremos cómo nos va, desde ya están todos invitados a participar, y espero que el tema interese. Estaremos estos días definiendo la estructura y la arquitectura base para trabajar.

PD: ¿cómo nos va a ir? Ni idea, pero espero que aprendamos algo en el camino, como nos pasó con el primero ;-)

Entradas populares