Caido el servidor SVN hasta nuevo aviso

Y bueno, lamentablemente tengo que actualizar unas cosas, y por los proximos días estará caido el servidor SVN. Igual intentaré subir las reviciones al grupo: http://groups.google.com/group/amtfwm

Nuevo esquema de configuración!

Cambió la vieja forma de configuración de nuestro proyecto por una más dinámica y fácil.

Yo no se aplican los modos (desarrollo, producción) en cada archivo de configuracion como antes.

Ahora (en el tree) hay una carpeta llamada /config, con subcarpetas con los modos.
Por defecto vienen 2, la "default" y la "prod", esta última es un ejemplo, pero la carpeta "default" no, esa es obligatoria, ya que contiene la configuración por defecto que tomará si no encuentra el arhivo de configuración necesario en la carpeta del modo.

El ejemplo sería:

/config
|-[default]
| |- db.php
| |- extradata.php
| |- general.php
| |- logs.php
| |- tasks.php
| |- template.php
|-[prod]
| |- db.php
| |- logs.php
|- init.php

Donde los archivos en default, serían los mismo que antes, osea, TODOS los archivos de confoguración del proyecto (bases de datos, encoding, logs, etc), y lo que está en el directorio "prod" se cargarian solo en el caso de que estemos en producción, eso lo decide a su vez el init.php.

init.php:

1. if ($_SERVER['SERVER_NAME'] == "localhost") {
2. define ("APP_MODE","dev");
3. } else {
4. define ("APP_MODE","prod");
5. }//if
6. 
   
7. load_config("general",APP_MODE);
8. load_config("db",APP_MODE);
9. load_config("logs",APP_MODE);
10. load_config("template",APP_MODE);
11. load_config("tasks",APP_MODE);
12. load_config("extradata",APP_MODE);

El load_config, lo único que haría es cargar el archivo de configuración segun el modo, si por ejemplo el modo esta seteado en "prod" buscará el archivo en /config/prod, si no existe, lo obtendrá de /config/default.

El modo lo puede sacar de varias formas, ip, dominio, parametros, lo que sea. por ejemplo se puede hacer:

1. if ($_SERVER['SERVER_NAME'] == "localhost" || $_SERVER['REMOTE_ADDR'] == "190.64.128.10" )) {
2. define ("APP_MODE","dev");
3. } else {
4. define ("APP_MODE","prod");
5. }//if

Eso por ejemplo seria, que si el server es localhost, sea desarrollo o si el ip que la visita es "190.64.128.10", esto es por ejemplo, para probar sitios en modo dev (con otra DB o logueando todo por ejemplo) en un sitio ya en producción, limitando el acceso solo desde nuestra ip a ese modo.

Otra cosa que cabe destacar, es que también son mas flexibles la llamada a la configuración:

load_config("template",APP_MODE);

Osea que se puede agregar cualquier archivo nuestro y llamarlo usando el esquema de configuración.

load_config("menu",APP_MODE); // lamará a /config/[modo]/menu.php

Para ver los cambios usa el SVN: svn://source.amtfwm.com.ar/amtfwm-current

SVN ¡Por fin!

Buenas, me da mucho placer anunciar que ya tenemos un svn para que puedan descargar el current del proyecto. Los últimos cambios esta reflejados acá.

El acceso anónimo es de solo lectura, pero el que quiera entrar al proyecto para desarrollar, es bienvenido, solo tiene que pedirlo desde el grupo (http://groups.google.com/group/amtfwm) y se le dará un usuario/pass del svn.

svn://source.amtfwm.com.ar/amtfwm-current

Para tener la última versión del código, solo deben hacer un checkout

svn checkout svn://source.amtfwm.com.ar/amtfwm-current

Y para mantenerlo al día:

svn update *

Obviamente en el directorio donde lo quieren tener.

Retraso de la beta 2, ¿valdrá la pena?

Bueno, aunque la Beta 2 está retrasada, creo que me agarro de nuevo esa onda malcriada que tengo de perfeccionar todo y al final llenarme de tareas.

La Beta 2 está retrasada, pero por las cosas que agregué a la lista de tareas ( y que son mis últimos días de vacaciones).

Los cambios realizados hasta ahora son (desordenados):

• Se agrega un archivo de configuracion general en /config
• Se agrega el directorio /config/modules para la configuración de los módulos
• Se agrega el directorio /data para guardar información de módulos
  
• La clase de templates ya acepta la salida de encoding (Arreglados todos los problemas)
• El método printout de la clase de templates, admite un parámetro para solo devolver en template terminado (para uso de sub-template)
• Arreglado el tema de los metas, en vez de value, ya pone content
• Agregado el método add_http_equiv_to_header en la clase de templates
• Arreglado, borrar espacios de los finales de las clases
• Agregado en el método get_server_info en la clase sql
• Agregado el cache en clase sqlmaker
• Agregado el uso de encodig para guardar/mostrar datos en la clase sqlmaker (Arreglado errores de encoding al guardar datos)
• Modificada la clase abml_base, el método data_save devuelve siempre el id, aunque sea un update
• Se agregó el método set_by_postdata en abml_base, para automatizar el seteo por post
• Agregado el método h en el helper de template, para generar los titulos.
• Agregada la funcionalidad en la clase templates para definir items especiales, usos.
• Mejorado el método make_menu

Y los que faltan o están en desarrollo y/o arreglo:

• Ajax helper: Está terminado el JS, pero no la integración desde PHP
• Form Helper: Esta terminada la implementación de PHP, pero no está terminado el JS que valida los formularios de forma inteligente

Y estos son aregados que pienso hacer a futuro, en la versión 0.7 o 0.9

• Clase AMBL_BASE_EXT con soporte para relaciones entre tablas, relaciones paramétricas, internacionalización, entidades y demás.
• Aplicación, helper para automatizar, al estilo amtfwm create-project Mi proyecto
• Paquetes para las distribuciones mas usadas en servidores: Red-hat/Fedora, Debian/Ubuntu y Slackware
• Soporte nativo para modrewrite (pero no obligatorio)
• Implementación nativa de comunicación entre aplicaciones por webservices (con y sin SOAP)
  

Apenas publique la beta 2, la pienso a dar a conocer, así que la prendo hacer perfecta.

Por otro lado cabe aclarar de que la Beta 2 en realidad no va a ser de la versión 0.3 sino de la 0.5, creo que por los cambios sufridos se la merece.

Luego de esta beta, y de los cambios que falta que los pienso poner en la v. 0.7 o 0.9, espero que sea la última (la beta 3) y luego poder sacar la versión 1.0 estable.

Amtfwm Beta 2 (lo que se viene)

Bueno, en pocos días se viene la segunda beta del Framework, y se viene mucho mas estable y dinámico, así como con mas utilidades y fácil manejo.

La segunda beta de esta entrega ofrecerá:

• data: Creación de un standart en el tree, se añade el directorio data con acceso de escritura donde deberá ir la información (data) que trabajen los módulos y etcs. Como por ejemplo fotos, archivos que se suban, o para bajar, etc.
• Ajax helper: funcionando, también en el tree, el helper de ajax para javascript, del cual ya hablé en este blog, se entrega funcionando, y aunque todavía no esta la implementación del helper php, con el JS ya se puede jugar y muy bién.
• Abml_class: Arreglados algunos errores de la clase abml_base y se agregó el método set_by_postdata para facilitar el manejo junto al helper de formularios, este setea las opciones en el abml desde lo traído por post data (o get data)
• Form Helper: (facilidad para los formularios), se entrega el form helper para la creación de formularios inteligentes y con las posibilidades de envío por ajax y validación automática, así como la generación de formularios automática desde la información de la tabla.
• Templates: plantillas predefinidas ya instaladas para ir jugando con la clase de templates.
  

Bueno, espero que esto les valla sirviendo, cualquier aplicación hecha con la Beta 1, andará perfectamente en este Beta 2.

Como siempre me retraso, la fecha la voy a dejar indeterminada, pero supongo que en esta semana ya saldrá con algunas cosas mas que no incluí acá.

Ajax, una tarea fácil

Bueno, aunque todavía no es tan fácil como quiero que sea en un futuro, creo que es lo suficientemente fácil como para incluirlo en el framework :).

En el current del proyecto (próximamente a salir la Beta 2) ya esta andando el helper js para ajax, solo el js, pero acá un ejemplo del uso:

Esta función, expande una árbol de un menú de subcategorías:

1. function cat_load_n_expande (cat_id) {
2. 
   
3. // Parseo la variable cat_id a entero
   
4. cat_id = parseInt(cat_id);
5. 
   
6. // Creo el objeto ajax_helper del framework:
   
7. var oajax = new ajax_helper();
8. 
   
9. // Acá solo referencio a unos objetos que uso en el árbol:
   
10. if (cat_id) var signito = document.getElementById("cat_" + cat_id + "_explog");
11. if (cat_id) var linker = document.getElementById("expcmd_" + cat_id);
12. 
    
13. // se le pasa la URL
    
14. oajax.url = "?task=admin&acc=categorias&ajax";
15. // le seteo un div para todos los mensajes (carga, completo, etc)
    
16. oajax.set_all_divs("cat_tree_" + cat_id);
17. // le seteo que el texto cuando se complete sea el responsetext (con true)
    
18. oajax.on_complete_text = true;
19. // El texto que va a tener el div, cuando se inicie la carga
    
20. oajax.on_init_text = "Cargando arbol de subcategorias...";
21. // Acá solo reemplazo el signo que está antes del titulo para definir que está abierto
    
22. if (cat_id) signito.innerHTML = "▼";
23. if (cat_id) linker.href = "javascript:cat_unexpande(" + cat_id + ")";
24. 
    
25. // Seteo para que le mande el parametro level con el id pasado (recuerden que esto castea solo)
    
26. oajax.add_param ("level",cat_id);
27. // envio
    
28. oajax.send();
29. 
    
30. }//function

Bien explicada les dejo esta función, para que masomenos vena el uso del objeto.

Esta es para crear una opción en el árbol:

1. function cat_save (sup_id) {
2. 
   
3. // Creamos el objeto ajax
4. var oajax = new ajax_helper();
5. // Obtenemos los datos del input
6. var cat_titulo = document.getElementById("categoria_titulo_"+sup_id).value;
7. var cat_id = document.getElementById("categoria_id_"+sup_id).value;
8. 
   
9. // Pasamos la url:
10. oajax.url = "?task=admin&acc=save_categoria";
11. // Le decimos que cuando termine la carga, ejecute una función
12. oajax.on_complete_func = cat_load_n_expande;
13. 
    
14. // Parámetros:
15. oajax.add_param ("categoria_titulo",cat_titulo);
16. oajax.add_param ("categoria_super",sup_id);
17. oajax.add_param ("categoria_id",cat_id);
18. // Enviamos los datos...
19. oajax.send();
20. cat_edited = false;
21. }//function

No hay que preocuparse por hacerlo compatible con la mi#rd4 del IE, Firefox, opera, safari, etc. es compatible con todo (solo) y sin necesidad de hacks ni códigos extras.

Como convertir un sitio convencional a uno 100% en ajax (en 5 minutos):

Y digo 5 minutos para darles tiempo de hablar por msn nada mas. La cosa es así, si el sitio está desarrollado en el framework usa las tareas y acciones (tasks y accs), así que suponiendo por ejemplo que tenemos un sitio con 4 secciones (Portada, blog, foro, galeria) como ejemplo, las tareas serían:

www.sitioejemplo.com/?task=portada
www.sitioejemplo.com/?task=blog
www.sitioejemplo.com/?task=foro
www.sitioejemplo.com/?task=galeria

Si se usó bien la clase de templates, en los archivos de salida abría algo así:

1. set_for_captura("CONTENIDO"); ?>
2. 
   
3. Ejemplo de lo que va a salir
4. 
   
5. end_captura(); ?>

La opción en el template CONTENIDO, contendría al fin y al cabo el contenido, sin menúes ni nada (si esta bien trabajado) así que si tenemos un template:

<html>
<head><!-- ##HEAD## --></head>
<body>
<div id="todo">
<div id="titulo">
<h1>Ejemplo de template</h1>
</div>

<div id="cuerpo">
<div id="menu"><!-- ##MENU## --></div>
<div id="contenido"><!-- ##CONTENIDO## --></div>
</div>

<div id="footer"><!-- ##FOOT## --></div>

</div>
</body>
</html>


Solo suponiendo xD, lo que va en el menú, el footer, la cabecera y demás se cargan otro archivo, el contenido al fin y al cabo se cargaría desde los outs de las tareas.

Supongamos que hagamos un template:

1. <!-- ##CONTENIDO## -->
   

sin nada mas, el FW solo expulsará a la salida el contenido neto trabajado, entonces... se puede hacer un perfecto uso de la clase de ajax para tener un sitio en ajax, que ala vez tendría la ventaja de llegar a todo su contenido por URL (para ser indexado por buscadores por ejemplo).

En que se basaría esto:

hacemos una pequeña función en js:

1. function go_task (task) {
2. // definimos la ruta (? o index.php o donde se tenga el init)
3. oajax.url = "?";
4. // usamos el methodo GET
5. oajax.method = "GET";
6. 
   
7. // Que cargue todo en el div "contenido"
8. oajax.set_all_divs("contenido");
9. // Que al completar inserte lo pedido en el div definido
10. oajax.on_complete_text = true;
11. // Cuando inicia la carga nos pone eso
12. oajax.on_init_text = "Cargando la pagina, espere";
13. 
    
14. // La tarea
15. oajax.add_param ("task",task);
16. // Le avisamos al FW que será por ajax
17. oajax.add_param ("ajax","true");
18. 
    
19. // Enviamos
20. oajax.send();
21. }

Esa es toda la función, esto ya haría la petición y la metería en el div de contenido, ahora, fijense que le mando el parámetro ajax, esto es para identificar el pedido desde el FW, ahora, en el archivos /config/template.php, podemos poner lo siguiente:

1. if (isset($_REQUIRE['ajax'])) {
2. $obj_template->remove_task_cache ("forajax");
3. } else {
4. $obj_template->remove_task_cache ("normal");
5. }//if

El template "forajax", seria el que solo contendría la etiqueta <!-- ##CONTENIDO## --> y se cargaría solo si se manda el parámetro "ajax", por lo que en las tareas no hay que modificar absolutamente nada, y después, esto lo tomo como idea, cargar un menú normal con las direcciones fijas, y en un js, hacer que se ejecute una funcion al principio que reemplace el contenido del menú para que las rutas sean con go_task();, así si el navegador tiene deshabilitado el JS o es un bot de un buscador, tendría los links directos sin necesidad de ajax.

Bueno cualquier cosa... está el grupo :)

Amtfwm; uso de packages (propuesta)

Rediseño completo del framework, basado en packages:

Este es un especie de rediseño total del framework para utilizar una forma de organización mas avanzada y robusta, y a la vez, hasta conseguir un uso mas sencillo.

Hasta ahora el framework usa un sistema de tareas, y acciones, con una salida estandart y el uso de modulos y helpers aparte de las clases del sistema, esto si bien es sencillo de utilizar, puede traer problemas a futuro en la organización del framework.

Por ejemplo, las clases sql, sql_maker, abml_base y abml_basext son del sistema de abstración de datos, pero estan al mismo nivel que otras como logs, error_man y de más.

Esto tambien proboca la carga de clases incesesarias y una depuración de estas mas compleja.

La idea con esto es dividir la aplicación en packages, donde cada “paquete” tenga sus calses y funciones independientemente del proyecto, esto en php 4 es simplemente raro, pero creo que se puede hacer una buena integración si emular muchas cosas.

Por otro lado también se erradicaria la divición “common” y “tree”, pero sin tener unido el framework con el proyecto.

Otra idea muy importanto es hacer los packetes hijos de un una aplicación web, y que la “pagina web” en cuestion sea una aplicación corriendo dentro de esta.

Hasta ahora, el archivo index.php del tree, llama al application del common, en este caso estaria el “tree” adentro del common.

Aca estaria una descripción del funcionamiento:

Uso de packages, para framework PHP

Arbol de directorios:

[root (common)]
 |--- [sys]
 |--- [defs]
 |--- [packages]
 | |--- [nombre_del_packge]
 |  |--- [classes]
 |  |--- [functions]
 |  |--- [tasks]
 |--- [local]
  |--- [data]
  | |--- [cache]
  | |--- [logs]
  | |--- [config]
  | |--- [templates]
  |--- [init]
  |--- [packages]
   |--- [nombre_del_packge]
    |--- [classes]
    |--- [functions]
    |--- [tasks]

Y uno de los packages (obligatorio) adentro de local, seria “main” con las tasks que tendria una estructura asi:

|--- [packages]
 |--- [main]
  |--- [classes]
   |--- main.php
  |--- [functions]
   |--- config.php
  |--- [tasks]
 |--- [webproj]
  |--- [classes]
   |--- main.php
   |--- ejemplo_de_tarea.php
  |--- [functions]
   |--- config.php
  |--- [tasks]

Este paquete sería simplemente el inicial, y su función seria definir que projecto será ejecutado, este seria un packete en local.

El packete “proyecto” funcionaría con los tasks, osea, en el “index” se encargaría de llamar al packete main, este decidirá a que proyecto se invoca, que es simplemente otro package el cual tambien contendrá un main, que será el que decida en base a sus calses que tarea tratará.

Cada tarea, por ejemplo, tendra su propio main, y su “destructor” o finalizador, a la vez, cada packete.

¡Amtfwm Beta 1!

Se se... me retrase mucho... encima saco una beta que rezo por falle menos de lo que me espero, jejeje, pero acá por fin.

Se pueden bajar los tar.gz de la pagina de descargas del grupo:

http://groups.google.com.pe/group/amtfwm/files

Y les paso a explicar que es cada cosa:

amtfwm-apidoc 0.3 Beta 1 (simple).tar.gz
Documentación del API generada por PHPDocumentor, en un formato simple y comodo.

amtfwm-apidoc 0.3 Beta 1.tar.gz
Documentación del API generada por PHPDocumentor, mas atractiva

amtfwm-common.0.3.Beta1.tar.gz
El framework en si

amtfwm-tree.0.3.Beta1.tar.gz
El tree, para empezar ahí los proyectos

Si no entendes como se usa el tree y el common leé la Guia de Instalación o manda un mail de ayuda al grupo.

Bueno al final así quedo:

Actualmente:

Manejo de tareas y acciones:
Mejorado del diseño original, ahora se puede llamar una accion desde otra y manejarla como un objeto.

Manejo de Logins para depuración:
Estuve comentando y agregando logins en algunas clases antes de poderlas dar de terminadas.

Manejo de templates con cache:
Funcional al 100% (igual en beta) pero no presento mas fallos.

Capa de abstracción de datos:
Como siempre... hermosa y sin errores, solo que solo esta para MySql

Capa de logica:
ABMLs y de mas... terminado, no me dio problemas, pero considerenla en Beta
Pero su uso es por decirlo.. mas que util:

$noticias = new abml_base("Noticia",$sqldb);
$rs = $noticias->data_list();

$noticias->clear();
$noticias->set("@titulo",$_POST['titulo']);
$noticias->set("@body",$_POST['contenido']);
$noticias->data_save();

Si le mando el post directamente... ¿¿lo toman inseguro?? no se imagina lo seguro que es este framework ;)

Helper para template:
Digamos que incompleto, pero lo que esta funca :)

Helper para paginación:
Util... funcionando bien

Helper para ajax:
Solo el Javascript y aclaro que no esta probado, lo incluí pero no se ilucionen

En desarrollo:

Helper de formularios
Y bueno, digamos que esta casi cocinado el helper para formularios, en la proxima versión esta seguro!
En realidad es mas lindo de lo que suena, se pueden hacer formularios de tablas con solo 2 lineas de codigo, incorpora una validación por javascript con mensajes de errores totalmente personalificables, y una forma muy facil de usar e implemetar, evitando errores comunes a la hora de hacerlos a mano xD. Tambien soporta el envio de formularios por Ajax y el armado automatico desde la tabla de la base de datos.

$form = new form_helper ("form_noticias");
$form->load_campo_from_table("Noticia",$sqlmaker->get_table_info("Noticia"));
$form->print_out();

Con eso ya se armaron un formulario que verifica los datos por tamaño, tipo, formato, por si es requerido o no por la DB con un manejo de errores hermoso, y todo esto con la posibilidad de salida en (x)html y wml, sin ningún problema

ABML_base extendida
Clase de manejo de datos de en la capa de negocios, para facilitar los abml, pero esta con internacionalización (i18n), relaciones, data extra en otras tablas y demas utilidades para no tener nada en que complicarse.

Ajax Helper
Aparte de la clase en Js, un exelente helper para manejar ajax de una forma natural y super-facil, y con utilidades muy buscadas como la subida de archivos por ajax, paginacion por ajax, y trabajando de una forma muy avanzada internamente (si estudian el js se van a dar cuenta ;-)

Y esto sigue....