Kumbia 0.5 alpha

edited septiembre 2007 in Desarrolladores
Hola Amigos

He subido el primer boceto de estructura para la version 0.5 en el SVN.

A tener en cuenta:

La estructura de archivos a cambiado considerablemente:

Los objetivos de la estructura es:

- Separar la logica de usuario del framework
- Permitir el uso de modulos
- Permitir actualizar el framework de una version a otra mas facilmente.

Nuevo Directorio app:
Se trata de colocar en este directorio los controladores, modelos y vistas de la aplicacion sin mezclarlos con otros archivos del framework.

app/controllers/application.php
Contiene el mismo archivo controllers/application de 0.4.x

app/models/base/model_base.php
La idea es definir la clase ActiveRecord como una clase que pueda ser manipulada por el usuario para abstraer metodos comunes para todos los controladores. La antigua ActiveRecord es ahora ActiveRecordBase en library/kumbia/db/active_record_base

app/models
La idea es que models tenga el mismo comportamiento que antes pero adicional a esto se puedan crear directorios para agrupar los modelos segun su funcionalidad de usuario asi:

app/
|_ models/
|_ seguridad/
permisos.php
roles.php
|_ facturacion
factura.php
detalle_factura.php
|_ compras
orden.php
proveedores.php

app/views
Es identico al de 0.4.x

cache/
Es identico al de 0.4.x

logs/
Es identico al de 0.4.x

scripts/
Contiene scripts php, de momento solo iphp.php pero la idea es agregar otros scripts que realicen pequeñas tareas.

config/
Antes era forms/config ahora lo lleve a config en la raiz. Esto porque estaba mezclado con la clase Config y causaba confusion. Ahora su tarea es mas clara: almacenar todos los archivos de configuracion. En este punto hay que debatir si se debe mover a app para que exista uno en cada modulo <!-- s:? --><img src="{SMILIES_PATH}/icon_confused.gif" alt=":?" title="Confused" /><!-- s:? -->

library/
Antes era lib/ contiene los mismos archivos mail, smarty, excel, etc pero ahora tiene el framework en el directorio kumbia. Asi es mas facil actualizarlo ya que solo hay que reemplazar este directorio-

library/kumbia
Aqui esta el framework.

El archivo kumbia.php contiene la clase Kumbia este archivo era el mismo que estaba antes en la raiz + el archivo forms.php en la misma ubicacion.

En library/kumbia ahora se encuentra un directorio por cada componente del framework.

acl
acl/resource
acl/role
Contiene la version del ACL en desarrollo que se espera terminar y documentar en esta version.

cache/
Contiene el boceto para implementar el componente de cacheo avanzado.

config/
Contiene la clase Config

controller/
Aqui vienen las clases del componente Controller

controller/application
Contiene la clase ApplicationController y sus clases excepciones

controller/builder
Contiene la clase BuilderController y sus clases excepciones

controller/standard_form
Contiene la clase StandardForm y sus clases excepciones

controller/router
Aqui esta la clase enrutadora. He separado la funcionalidad router que antes estaba en la clase Kumbia. Esto hace mas claro el funcionamiento del Front-Controller.

controller/dispatcher
Y Este es el Dispatcher que tambien estaba antes en la clase Kumbia y que he separado para hacer mas claro su trabajo.

db
db/adapters
Contiene los adaptadores de bases de datos habituales.

db/active_record_base
Contiene la implementacion del ORM y sus clases excepciones

db/loader
Es la nueva clase que sirve para cargar el adaptador de base de datos que diga en config/config.ini

exceptions
Es la implementacion de KumbiaException para el manejo de excepciones

flickr
Es la clase para acceder a las fotos de Flickr

generator
Contiene las clases que generan el codigo HTML de StandardForm

helpers
Contiene a tags.php y utils.php antes en lib/kumbia y forms/utils.

logger
Contiene la clase logger y sus excepciones. Esta clase tiene planes de mejoramiento para 0.5.x

messages
contiene la clase Flash

report
Contiene el generador de reportes de StandardForm

security
Contiene la clase Security que implementa algunos metodos de seguridad. Se planea mejorar esta clase.

session
Contiene el tradicional Session, SessionRecord y el Nuevo SessionNamespace de emilio.

Xml
Contiene el SimpleXMLResponse

Cada componente esta separado en un directorio en el cual se implementan las excepciones para manejar los errores.

He documentado gran parte del codigo usando la sintaxis de phpDocumentor con el cual he creado una documentacion del API del framework que esta en los archivos del grupo y en assembla con el nombre de api.zip.

Actualmente no es funcional sin embargo ya se puede ver que es lo que se quiere y hacia donde va el framework..

Invito a la comunidad a debatir los cambios y a proponer nuevos. Antes de empezar a trabajar.

Saludos
«1

Comentarios

  • edited 1:16
    Excelente Andres, gracias por esa invaluable mejora.

    Cada modulo puede necesitar configuraciones independientes, por lo que opino que el directorio Config se debe colocar dentro del directorio App.

    Seria muy conveniente aprovechar la ocasion para eliminar los archivos desactualizados que el Framework ya no emplee, leer este post:
    <!-- m --><a class="postlink" href="http://kumbia.org/foro/viewtopic.php?t=95">http://kumbia.org/foro/viewtopic.php?t=95</a><!-- m -->
  • Listo Roger fue eliminado ese post... y bueno por la otra parte respecto a la version 0.5 creo que comenzamos una nueva etapa y si nos ponemos a ver desde que se creo el foro los avanzas han sido considerables vaya mis felicitaciones a la comunidad...
  • Bueno me alegra que haya gustado el cambio. Ahora ponernos manos a la obra.

    Voy a definir las tareas en el ROADMAP para asignarlas a los desarrolladores y tener esta version cuanto antes.

    Gracias y saludos
  • Queria recordarles que ahora tenemos que tener en cuenta lo siguiente:

    1. Agregar nueva funcionalidad a 0.5.x y la que sea muy importante implementarla para 0.4.x
    2. Cualquier bug existente en ambas versiones debera ser corregido por igual.
    3. Hay que crear un documento para migrar de 0.4.x a 0.5.x, la gente que esta en documentacion (deivinson y powerade1) los invito a empezar a trabajar en ello.
    4. Desarrolladores (roger, emilio.rst, forGET, murilin, phillipo, deivinson, jucorant, irraco) revisar la lista de requerimentos que hay en:
    <!-- m --><a class="postlink" href="http://tools.assembla.com/kumbia/roadmap">http://tools.assembla.com/kumbia/roadmap</a><!-- m -->.
    5. Hay que terminar de pasar el libro de Kumbia al wiki. Los documentadores trabajan en esta parte.

    Asignacion de Tareas:
    He aqui la asignacion de tareas, he colocado a 2 personas a desarrollar el componente por favor hagan contacto entre las 2 y he asignado una tercera para que actue como colaborador y revisor de que los cambios lleven los estandares y que cumpla con los objetivos. Obviamente pueden apoyarse en la comunidad y en mi si tienen dudas

    No hay fechas de entrega pues depende de la disponibilidad de tiempo que tengan.

    Componente de Cacheo Avanzado
    Asignado a Murilin y forGET
    Revisar deivinson

    Pasar el codigo HTML a XHTML y CSS2
    Asignado a phillipo y emilio.rst
    Revisar irraco

    Soporte para Schemas en ActiveRecord
    y modelos que no siguen estandares
    Asignado a Roger y Deivinson
    Revisar jucorant

    Componente Filter
    Asignado a Deivinson y anthemfor182 (me)
    Revisar Roger

    Integrar dhtmlgrid a Kumbia
    Asignado a irraco y jucorant
    Revisar emilio.rst

    Integrar libchart a Kumbia
    Asignado a powerade1
    Revisar anthemfor182

    Listas de Acceso ACL
    Asignado a anthemfor182 y emilio.rst
    Revisar phillipo

    La idea es trabajar junto con la persona asignada, si no se sienten bien con la tarea asignada pueden comentarlo igual si se sienten mas comodos con otra tarea.

    La idea es trabajar poco a poco para ir avanzando. Espero que contemos con el apoyo de todos los aqui nombrados.

    Saludos y gracias
  • edited 1:16
    Bueno como dije, me voy a organizar en buscar un rato cada semana.....

    Animo a todos
  • edited 1:16
    Listo va para esa, cuenten conmigo, hare todo lo posible por cumplir las tareas asignadas con mi compañero.

    Saludos!
  • edited agosto 2007
    OK.

    Por favor moderadores, eliminar este Post.
  • edited septiembre 2007
    tambien este!
  • Bueno si realmente entendi mal sin embargo ese post solo tenia tu comentario... y con esto no justifico el error que cometí...
  • edited 1:16
    Cueten conmigo
  • edited 1:16
    Sang i fetge!! como se dice por aki!!, jejeje, adelante!!
  • edited 1:16
    bueno estoy impresionado con la tarea del director, espero que todos podamos darnos tiempo para desarrollar para hacer Evolucionar el Framework. Para mi sera una experiencia interesante trabajar con gente que me parece con deceos de superacion.
    'El conocimiento es infinito, se asemeja al tiempo... infinito'

    cuentan conmigo....
  • Hola Compañeros

    Como van las tareas, tienen dudas ya realizaron el contacto?

    Saludos
  • edited 1:16
    yo creo que lo mas dificil es empezar.
    Les deceo exitos en sus diferentes tareas.
  • He agregado avances de la reescritura de parte del core al SVN.

    - Clase Dispatcher
    - Esqueleto para la clase Filter
    - Clase Router
    - Reestructuracion de la clase Kumbia
    - Nueva jerarquia de clases:

    Object es la clase padre de las clases del framework:

    ControllerBase
    |--- Controller
    |---- ApplicationController
    |
    BuilderController
    |----StandardForm

    ActiveRecordBase
    |
    ActiveRecord (Modificable por el usuario)

    Ha empezado a desarrollarse una funcionalidad para agregar helpers de usuario que sean cargados automaticamente al iniciar la aplicacion.

    Adicional a esto la posibilidad de crear plug-ins que funcionen encima del core para mejorar la funcionalidad del framework .

    Las excepciones ahora podran ser capturadas en el controladores o en los modelos dependiendo de su naturaleza.

    El avance de Kumbia hacia 0.5 es mostruoso, desde ya se siente la emoción del cambio.

    Saludos
  • edited 1:16
    Hola,

    Entonces ya se puede utilizar la versión 0.5 ???

    ¿De donde a donde se mueve cada cosa al migrar de la versión 0.4x a la 0.5 de Kumbia?

    gracias.
  • Aun no se puede usar esta en alpha todavia pero avanza rapidamente para llegar al beta para poder empezar a usarse activamente.
  • Me parece muy bien que la versión 0.5 ande por buenos pasos, sin embargo pienso que antes de lanzar un beta de esta versión deberíamos alcanzar metas que ha asignado anthemfor182, esto con la idea de no hacer lo mismo que se ha venido haciendo con las versiones anteriores o mejor dicho disminuir eso que se viene haciendo (apagar fuego), ya que esto le quita seriedad al proyecto (yo se que el proyecto es serio), pero imaginemos una persona que llega nueva al framework y se encuentra con que cada semana sale un release nuevo se comienza a perde, es mi opinión, también debemos probar y discutir la versión 0.5 al máximo ya que para esta versión se va a sentir un cambio bien importante en el framework...

    Pienso que con la versión que esta actualmente 0.4.5RC6 se puede trabajar bastante bien, esto dara algo de tiempo para alcanzar estas metas...

    <!-- s:lol: --><img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing" /><!-- s:lol: -->
  • edited 1:16
    Estoy de acuerdo con Deivinson. Lo que no se puede pretender es estando en pleno proceso de revisión y desarrollo sacar una versión Beta cuando la gran mayoria de tareas aun esta en ascuas.

    Mejor sacar una versión 0.5 revisada a fondo y estable que no otra vez lanzar versiones a medias.
  • Lo que pasa es que la version 0.46 esta en beta y la gente insiste en usarla aun hay errores pendientes pero se debe trabajar en solucionarlos para sacar un 0.46 estable final.

    Pienso que muchos de los problemas resultan de no tener un banco de pruebas grande en el cual se puedan revisar los programas, creo que cada uno esta revisando en sus propias aplicaciones pero pienso que las pruebas podrian centralizarse.

    Hace un tiempo propuse desarrollar una aplicacion de ejemplo para la comunidad que sirviera como demo y emblema del framework, tambien para realizar pruebas y encontrar posibles necesidades.

    Pienso que podriamos retomar esa idea y empezar con esta aplicacion.

    En ese momento se propuso crear una aplicacion para crear blogs, un sistema de foros y hasta un bug tracker.

    Esto puede cambiar hoy, solo es debatirlo, pues le dejo a consideracion el apoyo a esta propuesta.

    Por otro lado hay necesidades latentes para la version 0.5 y tareas asignadas en las cuales veo que no hay mucha iniciativa de resolver. Esto es algo desmotivante ya que nuevamente siento la carga de todo el desarrollo del framework.

    Pienso que debe existir un compromiso real con el proyecto para saber con que personas se puede contar y con quienes no. Esto no es algo obligatorio es la colaboracion que cada quien desee dar.

    Antes se decia que el grupo necesitaba un SVN, un foro, un sitio, etc, Todo eso ya esta y sin embargo se sigue en lo mismo.

    Por otro lado, pienso que se deberia centrar todo el esfuerzo en trabajar y entender la version 0.5 para llegar a un mejor producto en el futuro.

    Saludos
  • Por otro lado hay necesidades latentes para la version 0.5 y tareas asignadas en las cuales veo que no hay mucha iniciativa de resolver. Esto es algo desmotivante
    el grupo necesitaba un SVN, un foro, un sitio, etc, Todo eso ya esta y sin embargo se sigue en lo mismo.

    Algo muy cierto todo esto expuesto por Andres, solo exigimos y no ponemos un granito, esto sin ofender a nadie porq tambien es cierto desde que kumbia esta en la comunidad el avance ha sido significativo, la intención es ayudar al proyecto.
    Respecto a la versión 0.5 entonces hagamos algo, vamos avocarnos a solventar los Bug reportados de la versión 0.4.x para generar un stable y si meternos de fondo con la 0.5 es mi propuesta...
    yo estoy utilizando la ultima version 0.4.5RC6 claro hizo falta modificar el metodo find_first pero por lo demás esta bien...

    Otra cosa la propuesta de hacer una aplicación de prueba para el framework es bueno.

    <!-- s:lol: --><img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing" /><!-- s:lol: -->
  • edited 1:16
    Yo apoyo la idea de sacar la version beta, porque creo que basta que haya algo funcional, aunque pequeño en el tiempo se estructurara mejor, esto no quiere decir que la estructura para el 0.5.x este mal, sino que con el el pasar del tiempo puede variar. Tambien me preocupa ya la integracion de xhtml y css tendrian que estar en estas versiones, porque al intercambiar ideas para trabajar sobre este tema creo que apuntan a la version 0.4.6 rc y creo que como sugirio Andres la inclusion del xhtml y css3 seria para la 0.5.x y para la concrecion del mismo tendria que haber algo funcional que aunque sea minimo realmente podriamos avanzar mucho mas en este y otros temas.
    Tb si es buena la idea de un demo que sea el standarte, pero creo que hacer un ejemplo en conjunto sera un poco dificil, al menos que ya tengan estructurado y definido un tema que sea lo necesariamente importante. Sobre este tema yo sugiero que tal ves para ser practicos hagamos una especie de concurso en la comunidad para el desarrollo de diferentes aplicaciones. Pero se tendria que generar un temario de que tipo de aplicaciones seran validas y permitir un numero limite d participantes para cada tema, a fin de que los temas no se queden sin concursantes. YBUENO... si manejan esta idea con criterio diferencial hasta podriamos obtener una gran aplicacion conjunta.
    Espero nos podamos definir pronto y me da mucha pena que Andres se sienta con todo el peso de desarrollo del framework otravez; en sus palabras textuales. espero que este tema se supere pronto y todos realmente ayudemos...
  • edited 1:16
    Como lo he dicho en repetidas ocasiones, creo que es conveniente centrarse en la corrección de los bugs que hay (que son bastantes, como es lo normal en un producto nuevo), y luego si dedicarse a la nueva versión y las nuevas funcionalidades.

    La verdad esa "manía necesaria" de querer siempre ampliar la funcionalidad del framework descuidando las que ya existen, siempre me ha parecido errónea y entiendo perfectamente que todo esto es producto de las exigencias del publico; no obstante, "hay que saber cuando detenerse y mirar atrás".

    Ha llegado el momento de mirar atrás y corregir muchas cosas, que si no, podrían ser catastróficas.

    Estoy dispuesto a seguir participando (aunque mal de tiempo como la mayoría, por no decir todos) en el mejoramiento continuo de este Prospero Framework.
  • edited 1:16
    Tienes razon roger, cuando comence a interactuar con esta gran comunidad, tambien habia sugerido eso, hay que hacer que kumbia sea estable a toda costa y luego lo ponemos bonito (por asi decirlo).

    Aunque me gusta bastante la nueva estructura de directorios y estoy ansioso por trabajar con kumbia 0.5, pero hay que aguantarse.

    Saludos.
  • edited 1:16
    Bueno, lo que veo es por los comentarios de unos y otros, un descontrol brutal. Hay cosas relativas a bugs, otras a mejoras, pero lo de hacer una aplicación común con una versión x de kumbia creo, como he comentado en el post abierto, seria de gran utilidad para la revisión y publicación de una versión estable.
  • debemos ponernos de acuerdo para seguir con el avance del framework las propuestas son muy buenas pero como lo pueden ver somo pocos y debemos dar prioridad, comparto con roger esto.
    Ha llegado el momento de mirar atrás y corregir muchas cosas, que si no, podrían ser catastróficas.
    Es importante corregir lo que existe actualmente del framework sin agregarles cosas importante solo corregir Bug y a partir de alli darle con todo a la version 0.5 ya que sino seguiremos siendo unos apaga fuego estamos conciente que nos rodea una público exigente y que cada día quiere cosas nuevas en el framework pero deben esperar...

    Exito...
  • edited 1:16
    Me parece exelente de sacar una version sin bugs, pero en si hasta que punto, porque la verdad un poco me confunde, que tiempo nos tomaria...
    Reflexiono y pienso que es verdad de que tb es necesario una version del 0.5.x beta, pero tb esta la necesidad de una version 0.4.x en perfecto funcionamiento. Creo el hecho ya tener conociemiento de contar con la version beta hace que nos presipitemos un poco o mucho, la verdad no se, en cierta manera manera cierto tipo de informacion deberia ser mas restricta, haci se evitaria un poco las exigencias de los usuarios.
    Me encantaria que el director del proyecto haga una seria reflexion y nos encamine a todos y que rumbo vamos a tomar todos.

    saludos a todos.
  • En cuanto a la version sin bugs: La version 0.4.6 esta destinada a ser la proxima version estable si bien hay cosas que no funcionan como se espera y eso significa que el framework no soporta "x" o "y" componente.

    Pienso que los bugs detectados no son muchos. menos de 5? no hay que crear un alboroto por esto.

    La version 0.5 realiza cambios que necesita el framework. Por lo tanto es necesario llevar todo el desarrollo nuevo a ella.
  • Bueno entonces cual sera el siguiente paso? que bug quedan pendiente de la version 0.4.X? para ponerla como stable y comenzar con la version 0.5...!
  • De momento se de un bug en el confirm del link_to_remote, no se de mas?

    Donde estan los bugsss?

    Pienso que los avances al framework pueden llegar a ser mas sencillos, pero simplemente no los hacemos.

    - Por ejemplo si todos los dias postemos aqui muchos mensajes que nos cuesta durar 3 min mas y llevar al menos una pagina del libro al wiki.

    - ¿O escribir un ejemplo y llevarlo al libro?

    - o agregar 10 lineas de codigo para arreglar un bug

    - o escribir 3 lineas de un mail y contactar a la persona con la que tenemos que realizar las tareas para empezar

    - o empezar las mismas tareas con 15 o 20 lineas de codigo diarias

    Aportar es mucho mas facil
Sign In or Register to comment.