Para quien pueda resultar de utilidad: Humm PHP framework

[dec]

Hola,

Gracias Julián, aunque, no creo que sea para tanto.

He añadido una nueva sección al sitio web de Humm:

http://hummphp.com/?cases

Ahí puede verse otro sitio web que usa Humm:

http://neoplugins.com/

Lo he hecho durante el día de hoy. Es cierto que la mayoría de contenido e imágenes estaban ya disponibles en NeoPlugins v1.0, pero, el sitio web (sobre todo internamente) ha quedado mucho más recogido. Mucho más limpio el espacio del servidor. En fin, ahí queda por si queréis echar un vistazo.

Je je je... ¡gracias otra vez Julián!

[Casimiro Notevi]

Dec, en mi próxima reencarnación quiero saber tanto como tú

[dec]

Empezado por Casimiro Notevi

Dec, en mi próxima reencarnación quiero saber tanto como tú

Huy,... ten cuidado con lo que deseas... ¡no vaya a hacerse realidad!

[dec]

Hola a todos,

¿Preparados para la siguiente versión de Humm PHP? Después de un tiempo dándole vueltas y de tres o cuatro días picando código bonitamente, os adelanto que pronto estará disponible la versión 2.0 de Humm PHP, escrita casi por completo desde cero, con un montón de mejoras sobre las versiones 1.x.

Humm PHP me ha dado dado muy buenos resultados en lo personal. Es el framework que utilizo en todos mis sitios web y en algún que otro proyecto "de terceros". Así que el compromiso por la sencillez y funcionalidad se mantienen en Humm 2.0, si bien contará con novedades interesantes.

/---------------------------------/

Todavía queda cierto tiempo para que publique esta nueva versión de Humm, pero, he aquí las mejoras ya incluidas respecto de Humm 1.x.:

* Olvidándome del estúpido "acortamiento" en los nombres de las clases y otros archivos e identificadores de Humm, ahora se contará con mejores y más descriptivos nombres de clases e identificadores, por ejemplo.

* No ha sido difícil (sólo dar vueltas alrededor) darse cuenta de cómo solucionar el "problema" que Humm tenía con los formularios "GET". En la versión 2.0 y siguientes no habrá problemas en usar estos formularios.

* Los diferentes tipos de bases de datos soportados por Humm (y que permiten traducir consultas SQL específicas para cada "driver") se encuentran ahora situados fuera del sistema, para que sea el usuario quien los use de ser necesario.

/---------------------------------/

En cuanto a las novedades que incluirá Humm 2.0 y que no se incluyen en versiones anteriores se trata de:

* Soporte para plugins, tanto de usuario como de sistema, con una serie de filtros y acciones a las que dichos plugins podrán reaccionar y actuar en consecuencia.

* Control internos de errores de PHP, de manera que se mostrarán o no dependiendo de la configuración de Humm, mostrándose convenientemente en caso necesario.

/---------------------------------/

En cualquier caso conviene recordar las principales características de Humm PHP:

* No necesita de instalación alguna en el servidor
* No necesita configuración en absoluto para funcionar
* Conexión automática con bases de datos (con sólo indicarlo)
* Clases prácticas y útiles como Database: listas para usar
* Usa URLs amigables al usuario sin utilizar modules "rewrite"
* Basado en vistas/plantillas HTML/PHP sencillas y potentes
* Completo soporte para la internacionalización de los sitios
* Algunas características básicas para la localización de sitios

/---------------------------------/

Para terminar una de las novedades con las que me gustaría en la siguiente versión de Humm sería el soporte para múltiples dominios usando la misma "instalación", mejor dicho, usando una sóla copia de Humm. Todavía no tengo claro cómo llevar a cabo esto, y, se agradecería cualquier comentario al respecto. Tengo más o menos claro que hay que trabajar con el nombre del "host", pero, esto en lo que se refiere a Humm: todavía no me queda claro cómo un usuario "llegaría" desde diferentes dominios a un mismo lugar... ¿redirecciones PHP? ¿configuración del servidor? ¿...?

En fin... no creo que Humm PHP le interese a mucha gente aparte de mí mismo, pero, supongo que escribo esto un poco para mí también, a modo de desahogo de tanto picar código y pensar en el proyecto trabajando en el mismo. Vaya, que así me distraigo un poco. Y quién sabe: quizás alguno de vosotros quiera hacer comentarios al respecto. ¿Verdad que sí?

¡Disculpad por el rollazo!

[Casimiro Notevi]

Suena muy bien, se ve que es una de tus "niñas mimadas"

[dec]

Hola,

Empezado por Casimiro Notevi

Suena muy bien, se ve que es una de tus "niñas mimadas"

Sí; je je je. Humm PHP vendría a ser una especia de plantilla para cualquier página web. Bueno... más o menos. Al menos yo lo uso en todos mis sitios, como ya he dicho, y, mi intención es poder seguir haciéndolo en el futuro en dichos sitios y en otros que pudieran venir. Desde un sitio que requiera únicamente una página a otro más o menos complejo, se trata de tener algo con lo que partir para no tener que reinventar la rueda una y otra vez.

Sigo trabajando, aunque ya es tarde. Y, por otro lado, parece que he entrado en una fase de añadir "cosas"... que no me gusta nada. Por ejemplo, traigo entre mientes añadir una especie de "administrador" a Humm. Ahora bien, esto parece contradecir una de las ideas fundamentales del proyecto: como básicamente se trata de editar archivos, creo yo que ningún "administrador" podrá llegar a la altura de programas como NetBeans for PHP, por ejemplo.

Y lo dicho para la edición de archivos puede servir para cualquier otra cosa. ¿El supuesto administrador debería de soportar la subida de imágenes? ¿Pero cómo demonios voy a lograr yo un administrador a la altura del estupendo FileZilla para subir y bajar y en definitiva trabajar con archivos en el servidor? ¿Y qué hay de un editor de imágenes? No hay "administrador" que se precie sin uno de ellos. Pero lo cierto es que tampo hay nada como tu editor de imágenes favorito.

En definitiva, que el administrador puede estar bien, puesto que, en algún caso, en un momento dado, quizás, podría uno necesitar editar un determinado archivo/plantilla... pero la complejidad que se añade al proyecto tal vez no merezca en absoluto la pena: en ninguno de mis sitios web (gestionados con Humm) he necesitado de administrador integrado alguno. Claro que tampoco necesito siquiera una base de datos... pero hay alguno más o menos "complejo".

En definitiva: la idea del administrador no parece buena, por mucho que me ronde por la cabeza. Añade complejidad, y, por otro lado, si alguien necesita alguna especie de administrador siempre podrá implementarlo él mismo partiendo de la base que proporciona Humm: de hecho yo mismo tendría que hacerlo (ya he hecho pruebas) así. En fin, supongo que con la fiebre del trabajo se le olvidan a uno las premisas fundamentales del proyecto, que conviene seguir para no convertirlo en otra cosa.

Bueno... no me enrrollo más, ¡que mira que estoy parlanchín!

[marcoszorrilla]

Enhorabuena David, como siempre un estupendo trabajo.

Un Saludo.

[dec]

Hola,

Empezado por marcoszorrilla

Enhorabuena David, como siempre un estupendo trabajo.

Un Saludo.

Gracias Marcos.

[roman]

Empezado por dec

* Olvidándome del estúpido "acortamiento" en los nombres de las clases y otros archivos e identificadores de Humm, ahora se contará con mejores y más descriptivos nombres de clases e identificadores, por ejemplo.

* No ha sido difícil (sólo dar vueltas alrededor) darse cuenta de cómo solucionar el "problema" que Humm tenía con los formularios "GET". En la versión 2.0 y siguientes no habrá problemas en usar estos formularios.

Hola dec, ¡qué bueno que sigas trabajando en ello!

¿Humm cuenta con algún sistema de autenticación? De no ser así, emho lo consideraría antes que un administrador (que tampoco entendí muy bien qué sería ) o bien como un plugin de fábrica.

Tampoco entiendo eso de los múltiples dominios. ¿Podrías explayarte?

// Saludos

[dec]

Hola,

Empezado por roman

¿Humm cuenta con algún sistema de autenticación?

No; ya sabes que, en realidad, Humm está mucho más "abajo" que eso.

Empezado por roman

De no ser así, emho lo consideraría antes que un administrador (que tampoco entendí muy bien qué sería ) o bien como un plugin de fábrica.

Tengamos en cuenta que Humm funciona sin necesidad de instalación, configuración ni bases de datos. De este modo, no hay para qué implementar algo así como un sistema de autenticación, pues Humm desconoce siquiera si hay algo que autenticar.

Un "administrador" vendría a ser una especie de gestor de contenidos incorporado en el propio sistema. Para esto ya, lógicamente, sí que necesitaría de algún tipo de autenticación, aunque, en realidad bastaría con una constante de configuración/contraseña.

Pero como dije más arriba creo que la idea de tal administrador está un tanto desencaminada y creo que algo así no es preciso en Humm.

Empezado por roman

Tampoco entiendo eso de los múltiples dominios. ¿Podrías explayarte?

Lo de los "múltiples dominios" sí que es algo interesante, pues, se supone que permitiría utilizar una misma base de código, una misma copia de Humm, para gestionar varios dominios al mismo tiempo.

Pensemos que ahora Humm cuenta con dos directorios raíces:

\Humm\System\

\Humm\Site\

En este último directorio se encuentran las vistas, estilos, scripts, imágenes, etc., del sitio web que Humm gestiona. Ahora bien, lo que se persigue sería contar con directorios como:

\Humm\Sites\Default\

\Humm\Sites\MiOtroSitio\

\Humm\Sites\OtroSitioMas\

Etcétera. De manera que todos esos directorios se correspondiesen con diferentes dominios o "host" o como mejor se diga. Lo que ocurre con esto es que estoy un poco pez, pero, en todo caso, creo que se trata de cambiar determinada configuración en el servidor, por ejemplo Apache.

Porque, de lo que se trata, es que diferentes URLs (www.ejemplo.com, www.otrositio.com, etc.) apunten al mismo "script", precisamente, al "index.php" o "punto de entrada" de Humm. Por otro lado huelga decir que Humm tendrá que determinar qué sitio o contenido ha de servir.

Creo que esto último se basa, más o menos sencillamente, en la variable "$_SERVER" y valores como "HTTP_HOST", puesto que a partir de ahí podría determinarse de qué "host" se trata y por tanto qué directorio de sitio ha de usarse. No sé si más o menos he conseguido explicarme.

Gracias por tu interés Román.

[roman]

Lo de las urls distintas apuntando al mismo sitio, creo que lo puedes resolver con servidores virtuales (en Apache). Pero eso ya implicaría meterse con la configuracion del servidor.

// Saludos

[dec]

Hola,

Empezado por roman

Lo de las urls distintas apuntando al mismo sitio, creo que lo puedes resolver con servidores virtuales (en Apache). Pero eso ya implicaría meterse con la configuracion del servidor.

En efecto, parece que hay que vérselas con el servidor. No importaría, es decir, HummPHP es independiente del servidor (con esa idea se hace, vaya, por ejemplo, recordemos que maneja URLs más o menos "amigables" sin necesidad de "MOD REWRITE" alguno, cuya implementación depende del servidor) y se supone que una vez configurado el servidor, HummPHP podría determinar qué contenido servir dependiendo de la configuración del servidor.

De todas formas el asunto (del lado de HummPHP) no es tan sencillo como puede parecer en un primer momento. Le estado dando unas cuantas vueltas y no he seguido adelante, pero, es algo que me gustaría añadir. Y el caso es que no he parado aún y sigo trabajando en el proyecto a marchas forzadas. De hecho espero hoy mismo publicar aquí lo que llevo hecho de esta versión 2.0, para que los que queráis podáis echar un vistazo al engendro.

[dec]

Hola de nuevo,

Venga, que no se diga... aquí os dejo adjunto lo que va de HummPHP 2.0, prácticamente terminado, por otro lado. Si queréis echar un vistazo ya sabéis que podéis montar un servidor de manera sencilla usando Xampp. Por otro lado, si queréis trastear un poco con el código os recomiendo que lo hagáis con NetBeans para PHP. Y eso es todo, espero que lo disfrutéis.

Cualquier comentario, reporte de error, etc., será bienvenido.

[Casimiro Notevi]

.

[dec]

Empezado por roman

Lo de las urls distintas apuntando al mismo sitio, creo que lo puedes resolver con servidores virtuales (en Apache). Pero eso ya implicaría meterse con la configuracion del servidor.

// Saludos

Captado este asunto de la configuración de Apache, parece que, en efecto, HummPHP debería poder lidiar con distintos sitios... así que ya estoy en ello.

[dec]

Hola,

Menos de una hora... eso me ha costado implementar en HummPHP la posibilidad de manejar diferentes sitios (dominios) con una misma base de código. Lo que parecía que iba a complicar las cosas, los espacios de nombres en PHP, han resultado por el contrario de gran ayuda. De hecho Humm cumple ahora mismo con cierto estándar que implica usar los mismos espacios de nombres que el árbol de directorios en que se encuentran.

Todavía me queda "refactorizar" un poco y darle alguna que otra vuelta, pero, en efecto, HummPHP cuenta ahora con un directorio "Sites" en lugar de "Site". Dentro de este directorio se puede encontrar otro de nombre "Main". Este será el directorio por defecto y contendrá todo lo necesario para un sitio: vistas, clases, plugins, archivos de lenguaje, etc. Este directorio podrá replicarse, por decirlo así, tantas veces como se quiera, en diferentes subdirectorios de "Sites".

El truco estará en el nombre de dichos directorios, que, habrán de corresponderse con el "nombre del servidor" ($_SERVER['name']) "capitalizado" (por seguir la convención), es decir, supongamos que tenemos dos dominios: www.juanito.com y www.pepito.com.

Instalamos Humm en www.juanito.com, por ejemplo, de manera que este dominio "cargará" el sitio principal o predeterminado en HummPHP (situado en el directorio "Main"). A continuación tendremos que buscarnos la vida para configurar el servidor (en Apache, al menos "en local" no es complicado) de manera que todas las peticiones al dominio www.pepito.com apunten al mismo directorio en que se encuentra copiado HummPHP en www.juanito.com

El "truco" estará entonces en crear un nuevo directorio en "Sites" de nombre "Juanito", en este caso, replicando los directorios del sitio principal. En principio no habría más que hacer, puesto que las clases (de vistas, por ejemplo) y los plugins son opcionales, pero, en caso de hacer uso de esta característica, dichas clases y plugins deberán estar en el espacio de nombres "Humm\Sites\Pepito\Classes", para las clases, y "Humm\Sites\Pepito\Plugins" para los plugins.

Y eso es todo... lo que en realidad se comparte entre los dos sitios es el directorio "System" de HummPHP, lo que equivale a decir todo el sistema, puesto que lógicamente cada sitio tendrá su propio contenido... pues por algo son sitios diferentes. Por otro lado los sitios podrían compartir ya los plugins del sistema, pero, veré si se me ocurre algún otro lugar donde situar los plugins compartidos por difentes sitios: al fin y al cabo creo que sólo se trata de añadir una ruta más al "gestor de plugins".

Por lo demás los sitios pueden compartir clases PHP sencillamente gracias al espacio de nombres de PHP y a cómo "carga" las clases el sistema, equiparando el espacio de nombres con el árbol de directorios. De este modo podríamos tener dentro del directorio "Sites" un directorio de nombre "Shared" o "Classes", que, usando el espacio de nombres apropiado, sólo nos tendríamos que preocupar de usar cuando nos hicieran falta, ocupándose el sistema de encontrarlas y cargarlas.

En fin... creo que he tardado más en soltar este rollo que en conseguir (al menos de momento) el objetivo. Creo que yo seré el primero en usar esta característica "multisitio" de HummPHP, pues, si puedo configurar el servidor, cuando rehaga mis sitios, todos ellos van a compartir la misma copia de Humm, cosa que me ahorrará tiempo y trabajo si por ejemplo decido actualizar el sistema, etc.

¡Y no digo más!

[dec]

Hola de nuevo,

Pues nada... más novedades. A través de "CPanel" (el "hosting" que uso lo proporciona) resulta de lo más sencillo hacer que varios dominios apunten a un mismo directorio. Se trata de dominios añadidos o "addons" y no hay que andarse configurando "virtual host" ni nada por el estilo: simplemente se indica el directorio al que tiene que apuntar un dominio. Y a funcionar.

[dec]

Hola,

Quiero explicar aquí cómo se puede configurar el servidor Apache (al menos la distribución que se incluye en Xampp) para crear "virtual host", puesto que es algo que no había usado hasta ahora y veo que tiene utilidad, no sólo para comprobar sistemas "multisitio" como HumPHP, pero, también a la hora de trabajar en nuestro ordenador y en su servidor local.

Hasta ahora yo usaba URLs del tipo "http://127.0.0.1/HumPhp", "http://127.0.0.1/OtraCosa" , etc. Pero, veréis lo sencillo que es configurar Apache y Windows para que podamos utilizar URLs como "www.hummphp.dev" y "www.otracosa.dev", por ejemplo.

1º Paramos Apache si está en marcha

2º Abrimos el archivo "xampp\apache\conf\extra\httpd-vhosts.conf" y añadimos:

<VirtualHost *:80>
  DocumentRoot "/xampp/htdocs/HummPhpSite"
  ServerName hummphp.dev
</VirtualHost>

<VirtualHost *:80>
  DocumentRoot "/xampp/htdocs/HummPhpSite"
  ServerName www.hummphp.dev
</VirtualHost>

3º Abrimos (como administrador) el archivo "C:\Windows\System32\Drivers\etc\hosts" y añadimos:

127.0.0.1       hummphp.dev
127.0.0.1       www.hummphp.dev

¡Y eso es todo! Ya podemos arrancar Apache de nuevo y podremos navegar hasta "hummphp.dev" y "www.hummphp.dev", apuntando ambos "host" al mismo directorio "/xampp/htdocs/HummPhpSite".

[roman]

Empezado por dec

Se trata de dominios añadidos o "addons" y no hay que andarse configurando "virtual host" ni nada por el estilo: simplemente se indica el directorio al que tiene que apuntar un dominio. Y a funcionar.

¿Y estás seguro que el cpanel no crea un servidor virtual?

// Saludos

[dec]

Hola,

Empezado por roman

¿Y estás seguro que el cpanel no crea un servidor virtual?

// Saludos

Así es Román, probablemente. Yo iba más bien por lo sencillo que resulta hacerlo gracias a "CPanel".