No sé que sentimientos puede tener un padre hacía un hijo, no soy padre. Pero soy hijo y por lo tanto podría ponerme en la piel de Puskas CMS para experimentar los sentimientos, si los tuviese, hacia su creador, el mismo que aquí escribe.

Después de meses de gestación, Puskas existe. Crece y se enriquece con la única pretensión de sustentar lo que hoy podéis ver como promineostudios.com.

Cuando comencé el desarrollo tuve que tomar decisiones que afectarían a cualquier evolución posterior de la aplicación. Decidí replantear todo el trabajo que había realizado hasta el momento. Como base usé el patrón de diseño MVC, hasta ahora usaba un híbrido entre OOP PHP5 y un sistema de plantillas con el que podía tener el código más o menos limpio y sencillo de mantener, pero que no era suficiente. No para lo que yo quería que fuese el CMS de Promineo Studios.

El anterior sistema de plantillas, Smarty, era bastante correcto en su funcionamiento pero requería demasiados recursos, además de obligar a aprender un pseudo-lenguaje nuevo, muy sencillo eso sí. Smarty se hizo prescindible, ya que desarrollé mi propio motor de plantillas valiéndome del propio PHP y las QuickTags. El aumento de rendimiento fue significativo, aún cuando smarty cachea las plantillas, ya no era necesario tener un motor tan pesado para generar las vistas de una página.

El segundo paso fue programar el núcleo de la aplicación con todas las funcionalidades básicas que incorporaría el CMS. Como por ejemplo, controladores base, modelos base, configuración, autentificación de usuarios, filtros de entrada de datos, manejador de conexión a base de datos, multilenguaje, sesiones y demás hierbas.

Como funcionalidades más 'revolucionarias' del núcleo puedo nombrar el uso PHP Data Objects, Gettext o manejo de Sesiones desde una base de datos. De PHP Data Object, escribiré e instruiré en próximos artículos en los que transmitiré todo lo que he aprendido de esta interfase de acceso a datos que me tiene enamorado ;-p. Sobre Gettext, que puedo decir... Es el pilar de toda aplicación multilenguaje que se precie. Y el manejo de sesiones desde una base de datos da para otro artículo.

Dejando de lado el núcleo, Puskas ofrece un completo sistema de blog, videoblog y creación de cualquier contenido para una web. Debo reseñar la incorporación de trackback y pingback en el blog, una característica muy interesante para comunicar contenido referenciado entre blogs. Comentarios enriquecidos con Ajax, votación de artículos

Aún queda mucho que madurar y para próximas versiones incorparé un sistema de caché para contenido estático, comentarios para el videoblog y cualquier cosa que se me vaya ocurriendo. txp4zuaybj

Los php_flag son parámetros de seguridad que habitualmente se configuran desde el php.ini para todo el servidor o desde el .htaccess para una aplicación en particular. En caso de tener PHP instalado como un módulo de apache podrás configurar los php_flag desde el .htaccess de la siguiente manera:

php_flag magic_quotes_gpc Off
php_flag safe_mode on
php_flag expose_php off
php_flag display_errors off

En cambio, si tu instalación PHP corre como CGI esta forma sólo hará que tu web muestre un error interno del servidor. Para evitar esto podemos crear un php.ini para la aplicación web. Es tan sencillo como crear un archivo de texto con el nombre 'php.ini' en el directorio raíz de la web e introducir los flags que necesitas, como puedes observar en el siguiente ejemplo:

magic_quotes_gpc = Off
display_errors = Off
register_globals = Off 

Si trabajas con PHP5 y POO te habrás topado en infinidad de ocasiones que has desarrollado una clase y debes instanciarla una y otra vez en cada una de las clases que crees posteriormente. Por ejemplo, una clase que se encargue de realizar la conexión con una base de datos. Como los datos de conexión de nuestra supuesta clase 'BaseDeDatos' no van a cambiar en ningún momento, ni necesitamos que el constructor de la clase mande diferentes parámetros con cada una de las instancias que hagamos, sería un desperdicio innecesario de memoria instanciarla en cada una de las clases que requieran acceso a la base de datos.

En este caso lo más lógico sería tener una instancia única siguiendo el patrón de diseño singleton, que garantizará que una clase sólo tenga una instancia con un punto de acceso global a ella.

Implementar este patrón es tan sencillo como crear un método que se encargará de crear un objeto de la clase si este no existe o devolver el objeto creado si existe una instancia previa. El constructor de la clase debe ser controlado con el atributo private para asegurarnos de que no se puedan crear instancias de forma directa.

Explicado sin nada de código puede parecer un poco confuso, así que mejor verlo en acción.

 
class BaseDeDatos{
    //instancia de la clase
    private static $instancia = null;
 
    /**
     * Constructor con atributo privado
     */
    private function __construct(){
        echo 'constructor';
    }
 
	/**
	 * Método para patrón singleton
	 * @return instancia del objeto
	 */
	public static function singleton(){
		//si no existe instancia de la clase se crea y si existe se retorna la instancia existente 
		if( self::$instancia == null ){
			self::$instancia = new self();
		}
		return self::$instancia;
	}
}
 
//la primera vez se crea una instancia
$obj1 = BaseDeDatos::singleton();

//el resto de veces se retorna la instancia ya creada
$objX = BaseDeDatos::singleton();
 

Cuando diseñamos una página web, ésta debe verse exactamente igual en todos los navegadores. Lograr la exactitud visual independientemente del navegador que usemos genera inmensos dolores de cabeza al pobre desdichado que le ha tocado maquetar. Estas incompatibilidades visuales suelen ser debidas por una mala codificación del xhtml o del css, o porque el navegador no a hace uso de los estándares web, como pasa con IE6.

Pero no todo es culpa de IE6 ni de que nuestro código xhtml no sea válido. Hay otras ocasiones en las que una misma etiqueta html tiene diferentes valores para distintos navegadores, no es habitual pero puede pasar. Por ejemplo, la etiqueta < img> si se encuentra dentro de etiqueta < a> en Internet Explorer se genera con un borde alrededor de la imagen y en Firefox se muestra sin ese borde (como debería ser).

Para evitar este tipo de diferencias la mejor solución es tener una hoja de estilos (CSS) base e independiente del diseño que vayamos a definir. Esta hoja resetearía los estilos para las etiquetas más habituales a unos valores por defecto. Así evitamos parte de esos errores de compatibilidad entre navegadores. aa

 
html, body, div, span,
applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
dd, dl, dt, li, ol, ul,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
	margin: 0;
	padding: 0;
	border: 0;
	font-weight: inherit;
	font-style: inherit;
	font-size: 100%;
	line-height: 1;
	font-family: inherit;
	text-align: left;
	vertical-align: baseline;
}
a img, :link img, :visited img {
	border: 0;
}
table {
	border-collapse: collapse;
	border-spacing: 0;
}
ol, ul {
	list-style: none;
}
q:before, q:after,
blockquote:before, blockquote:after {
	content: "";
}
 
 

Código extraído de Meyerweb.com