¡Hola Forastero!
Pareces nuevo por aquí. Si quieres participar, ¡pulsa uno de estos botones!
Categorías
- 1.6K All Categories
- 83 Noticias, Anuncios e Información
- 244 Zona de presentaciones
- 369 Dudas/Problemas
- 12 FAQ
- 70 Versión 1.0 Spirit
- 23 Beta1
- 44 Beta2
- 592 Aplicación y Uso del Framework
- 430 Principiantes
- 64 Generadores de Formularios
- 91 (M)odels, (V)iews, (C)ontroller
- 188 Desarrollo del Framework
- 92 Bugs y Problemas
- 53 Nueva Funcionalidad y Sugerenc
- 36 Desarrolladores
- 6 Documentación
- 38 Programación (no relacionado)
- 3 Xhtml y css
- 13 PHP
- 7 Javascript
- 9 SQL y RDBMS
- 25 Tema Libre
In this Discussion
Kumbia 0.5 alpha
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
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
Comentarios
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 -->
Voy a definir las tareas en el ROADMAP para asignarlas a los desarrolladores y tener esta version cuanto antes.
Gracias y saludos
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
Animo a todos
Saludos!
Por favor moderadores, eliminar este Post.
'El conocimiento es infinito, se asemeja al tiempo... infinito'
cuentan conmigo....
Como van las tareas, tienen dudas ya realizaron el contacto?
Saludos
Les deceo exitos en sus diferentes tareas.
- 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
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.
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
Mejor sacar una versión 0.5 revisada a fondo y estable que no otra vez lanzar versiones a medias.
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
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
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...
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.
Aunque me gusta bastante la nueva estructura de directorios y estoy ansioso por trabajar con kumbia 0.5, pero hay que aguantarse.
Saludos.
Exito...
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.
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.
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