Este es un error que no se esta manejando desde el core,
Notice: Undefined variable: titulo in D:\xampp\htdocs\kumbia\default\app\views_shared\templates\sbadmin.phtml on line 36

La variable $scaffold aparece en Controller pero no se usa para nada, debería ser eliminada.

Una vez instalado correctamente kumbiaphp en mi hosting y usando un subdominio solo se muestra correctamente la pagina principal y las demas vistas se muestran solo con el contenido del template, sin cargar correctamente el contenido de la vista asignada por el controlador ni los archivos css, js, jpg etc.

El mod_rewrite esta activado y realize una modificacion en mi archivo public/index.php en la linea 83 con la direccion de mi subdominio y no soluciono el problema define('PUBLIC_PATH', 'sub.dominio.com');

El problema no se genera cuando estoy dominio regular www.dominio.com

De antemano Gracias por su poyo y ayuda, estare atento a cualquier apoyo que puedan brindarme.
Saludos

Como se puede ver en el metodo post no se hace el mismo filtrado que el get
https://github.com/KumbiaPHP/KumbiaPHP/blob/master/core/libs/input/input.php

Lo que podría hacer que se hagan peticiones malintencionada que comprometan la aplicación

Buenas, quisiera comentarles sobre que opinan de cambiar la forma en como se crean los elementos con estos helpers para tener funcionalidad javascript, actualmente, lo hacen por medio de clases especificas, ejemplo:

Ajax::link($action, $text, $update, $class=NULL, $attrs=NULL)
{
if (is_array($attrs)) {
$attrs = Tag::getAttrs($attrs);
}
return '<a href="' . PUBLIC_PATH . "$action" class="js-remote $class" rel="#{$update}" $attrs>$text";
}

Este metodo crea un link con la clase js-remote para luego en el jquery.kumbiaphp.js hacer un selector a esa clase.

Me parece que pudiesemos cambiar el uso de clases para los selectores al uso de atributos data-* , con eso nos evitamos el que esos metodos tengan un parametro $class, y serian mas parecidos a sus metodos equivalentes originales como el Html::link().

Entonces el metodo podria quedar algo así:

Ajax::link($action, $text, $update, $attrs=NULL)
{
if (is_array($attrs)) {
$attrs = Tag::getAttrs($attrs);
}
return '<a href="' . PUBLIC_PATH . "$action" data-ajax-link="true" rel="#{$update}" $attrs>$text";
}

y los selectores en el js se adaptarian a la nueva forma $("a[data-ajax-link]")...

Quizas para esta versión ya no sea recomendable el cambio, pero para futuras versiones pudiera implementarse.

Saludos....

Hola chicos alguna iniciativa para agregar soporte a composer?

En la linea 89 del archivo core/libs/db/db.php estan haciendo una asignación y no una comparación.

Saludos

Una pregunta, el método Router::redirect() no tiene un die ó exit en su interior por alguna razón en especial ?

La única razón por la que pienso que pueda no tenerlo es para que se pueda ejecutar algún proceso antes de la re dirección, pero no se si realmente alguien trabaje en el framework con esa forma, es decir, llamar a Router::redirect() y luego ejecutar algun proceso php como guardar estadisticas de visitas, algun registro a la bd, etc...

En el framework usamos la hoja de estilo style.css que contiene reglas css específicas para kumbia. Personalmente creo que sería mejor cambiar su nombre por kumbia.css.

Buenas.

Propongo que el repositorio del proyecto sea dividido en dos repositorios, uno para el core de las aplicaciones y otro para el default, donde el ultimo tendrá contenido al core pero como un submodulo git. con esto podremos actualizar nuestro core en aplicaciones git sin necesidad de que las demas carpetas del proyecto se vean afectadas.

Ademas podremos añadir la posibilidad de descargar el core y posibles modulos con la herramienta de manejo de dependencias composer.

No existe un método que permita incluir Javascript tal como se hace con los Meta, los Link y los CSS. Debería seguirse la misma convención para estos.

Estoy trabajando con el helper form, creando unos input text, Form::text("campo",NULL,'valor por defecto');

Asignandole un valor por defecto al mostrar el input, el mismo puede ser reemplazado por el usuario al ingresar sus datos.

Hasta aqui todo bien. ahora me esta pasando que si el usuario ya tenia info guardada y la quiere editar, en dicho campo deberia aparecer el valor que el tiene guardado en la bd, pero está apareciendo el valor que paso como parametro al metodo,
es decir, tiene mas relevancia el valor que se pasa como parametro que el que se pasa por autocarga, ya sea desde $_POST ó desde el controller.

Ahora la cuestión es, trabaja así intencionalmente ó no se habia dado el caso ?

Será recomendable cambiar la relevancia ? para poder tener valores por defecto en el input, pero que tengan mas importancia los de autocarga ?

Este cambio para la 1.2 final lo debemos hacer ahora o ya no podremos mas adelante.
En la beta2 final seguirá como antes.
Es muy fácil cambiar ese método, un encontrar y reemplazar en la carpeta de controllers.

En /libs/auth/auth.php ( linea 289 )
/**
* Obtiene un valor de la identidad actual
*
* @param string $var
* @return string
*/
public static function get($var = '') {
if ($var) {
return $_SESSION['KUMBIA_AUTH_IDENTITY'][Config::get('config.application.namespace_auth')][$var];
}
}

el return deberia ser

return (isset($_SESSION['KUMBIA_AUTH_IDENTITY'][Config::get('config.application.namespace_auth')][$var]) ? $_SESSION['KUMBIA_AUTH_IDENTITY'][Config::get('config.application.namespace_auth')][$var] : null);

Alguien ha usado la consola?
A mi me ha dado unos cuantos problemas

No hay archivo config.ini para consola
PHP Warning: parse_ini_file(/home/beto/www/venepago/core/console/config/config.ini): failed to open stream: No such file or directory in /home/beto/www/venepago/core/kumbia/config.php on line 106

No existen los directorios "models" ni "controller", por tanto no se ejecutan los comandos

hay que cambiar el nombre de la variable $checkValue a $radioValue en la linea 431, ( 432 en github).

ya que el parametro es $radioValue y no $checkValue...

pongo el issue porque tengo unos commits que pienso que es mejor que no se pasen en el pull.

Que opinan de colocar un parametro en el metodo content de la lib View, con la finalidad de poderle decir al mismo que no queremos imprimir el contenido, sino que queremos almacenarlo en una variable.

Esto da la posibilidad de por ejemplo trabajando con librerías que exportan html a pdf le pasamos a dichas libs el contenido html simplemente haciendo algo como $pdf->setHtml( View::content(FALSE) ); con lo que el contenido en el buffer no se imprimiría sino que seria devuelto y almacenado en el pdf.

No se para que otros caso pudiese ser util, espero comentarios :-)

La librería Auth2 no permite configurar el salt, asi que la contraseña puede ser obtenida en una tabla hash publica.

Estimados, estaba revisando el código para hacer un rest básico y me encuentro con lo siguiente:

Cuando creo un controller y agrego un metodo public function get($id) veo que que el archivo kumbia_rest.php en la línea 102 almacena el action name (en este caso es get) luego en la 103 obtiene el action del controller (también get) y en la 104 la reescribe como get_get. Pregunta estoy haciendo algo mal o es un bug en la línea 104 al poner $rewrite = "{$method}_{$action}";

Otra cosa, como hago para que defina un input y un output por defecto en el controller? lo único que he podido hacer es un View::select(NULL, 'json'); mas no un uso de la variable $_fOutput

Me estaba guiando por este ejemplo: http://wiki.kumbiaphp.com/Ejemplo_Rest

Gracias!

Cordial saludo,
mirando el link http://wiki.kumbiaphp.com/Ejemplo_Rest mi idea es trabajarlo con json
he estado haciendo prueba con el Get, Getall y Post , he notado que si lo veo desde el navegador este me nuestra un error

This page contains the following errors:

error on line 2 at column 1: Extra content at the end of the document
Below is a rendering of the page up to the first error.

Warning: get_class() expects parameter 1 to be object, string given in /default/app/views/_shared/templates/xml.phtml on line 10

veo es q se esta mostrando es la plantilla xml.phtml como hago para indicarle que necesito la plantilla json.phtml.

La idea es crear una clase que implemente Iterator ó IteratorAgregate para devolver en el paginado en vez de stdClass https://github.com/KumbiaPHP/KumbiaPHP/blob/master/core/libs/kumbia_active_record/behaviors/paginate.php#L83

Así se resuelve el hecho de tener que usar el $result->items para recorrer los registros en la vista, en este caso con foreach($result as $item) seria suficiente, y se logra recorrer resultados con o sin páginar de la misma manera.

Saludos!

Buenas,

he querido usar el sistema de etiquetas meta bajo la versión KumbiaPHP Spirit B2 y me da error.

El código PHP usado es:

y el resultado devuelto:

Notice: Array to string conversion in D:\Users\Phillipo\Documents\Webs\ServidorWeb\abridgetotheholyland.org\core\extensions\helpers\html.php on line 152
Array

Está copiado directamente de la wikipedia de kumbiaphp.

http://wiki.kumbiaphp.com/KumbiaPHP_Framework_Versi%C3%B3n_1.0_Beta2#Html::meta.28.29

¿Les parece buena idea agregar la opción de instalar vía Composer ?
Hay que arrancar registrando el framework en Packagist.
Si les parece buena la idea me gustaría colaborar!

Saludos!

Al intentar usar este helpers nos da un "Notice: Array to string conversion in /XXX/XXXX on line XX", la implementación del helper debieria ser algo como Html::includeHeadLinks para resolver el inconveniente, de todos modos ya en mi Fork de KumbiaPHP con el commit
36e2ef5

Buenas, hace unos dias hice un cambio en la lib kumbia_active_record:

95ddaaa

La cual permite realizar asociaciones entre modelos que estan dentro de carpetas en app/models, ejemplo

app/models/admin/usuarios.php. un modelo puede estar relacionado con usuarios de la siguiente manera:

$this->belongs_to('admin/usuarios');

Sin embargo ahora debemos tener cuidado ( y buscar la manera de corregirlo ) al crear un scaffold hacia dicho modelo, ya que estamos usando el valor del atributo $model del controlador para crear una variable:

https://github.com/KumbiaPHP/KumbiaPHP/blob/dev/default/app/libs/scaffold_controller.php#L38

Y si el valor de $model es por ejemplo: 'admin/usuarios' , al intentar crear una variable $this->{'admin/usuarios'} nos dará un error de php. Ademas lo mismo pasará en la vista:

https://github.com/KumbiaPHP/KumbiaPHP/blob/dev/default/app/views/_shared/scaffolds/kumbia/crear.phtml#L6

Una posible solución sería tener un nombre estatico para la variable que pasa a la vista en el scaffold, por ejemplo

$this->object

Quedo a la espera de comentarios, Saludos...!!!

Buenas, estoy haciendo pruebas cacheando un template, el controlador que se está cacheando esta protegido por logueo.

cuando entro logueado todo perfecto y se cachea la vista y el template.

pero si cierro sesion y escribo la url que se cacheo, me muestra la pagina sin problemas ( cuando me deberia pedir que inicie sesion, como cuando no está cacheada ), ya que en produccion si una url está cacheada por template, no se ejecuta el fw sino que solo se manda lo que esté en cache.

No se si esto ya se tiene en cuenta, tampoco es que sea razonable cachear una url que esté protegida, al menos cachear todo el template.

Creo que es algo que se debe discutir para tratar de resolver.

Estuve leyendo algo de Yii y me pareció super internaste, lo de crear un modelo o un controlador por ejemplo, en Yii se hace con una interfaz web, y en KumbiaPHP se hace en consola.
Se puede implementar que estas consolas pasen a tener interfaz web, y también que se pueda configurar los .ini (config, dqatabase, routes) con una GUI web, lo último surgió como sugerencia de un participante en la última capacitación que di.

CUando se da un error de modelo no encontrado se intenta incluir un archivo que no existe

Hola, Me pasó lo siguiente, estaba verificando el método "to" de la clase redirect y me dí cuenta que allí se llama View::select(null, null), lo quise hacer en un método de un controlador y el renderizado de las vistas se comporto de una forma extraña después de esto, sólo salía el HTML sin el template base, incluso en otras vistas no aparecía el HTML completo.

Especificaciones de Entorno:

Windows 7
XAMPP Server
PHP 5.4.7

Actualmente, la función Util::get_params de la línea 298 es Util::getParams. Se debe rectificar.

Que opinan de en vez de que en public/index.php se pueda elejir entre cargar el bootsrap del core ó el de app/libs,
el bootstrap del core lo incluya automaicamente (luego de iniciar el autoload y antes de llamar al Router::execute()), asi, tendría más utilidad porque ya estaria cargada la config del core, como el autoload y las excepciones.

porque como está orita realmente no se puede hacer mucho ya que para usar alguna lib del core en el bootstrap de app, hay que cargarla manualmente.

El uso de las librerias Mysql deben ser deprected, de ser posible eliminar y hacer una migración transparente a Mysqli

Hace tiempo que está en la wiki un cambio ó caracteristica nueva, pendiente de agregar al Framework, y es la de tener la posibilidad de trabajar con mini apps en el mismo: http://wiki.kumbiaphp.com/Cambios_Pendientes_Spirit#Recordar "Crear boceto para sistema de plugins(mini apps) ".

Pudiesemos colocar por acá que ideas tenemos con respecto a este punto, ya que me parece muy interesante e importante esta posibilidad, debido a que será mas facil crear funcionalidades empaquetadas que podremos adaptar a cualquier proyecto :-)

Buenas, estoy insertando manejo de eventos en diferentes partes del fw

https://github.com/manuelj555/KumbiaPHP/commit/b975d8516cb7e326bbd5ed46a230c29a78aa7062

https://github.com/manuelj555/KumbiaPHP/commit/98e7a59783cd9861d5c0a622cd8f3bdbd2ce2d93

Esto con la finalidad de poder ejecutar ciertos hooks en determinados momentos del sistema, al realizar un query por ejemplo.
para llevar auditorias, extender excepciones, tambien se le pasan al before y el after de la lib upload.

Que piensan ? seria bueno integrar estos manejadores de eventos al fw.

Esta idea inició con la necesidad de poder capturar los queries y el tiempo que tardan en ejecutarse en una petición, para hacer un debug para el fw.

Eliminar todos los métodos y clases deprecated.
También el scriptaculuos.js

Tenemos la función cUpdaterselect en la cual se toma por hecho que TODOS los select que se creen con esta función, tendrán como atributo ID el valor 'id' lo cual es impráctico, dado que cada select que creemos tendrá su propio valor de ID. No me actualiza el valor correctamente, si no es que en mi select ponga dicho valor en ese atributo. De momento podría proponer usar el código del anterior kumbia el cual es más reducido y funcional.

//Código en cuestión
cUpdaterSelect: function(event) {

   var $t = $(this),$u= $('#' + $t.data('update'))
url = $t.data('url');
   $u.empty();
        $.get(url, {'id':$t.val()}, function(d){
            for(i in d){
                var a = $('<option />').text(d[i]).val(i);
                $u.append(a);
            }
        }, 'json');
    }

Código propuesto:

cUpdaterSelect: function(event) {

        var este = $(this);
        $('#' + este.attr('data-update')).load(este.attr('data-url') + this.value);

}

Evitando utilizar código javascript como hago a menudo, he decidido investigar el helper ajax para poder en mi vista cargar un formulario mediante Ajax::link() y luego ese formulario enviarlo mediante Ajax::form().

Pero me encuentro con el siguiente problema, la librería jquery.kumbiaphp.js hace el bind del submit del formulario una vez que el DOM está cargado, utilizando $("form.js-remote").on('submit', this.cFRemote);
Con lo cual, si mi formulario es cargado por ajax nunca va a enlazar el evento submit del form.

Para esto sugiero utilizar .on() [http://api.jquery.com/on/] fuera del $document(ready) y así realizar el enlace en forma dinámica y solucionar el problema.
Ej:
$(document).on("submit", "form.js-remote", this.cFRemote);

Ver la posibilidad de implementar alguna herramienta de generación automática de modelos a partir de una base de datos existente.

La variable $schema declarada en el método describe_table debe estar inicializada en public, debido a que el manejador de base de datos crea este schema por defecto. La solución sería:

 public function describe_table($table, $schema='public'){

Además falta incluir esta variable dentro del sql de las línea 519. El sql podría quedar así:

SELECT a.attname AS Field, t.typname AS Type,
CASE WHEN attnotnull=false THEN 'YES' ELSE 'NO' END AS Null,
CASE WHEN (SELECT cc.contype FROM pg_catalog.pg_constraint cc
WHERE cc.conrelid = c.oid AND cc.conkey[1] = a.attnum LIMIT 1)='p'
THEN 'PRI' ELSE '' END AS Key, a.attnum
FROM pg_catalog.pg_class c, pg_catalog.pg_attribute a, pg_catalog.pg_type t, pg_catalog.pg_namespace x
WHERE c.relname = '$table'
AND c.oid = a.attrelid
AND c.relnamespace = x.oid
AND a.attnum > 0
AND x.nspname = '$schema'
AND t.oid = a.atttypid order by a.attnum

Saludos.

Buenas.

La idea es que la v2 de KumbiaPHP, implemente la Inyección de Dependencias correctamente, para así poder tener clases realmente desacopladas y cambiables (De manera sencilla) en todo el framework como tal.

Una herramienta excelente para dicha implementación es el Container de Symfony (no he visto mejor lib), el cual permite registrar clases y sus dependencias, y luego el se encargará de resolver las mismas, quitandonos dichas tareas.

Acá se habla más extensamente del tema:

http://gitnacho.github.io/symfony-docs-es/components/dependency_injection/introduction.html

SOLID

Realmente sus ventajas son muchas, primero nos permite trabajar realmente usando el principio de SOLID al no tener que depender de tantas clases estáticas en el FW, lo cual sabemos, aveces nos complica reescribir y extender las mismas (y más aun con la implementación de namespaces), con un container esto no sería problema alguno.

Inversión de Control

Además, permite que las clases no se deban encargar de la creacion/gestion de otras clases y recursos, sino que es el contenedor el encargado de hacer llegar las dependencias a cada clase.

Extension

Es muy facil agregar/reescribir clases al contenedor, lo que permitirá añadir funcionalidades (Mailer, Log, PDF, XLS, etc...) de manera sencilla en los proyectos, dichas libs no dependerán de clases como la Config::get() para leer parametros de configuracion, ni habrá que configurar las libs manualmente en la App (crear la instancia cada vez que se necesite y configurarle los parametros, o tener que crear una clase Singleton que cree la instancia configurada :-/).

Cambio de Clases

Seria facil cambiar por ejemplo el router a usar, por otro que queramos (algo que no se ha podido implementar actualmente).

Menos dependencias

No dependeriamos de constantes como PRODUCTION o APP_PATH, ya que serian parametros del contenedor, y se podrian facilmente pasar a las clases que registremos en el mismo.

Por ejemplo ahora mismo el nuevo AR depende de la constante APP_PATH para leer la config de conexion a BD, algo que dificulta su uso fuera del contexto del FW.

Esas son algunas de las ventajas que desde mi punto de vista obtendriamos al implementar el componente.

La clase Auth no hace comprobación si existe el indice antes de enviarlo

public static function get($var = null)
{
    if ($var) {
        return $_SESSION['KUMBIA_AUTH_IDENTITY'][Config::get('config.application.namespace_auth')][$var];
    }
}

Por lo que en caso de no existir se obtiene un warnig

Al usar el método Form::hidden de la siguiente manera:

debería devolver

pero devuelve

El problema, creo yo, es que el parámetro $value entra en conflicto cuando dentro de dicho método existe:

extract(self::getFieldData($field, $value), EXTR_OVERWRITE);

La session_start deberia estar en la lib Session, no en necesario iniciar session en cada petición.

Fatal error: Call to undefined function getCache() in COREGIDO

if (PRODUCTION && $type === 'view') {

•        return getCache(); //TRUE si está cacheada
  

•        return self::getCache(); //TRUE si está cacheada
   }
  

https://github.com/KumbiaPHP/KumbiaPHP/pull/188/files

Seria bueno crear una variable que defina el template por defecto, desde el config.ini

Luego de probar con la aplicación en OS X y con Windows, y habiendo descargado desde cero el repo, creo que hay un problema al cargar datos con el Form helper.
Los elementos tal como los estoy trabajando están en los siguientes PasteKu
Controller: http://kupaste.com/ver/240774
Model: http://kupaste.com/ver/240775
Vista edit: http://kupaste.com/ver/240776
Sql de la tabla:
CREATE TABLE categoria (
id int(11) NOT NULL AUTO_INCREMENT,
nombre varchar(45) DEFAULT NULL,
icono varchar(45) DEFAULT NULL,
PRIMARY KEY (id) )
Configuración en Windows:
Apache/2.2.22 (Win64) mod_ssl/2.2.22 OpenSSL/1.0.1c PHP/5.3.13

Buenas, estoy pensando en ver si se puede integrar el manejo de eventos durante la ejecución de una peticion en el fw.

Más o menos estos son los eventos que se me ocurren por ahora ( no se si sean los nombres correctos):

Events::beforeController

Será un evento que se disparará antes de instanciar al controlador (puede recibir la url actual que se está procesando, habrá que ver), puede no devolver nada, con lo que la ejecucion de la petición seguirá normalmente, ó puede devolver un array con nuevas especificaciones a usar, por ejemplo: cambiar el controlador a llamar, cambiar la acción, los parametros, etc.

Events::beforeView

Se ejecutará justo antes de llamar a la vista, recibirá las variables que vienen del controlador y podrá devolver nuevas variables, ó las mismas con valores diferentes, tambien se podrá usar para reemplazar las vistas del fw, por ejemplo para usar gestores de plantillas.

Events::onException

Se llamará al haber una excepcion, recibirá la excepcion, y puede usarse para registrar excepciones en la bd, en archivos .log, ó mostrar excepciones distintas para la app.

Events::beforeQuery

Justo antes de ejecutar una consulta a una base de datos, ( puede recibir el SQL a ejecutar ó algun objeto de bd, con el SQL a ejecutar sonpongo que estará bien ).

Events::afterQuery

Justo despues de ejecutar la consulta, resivirá resivirá la consulta.

Por ahora con eso supongo que estaria bien.

Pienso que hacen falta los eventos para tener un mejor control del recorrido de una petición, ya que por ejemplo para usar gettext debemos colocar el codigo inicial en el AppController, pero hay aplicaciones donde tenemos mas de un controlador padre, ejemplo AppController para paginas publicas y AdminController para paginas con seguridad, entonces debemos ingeniarnosla para tener el gettext siempre en funcionamiento.

Ademas incorporar un debug para el fw sería mas facil, al menos en cuanto a registrar los queries que se ejecutaron en una peticion.

y Bueno lo de poder trabajar con gestores de plantillas ó alguna metodologia de vistas distintas a las que vienen por defecto en el fw.

Espero que les agrade la idea, ó que al menos sirva de iniciativa para alguna idea mejor :-)

Saludos...!!!

Se pueden agregar más métodos a la clase input, con información de la petición, por ejemplo el método de la misma (POST, GET, PUT, etc), el formato ( text/html , json , etc ), y bueno si se les ocurren otros útiles, se anotan por acá :-)

Ocurre el siguiente error al intentar autenticar un usuario utilzando una base de datos oracle:

"Fatal error: Declaration of DbOracle::limit() must be compatible with that of DbBaseInterface::limit()"

Esto ocurre debido a que se presenta una incongruencia entre la interface que implementa la clase DbOracle donde utiliza una función limit con dos parámetros de entrada y en la interface solo tiene un parámetro.

El error se lanza al intentar ejecutar "if (!include APP_PATH . "models/$model.php") " en la linea 78 del archivo load.php.

Es posible efectuar varias alternativas para dar solución a este inconveniente, una de ellas se expone en el foro de kumbia (http://foro.kumbiaphp.com/discussion/1309/trabajar-con-oracle/p1), pero hasta el momento no veo que exista una opción valida ofrecida por kumbiaphp.

Por favor revisar este error para dar una solución que nos permita solventar este pequeño percance y que podamos utilizar este framework con oracle sin ningún inconveniente.

Saludos.

Hola, he estado realizando unas pruebas con esta DB y tengo un error en esta linea de código
public function limit($sql, $number) del adaptador PDO de informix, momentaneamente lo he solucionado agregando un valor por defecto al parametro number, algo asi como esto public function limit($sql, $number=10).