En GuiMags han tenido una idea mejor para diseñar prototipos de formularios que el lapiz/papel o el programa de turno.
Han creado pequeñas cartulinas magnéticas con diferentes formas de controles de formulario (botones, pestañas, combos, radio buttons, cajas de texto, checkbox, controles numéricos, slider), que podamos tocar, mover, colocar sobre una pizarra, pintorrear por encima, borrar y volver a pintorrear. Desde luego una forma pero que muy ágil, habrá que probar cuanto de reales son los resultados.
Yo ya estoy pidiendo una cajita para mi próxima pizarra, eso si la Students (29.95$), que estamos en crisis.
Google lanza su propio navegador web, ya no son rumores, es noticia confirmada. Por un lado en este gracioso e ilustrativo comic y por otro en el blog oficial de google, en breve también estará disponible para su descarga.
En estos momentos estoy confuso. No se si alegrarme por la noticia de un nuevo navegador que continúe haciendo crecer la web y sus diferentes aplicaciones, o por el contrario mantener todos mis temores ante la aparición de ¡un nuevo navegador donde testear webs!.
Una buena y otra mala noticia, y a las dos nos tiene acostumbrados google. La buena: será 100% open source, ¡bien!. Y la mala: los usuarios de linux tendremos que continuar esperando, ¿hasta cuando?.
Os animo a leer este artículo de Enrique Dans, en el que expone la idea de un navegador diferente, una nueva plataforma web para soportar aplicaciones, el primer paso para restar la dependencia de algunos pesados sistemas operativos actuales. Para ello google chrome incluirá google gears y contará con una maquina virtual de javascript al que llaman “V8″, que si cabe viene a reforzar todavía mas ajax, que google utiliza en todos sus productos, y GWT como kit de desarrollo, del que espero contaros mis experiencias dentro de poco. También contará con un sistema multihilo para que la vida del navegador no dependa de la web a visualizar.
Esperemos a tener siquiera una beta para tener las cosas mas claras, por cierto, no me gusta nada el nombre.
Como soy así de vicioso esta mañana estaba dedicando algo de mi tiempo a maquetar un formulario sobre el que pueden actuar 3 botones con acciones diferentes (pongamos guardar en session, guardar en BD y eliminar de session). Este formulario debe cumplir estándares xtml+css2 y debe ser accesible lo cual me obliga a prescindir de javascript para su funcionamiento básico, se acabó el document.location.href='xxx'.
Gloogleando un poco me encontré con este buen artículo de Olga Carreras.
La idea es muy simple. A cada uno de los botones le asignamos un name un id y un value, y en el servidor nos encargaremos de comprobar que botón se ha pulsado y de ejecutar la acción correspondiente.
-
<form action="./controllerForm" name="form1" id="form1" method="post">
-
<input type="submit" value="Guarda" id="save_session" name="save_session" />
-
<input type="submit" value="Eliminar" id="eliminar" name="eliminar" />
-
<input type="submit" value="Enviar" id="enviar" name="enviar" />
-
</form>
Como veis me he puesto en plan diseñador-meticuloso-pejillero y gracias a los conocimientos de css/xhtml adquiridos en mi etapa de interacción he podido cambiar un poquillo el layout de este espacio.
Mas espacio en la columna de navegación, nuevo menú de navegación superior donde en los próximos días encontrareis un enlace al nuevo wiki, menos importancia al titulo de este blog (el cual me sigue sonrojando :$ estaba falto de ideas aquel día), el buscador en la cabecera, la nube de etiquetas y algunos cambios de colorines.
Como no podía ser de otra forma me topé con los siempre cojoneros problemas de visualización en ie. Este vez le tocaba a los bloques que contienen otros bloques flotantes. El bloque padre no se adapta a la altura de su contenido así que toca utilizar los hacks para ie6 y ie7.
Lo primero añadir las css con los bloques condicionales para los ie's.
-
<!--[if IE 6]>
-
-
@import url( /ie6.css );
-
</style>
-
<![endif]-->
-
<!--[if IE 7]>
-
-
@import url( /ie7.css );
-
</style>
-
<![endif]-->
Luego en ie6.css declaramos la altura del contenedor padre como:
Y para ie7.css así:
-
#header {
-
display:inline-block;
-
}
Esta vez he tenido suerte y no han sido necesarias mas personalizaciones.
Tanto los componentes como los helpers están diseñados para extender las funcionalidades que el propio núcleo cake nos ofrece. La diferencia? bien sencilla. Mientras los componentes añaden lógica de negocio a nuestro proyecto, los helpers añaden lógica de presentación.
Componentes:
Existen multitud de componentes que podemos descargar y utilizar: Sending Email With PHPMailer, Integrate CakePHP with Kcaptcha, Google Geocoder, LastRSS CakePHP Component, Pagination Component, etc. Y otros que ya vienen incluidos con el núcleo cake: AuthComponent (Gestión y autenticación de usuarios), RequestHandler (Obtener información de las peticiones http), CookieComponent (Gestor de cookies), AclComponent (Access Control List), EmailComponent (Envio de mails), SecurityComponent (Incrementar la seguridad de tu aplicación), SessionComponent (Gestor de session). Y podemos crear nuestros propios componentes para cumplir diferentes requisitos:
Crear un nuevo componente para cakephp es muy sencillo. Basta con crear un fichero en app/controllers/components/fichero.php con una clase nombrada FicheroComponent que tendrá una variable $controller y un método:
-
function startup( &$controller ) {
-
$this->controller = &$controller;
-
}
Luego para hacer uso de un componente en uno de nuestros controladores simplemente lo añadimos al array
-
var $components =
array('NuestroComponente',
'OtroComponente');
y ya lo tendremos disponible como
Aqui tenemos un buen ejemplo de uso del json component.
Helpers:
Respecto a los helpers también los tenemos incluidos en el núcleo cake: html (ayuda a contruir tags html), form (ayuda a contruir formularios), number (ayuda a formatear numeros), timer (ayuda a formatear fechas), xml (simplifica la construcción de documentos xml), ajax (uso de ajax mediante prototype). Su uso es tan sencillo como:
-
-
<h1><?php echo $html->link(__('Portada', true), $html->base.'/portada'); ?>
</h1>
-
</div>
-
<!--Hacemos uso del helper $html tanto para crear un link como para obtener la dirección base de nuestra web.-->
Al igual que los componentes también podemos desarrollar nuestros propios helpers, aqui tenemos un buen ejemplo donde se crea un helper para autocompletar un input text mediante ajax .
Hoy, después de pelearme con el eclipse un rato (tampoco fue como para una separación seria, solo unos días hasta que se me pase) me he dado una vuelta por netbeans y me entero de que la nueva versión 6.1 ya trae el plugin integrado para soportar php. Es mas, nos podemos descargar una versión de este ide solo con el plugin para php por la módica cantidad de 16MB.
La he instalado y las primeras impresiones son buenas pero...
El editor está bien, el autocompletado de funciones funciona!, la refactorización se reduce a renombrado de ficheros y ni siquiera lo hace bien, excelente integración con svn (igual que la versión javera), en principio parece que la integración con xdebug es bastante buena pero solo lo he usado con proyectos demo.
Pero... el mismo pero de siempre, sigue siendo muy pesado, consume una grandísima cantidad de memoria. Será momento de plantearme un cambio de equipo? mmm, no se no se, creo que aguantaremos un poquillo mas.
http://wiki.netbeans.org/PHP
Este fin de semana el cake me hizo otra de las suyas. Aunque pensándolo bien siempre podemos disculparlo por trabajar en beta.
El caso es que yo necesitaba mi propio AppController para incluir una serie de acciones comunes a todas las peticiones, y que se ejecutarían en el beforeRender() (justo antes de renderizar la vista y después de ejecutar toda la lógica de los controladores).
Esto en cake 1.1 se hacía copiando el app_controller.php a la raíz de /app, sobreescribíamos los métodos necesarios y listo. Y claro antes de leer nada fue lo primero que hice en cake 1.2. Pero no tuve suerte. Resulta que no encontraba los métodos que estaba declarando. Cake no estaba cargando mi app_controller sino el por defecto en /cake/libs/controller.
De primeras acudí a google (no conozco otra forma mas rápida de encontrar solución a este tipo de problemas) y tras comprobar que era al único que le sucedía tal cosa me fuí directo a http://manual.cakephp.org/complete/3/the-manual y la sorpresa cuando me encuentro con estas líneas:
Both controllers, helpers and models have a parent class you can use to define application-wide changes. AppController (located at /app/app_controller.php), AppHelper (located at /app/app_helper.php) and AppModel (located at /app/app_model.php) are great places to put methods you want to share between all controllers, helpers or models.
Lo estaba haciendo bien!, tras navegar por el registro de bugs llegué a esta conversación en el grupo de google , que seria de mi sin la comunidad!, resulta que para extender el app_controller en cakephp 1.2 debes situarlo en /app/controllers/app_controller.php y no en /app/app_controllers.php.
No me quejo, es el riesgo que se corre por trabajar en betas, además, quitando estos dos detalles cake y yo nos llevamos bastante bien. Aunque eso si, prefiero no tener documentación a tener documentación mentirosa.
