En la actual empresa en la que estoy trabajando, tenemos cerca de una treintena de proyectos activos, si para cada uno tuviesemos que seguir estas estructuras se volvería todo un caos. Aqui, en cambio, usamos una estructura inversa. Definiendo tan solo tres directorios de las que depende todo:

• Public
• Private
• Config

Y cuando realizamos un nuevo desarrollo introducimos la abreviatura única en las tres carpetas. Por ejemplo si tuviesemos una nueva aplicación de comercio online ((Es tan solo un ejemplo.)) y decidimos titularla “compras” introduciríamos en los tres directorios el correspondiente subdirectorio

• Public.
  • compras
• Private.
  • compras
• Config.
  • compras

A simple vista puede parecer más lioso, pero una vez empiezas a usarlo ves las ventajas. Ya que todo tiene la misma estructura, todo es accesible de una forma sencilla, la administración no se hace tan incontrolable y sobretodo consigues separar la parte pública de la privada, fundamental en servidores cara a internet.

Otra de las adaptaciones que he realizado viene por necesidad. En el servidor donde está alojado mi dominio usan cPanel ((No se si en otros lados será igual)), y la forma de crear subdominios es creando los subdirectorios directamente en public_html ((Siendo accesibles como sudominio.dominio.com o dominio.com/subdomino))

Bueno, pues visto lo visto e aquí mi adaptación:

Como se puede ver el screenshot está sacado del EasyEclipse ((Copiando metodología de desarrollo de Enrique Place)), Y está basado en el desarrollo del Proyecto01 del que ya hablamos.

Para todo el proyecto usaremos el nombre “afm” que es un acrónimo del site.

• config->afm: En este directorio añadimos la configuración base del site.
• library: En library añadimos el framework de Zend y el resto de librerías externas que podamos ir necesitando para el desarrollo ((Como por ejemplo HTML Purifier, Blueprint o cualquier otra aplicación externa))
• private->afm: En este subdirectorio incluimos toda la parte privada de la aplicación.
  • admin y default: Lo primero que vemos son los módulos; en este caso solo “admin” y “default” ((Para mantener más la integridad de la estructura, el módulo “default” tambien lo incluyo como subdirectorio)). En cada módulo incluyo la “subestructura base” típica:
    • controllers: Aquí guardamos los “controladores” del módulo. Usando la forma de trabajar, MVC, del framework de Zend podemos poner las vistas en el directorio “views” a la misma altura ((Aunque como todo en ZF siempre puedes configurarlo a tu gusto)) que “controllers“.
    • views: Aquí incluimos los subdirectorios necesarios para toda la parte de la “vista” (”filters“, “helpers“, “scripts“, “layouts“,…).
  • models: Esta es la zona donde se guardan todos los “modelos” necesarios para el site.
• public_html: De aquí colgará toda la parte publica de la web ((Siguiendo la estructura “impuesta” por el cPanel el directorio “public_html/” alberga el site principal y cualquier subdominio cuelga como subdirectorio de “public_html/“)). En este caso el subdominio se llamará, para mantener la integridad claro, “afm“.
  • public_html->afm: La información aquí suele ser básica, el “.htaccess” que redirige toda la información a “index.php” y el propio “index.php“. Aqui también irán todas los posibles directorios con la información pública: estilos, imágenes, javascripts…

Como se puede ver la estructura es fácilmente adaptable para incorporar nuevos sites, para reutilizar posible código y para tener una librería única en la que incluir el framework, a parte, claro de la necesidad de separar la parte de privada de la parte pública del site.

Con respecto a la forma de trabajar de una estructura “habitual” la única diferencia radica en el “index.php” y en el “Bootstrap.php” que deben tener en cuenta el “salto de un directorio más“. Pero, como por ahora estoy puliendo mi “Bootstrap.php” ((Basandome en el usado por Pádraic Brady para el desarrollo de su Blog con Zend Framework)) (el “index.php” ya tiene una versión “estable“) lo dejaré para el siguiente post…

Pero si tenéis alguna duda, o no os gusta, o tenéis alguna sugerencia, no lo dudes, más abajo tenéis los comentarios!

Recently, Binary Ant Punto Es, a blog from my Seo’s list, closed its doors. Really I should say, that he changed his write rhythm only. And now, Binary Ant Punto Es only has a few post monthly.

Why he “semi-closed” his blog? Simple, he tried to do more than he could do. He tried to do the next step from a blogger and become a English’s written blogger.

It’s a great idea, i think, but the problems become at first. One blog and two languages or one blog for each language? And then, born Binary Ant Dot Com. With two blogs to admin. A Twitter account for each language. Have to translate every post… So many work.

Finally, this was unsustainable, and the solution; stop to write in Spanish… Only English version available.

I think this is a better idea. This will help his English and put in another league, another higher league.

Now, I think. Why discard Spanish blog?? I accept that have a blog is quite complicated as to have two. Two twitter is “stupid” (without offending), but why do I need two blogs?

As you can see, my blog will be described as a “great black box” in which I keep all kind of things, personal, design, seo, programming… Why don’t add English posts?? Why can’t coexist both languages?

Yes, I know that is better for SEO separate niche information in different sites. But I think that, for this, now exists the categories and tags. If a person only want to see Zend information and arrive at this blog, he only has to click at the Zend category (or subscribe to their feed), and then he only see Zend information. And, in the other side, there are a person who enters in my blog.

IMHO, if you collect all the information in one place, you can congregate a great number of visits and having located the site for several keywords.

And, why will not be equal to the languages? If you can configure your blog for use with two languages (At this time, I don’t know any plugin that could do this). Why don’t you have a multilingual blog??

Well, In honor to Binary Ant Dot Com, I will try to do this… I will try to do a multilingual blog…

For last, what do you think about this? What would you do??

Lo siento, pero como programador, Wordpress me parece malo. Muy malo. Pero lo peor de todo es que tiene cosas excesivamente buenas. Muy, muy buenas.

A día de hoy, no entiendo como WP se ha hecho con el mercado mundial de sistemas de blogs. Puedo entender que se desarrollase en principio de forma procedural, pero un blog adaptado a PHP5 nunca debería seguir siendolo!.

Señores PROCEDURAL a muerto, YA SOLO EXISTE OOP.

Una vez decidí dar el paso y congelar el desarrollo de mi blog para usar wordpres, una vez instalado , intento sacarle el potencial, adaptar algunas cositas que no me gustan, ver el asunto de los templates… Y me doy de bruces, una y otra vez, con errores de programación básicos; Cosas tan simples como el de incorporar “echos” en las funciones. Funciones demasiado estáticas y poco modulares. Vueltas y más vueltas en el diseño. Estructuras obsoletas (desde cuando es accesible via web el kernel de una aplicación?).

Pero claro, todo no es malo, ni mucho menos!

Que cosas buenas tiene, que por algo decidí quitar mi blog y traer este al mundo. Es cierto que la parte de administración es mucho más que completa, cómoda e intuitiva. Que los plugins dan mucho juego y Akismet principalmente mucho más (que mi blog es un nido de spam!).

Pero no me gusta. Es cómodo escribir aquí, y por eso seguirá, durante un tiempo, siendo mi blog. Pero no me gusta. Trataré de acabar el template que estoy desarrollando para que se parezca más a lo que ya tenía. Pero no me gusta.

Y como lo fácil es quejarse y seguir, y a mi no me gusta lo fácil. Prometo traer mi blog de nuevo, hacerle un refactoring completo para adaptarlo al mundo de Zend Framework, intentaré copiar (si, copiar, que para algo es Software Libre) lo que más me gusta de Wordpress, vamos, toda la parte de administración.

Y si esto no fuese poco, intentaré lo más complicado… Y ya que se de diseño de patrones, porque lo dice un título que todavía no tengo, pues intentaré crear un patrón llamado Wrapper, para poder adoptar bajo el blog todos los plugins creados para WP (Si es que algún día llego a terminar el desarrollo del blog!).

Así que ahora mismo en mente tengo una larga serie de desarrollos:

• Desarrollar tres minisites (aunque por ahora solo uno es seguro que haga) donde aprenda el uso básico de ZF. Sencillos y sin muchas complicaciones.
• Desarrollo de dos (uno de ellos será principalmente refactoring), mayor ideas propias bastante suculentas… Espero que me saquen de pobre! :-p
• Desarrollo de tres microsites de shopping… Espero que me den más dinerito todavía!!
• Refactoring y desarrollo del blog
• Y como todo esto es poco, pues ya me apunte al mundo de SURFORCE, con su surforce-cms.

Alguien da más??

PS: Y sip, iré contando por aquí todos los desarrollos paso a paso.

Quieres empezar con él, o saber más de él.

Bueno, tenía intención de contar un poco de ZF, pero

• No tengo conocimientos suficientes para hacer algo que realmente valga la pena.
• Hay bastante buena información al respecto en español[1]. Aunque, eso si, más allá de contarte que es ZF poca información buena encontrarás en la lengua de cervantes, todo en un perfecto ingles!

Así que directamente pasaré a la parte b), crear el primer site:

PROYECTO01 - AFM

PLANIFICACION

El site en principio va a ser casi_estático, ya que supongo que una vez lo entrege prácticamente no se usará ;-). Aun así, quiero desarrollar algo que sea bastante modular y fácil de ampliar. La idea principal es un site donde las subsecciones sean ampliables y la información de esta editable.

La idea es crear el tipico frontal con secciones y subsecciones (solo dos niveles, ya que no creo que “el cliente” vaya a necesitar más). La forma más fácil de desarrollarlo será crear una lista de secciones y una lista de subsecciones. Y para optimizarlo, las secciones no contendrán información, sino que serán las subsecciones las encargadas de contener toda la información. Tendremos la opción de marcar una subseccion como “default”, siendo la marcada la que se muestre por defecto en su respectiva seccion.

A priori necesitaría una lógica de navegación, una administración de usuarios y roles, y una base de datos que respalde toda la información.

La lógica de navegación es simple:

• El portal inicial tendrá un listado de secciones
• Al entrar en cada sección se motrará la subseccion activa.
• En caso de que haya más de una subsección se desplegará el listado de subsecciones en el navegador.

Nada especialmente difícil. Como ya he dicho en principio no se necesitarían más subniveles en la aplicación, facilitando bastante el desarrollo al no tener que hacer esto de forma dinámica.

Los roles definen el alcance de cada usuario. Al poder, los usuarios, introducir la información en la aplicación, esta deberá contar con una sería de roles. En principio solo usaré tres roles básicos:

• guest/default: El rol por defecto del visitante. Podrá navegar por el site, pero nunca podrá editar la información.
• writer: Solo podrá hacer modificaciones en las secciones ya creadas, vamos un editor.
• admin: Podrá crear nuevas secciones, además de escribir en ellas.

Una duda que tengo es el alta de usuarios nuevos. En caso de poder hacerse, solo sería admin quien podría ya que es una aplicación privada. Pero no se hasta que punto será útil crearlo, teniendo en cuenta el poco uso que se le dará al alta/baja de usuarios. Dependerá sobretodo de la (mi) facilidad de desarrollo con ZF

Lógicamente la parte de administración tendrá su própia lógica de navegación:

• Logeo
• Modificación de la información de las subsecciones (recordamos que las secciones, por si mismas, no contendrán la información).
• Gestión (añadir, borrar) de Secciones y subsecciones.
• Gestión (añadir, borrar) de usuarios.
• Deslogeo

Como el portal es bastante pequeño y simple, toda la estructura de la base de datos es bastante sencilla. Contendrá la información relativa a la navegación y la relativa a la administración de usarios y roles.

Para la navegación se crearán dos tablas:

• afm_section: Que tan solo contendrá el nombre de la sección, “section_name” y el id correspondiente “section_id”
• afm_subsection: Esta tabla contendrá toda la chicha del portal y tan solo contará con 6 campos.
  “subsection_id”, “subsection_name”, “subsection_content”, “subsection_hasDefault”, “subsection_section_id” y “subsection_modify” que contendrá el user y la fecha de la última modificación.

Y la parte de lógin tendrá sus dos tablas correspondientes:

• afm_roles: Que contendrá la información relativa a los roles de acceso (luego veremos mejor como juntar esto con Zend_ACL. Contendrá tres campos “roles_id”, “roles_name”, “roles_roles_id”. En “roles_roles_id” indicaremos los roles que puede contener el rol indicado. Por ejemplo todo “Admin” será “Guest” y “Writer”.
• afm_users: Los usuarios no necesitarán excesiva información; “user_id”, “user_name”, “user_realname”, “user_password”, “user_mail”, “user_roles_id”.

Y con esto y un bizcocho, el planteamiento base ya está realizado! Está claro que hay más cosas en mente. Como el posible diseño, opciones especiales de navegación, posibles extensiones y demás. Pero creo que por ahora, ni es necesario explicarlo todo detalladamente, ni me interesa, ni sabría como escribirlo. A parte de que al hacerlo así, siempre podré extenderlo en mayor o menor media.

PRIMER PASO: CODE.GOOGLE

Ahora que ya tenemos el planteamiento, vamos a crear un nuevo proyecto en code.google. Esta nueva implementación de google la conocí hace relativamente poco (gracias a que es ahí donde se aloja Surfoce-CMS). Poco a poco iré explotando más estas nuevas opciones de google, pero por ahora simplemente lo uso para guardar mi repositorio del proyecto. Que pena que mi hosting no acepte SVN.

La url del repositorio es: http://code.google.com/p/g05l21-project01/

Por ahora no es que le haya metido mucha información o texto, pero vamos, ni siquiera lo he hecho aquí en el blog…

Ya iré ampliando la información allí y poniendo más cositas por aquí!

[1]: Y un claro ejemplo está en ZF: Estado del arte. En Abril del 2008 sacó una buena colección de post relativos a ZF.

Solo una cosa. Intentaré hacer tres desarrollos distintos, para tres personas que en un caso me lo pidieron, en otro se lo ofrecí yo y en el último no tienen ni idea de que su sobrino “sea capaz de hacer eso en internes”.

Espero que alguno de los tres acabe usando los desarrollos.

Bueno, para el desarrollo inicial, para empezar a zambullirnos en ZF. Lo primero es recabar información. Así que aquí una ristra de enlaces para poder empezar (y para no olvidarlos yo)

http://framework.zend.com/ donde todo da comienzo. Sobretodo te será útil la zona de documentación y API.

http://phpsenior.blogspot.com/ El blog técnico de Enrique Place. de obligada referencia para ver de cerca el mundo del desarrollador senior, de Php5, de patrones de diseño, de desarrollos en zend…

http://blog.astrumfutura.com/ Blog donde te enseñan a desarrollar un blog en ZF desde 0, muy bueno, pero que muy bueno.

http://www.zfforum.es/ Los foros de ZF en lengua castellana. La verdad es que no tienen mucha actividad todavía, así que poco podrás ver en ellos. Pero siempre podrás preguntar.

http://www.forosdelweb.com/ El foro por excelencia. Donde encontrarás de todo lo relacionado con el mundillo del desarrollo web. Pero sobretodo mucha información sobre PHP5 orientado a objetos. A parte de poder encontrarte a un omnipresente enriqueplace.

Y otros buenos blogs con ejemplos y mucha info:

http://bolsadeideas.cl/zsamer/

http://zendhispano.blogspot.com/

Con todo esto, más algún que otro manualito que me he bajado y leido… Y que creo que no merece ser nombrado en exceso, jeje, empezaremos con ZF

PS: Está claro que si alguien quiere, estaría encantado de escuchar nuevos desarrollos y llegar a acuerdos para realizarlos

Y encima, hacerlo de la mano de los más grandes en esto de PHP (que para algo son los padres del cotarro) los señores de ZEND y su framework. ZendFramework.

Por qué ZendFramework y no otros? Bueno, en principio, si lo comparamos con Symfony creo que ZF sale un poco en desventaja, digamos que tiene pequeñas deficiencias que otros ya han solventado hace tiempo.

Pero, también es cierto, que mientras otros juegan con el tiempo pasado a favor, ZF juega con el tiempo futuro a su favor, ya que actualmente el desarrollo es muy grande y el respaldo por parte de Zend lo hace no un framework más…

Bueno, y otra de las grandes razones es por mimetismo. Se que mucha gente usa Symfony, otros usan Smarty o CakePhp… Pero a la persona que más me interesaría mimetizarme. El blog del que cada día más se puede aprender es el de PHPSenior.

Enrique Place, uruguayo con un currículo a sus espaldas impresionante, está completamente decidido por ZF, y así lo demuestra realizando un gran CMS basado solo en clases, pensado para PHP5 y desarrollado con ZendFramework. Surforce CMS

Está todavía en un estado todavía muy básico (recién sacada la versión 1.0?), y cualquier mano que se le pueda echar siempre será bienvenida, desde testing hasta desarollo y corrección de errores. Si le quieres ayudar: http://phpsenior.blogspot.com/2008/05/surforce-cms-solicitud-de-colaboracin.html

Así que aquí estoy. Empezando con un lenguaje “nuevo” y con un framework nuevo para mi.

Y como bien suponéis aquí iré poniendo todo lo que vaya desarrollando y como lo voy a ir haciendo. Por si alguno quiere empezar a desarrollar en PHP5.