ppazos / yupp Goto Github PK

Si la clases A, B y C:

A hasMany B
C extends B
B belongsTo A

a: A, c: C
a.addToBs( c )
a.save() // no guarda c en cascada y deberia porque B belongsTo A y C extends B.

Que las clases del dominio tengan filtros, similar a las restricciones, pero 
que en lugar de verificar valores, modifique estos valores.

Ejemplos:

addFilter(field, Filters::stripslashes()) // Saca las \ del campo
addFilter(field, Filters::trim()) // Saca espacios al inicio y al final del 
campo

etc...

Ideas:

- formateos de fechas y otros datos que necesitan formato, p.e. correccion de 
valores ingresados por el usuario de dd/mm/aaaa a aaaa-mm-dd
- remover caracteres indeseables
- cortar strings largos (p.e. que se pasen de una restriccion maxLength)
- sustituir valores, p.e. si el valor que viene es '', poner NULL en el campo.

Los filtros se aplicarian en los setField(value)

Idea: AntiFilter, lo mismo que el filtro pero al revés, al hacer getField(), 
que el valor cambie a uno esperado por el usuario, p.e. las fechas que se 
guardan como aaaa-mm-dd, que se pongan en formato dd/mm/aaaa.

Ver que errores puedeb ocurrir al hacer un pedido al framework y devolver 
el error correcto en el codifo HTTP. Esto es para acercarse a los servicios 
REST.

Por ejemplo:

set_error_handler('flash_error_handler');

function flash_error_handler() {
header('HTTP/1.1 500 Internal Server Error');
return false;
}

Existe un archivo de configuración del frameowork, pero muchas veces se 
necesita configuración particular para los componentes.
La idea sería hacer un archivo de configuración por componente, que se cargue 
automáticamente al acceder al componente, y que si en este se redefinen 
variables de la configuración del framework, estos valores sean tomados en 
lugar de los que aparecen en la config del framework, así se logra una carga 
de configuraciones en cascada y flexibiliza la configuración de distintos 
componentes, por ejemplo si un componente trabaja con una base de datos y 
otro con otra.

Tanto en la clase YuppConventions.tableName como en 
DatabaseNormalization.table (DAL.php) se define la convencion de nombre de 
tabla.

Ver cual se usa y cual no, sacar el que no se usa.

Para enviar emails, como adaptador de las funciones de PHP, capturar errores, 
hacer logs, preconfiguracion (p.e. sacar mail del adminsitrador de la config), 
etc.

REF: #14

Modificar las APIS? de Database? DatabaseMySQL? DAL? para que las
operaciones puedan hacerse con transacciones (con BEGIN y COMMINT/END de SQL).

Esto sirve para si en el medio de un salvado de un modelo complejo hay un
error, que no se salve medio modelo y quede la base inconsistente.

Cuando se esta en modo prod, las funciones de desarrollo como crear tablas 
deben estar protegidas. Si se intenta acceder a estas ingresando una url, 
deberia mostrar un prompt de autenticacion, si esto falla tirar>

header("WWW-Authenticate: Basic realm=\"$realm\"");
header("Status: 401 Unauthorized");
header("HTTP-Status: 401 Unauthorized");

Esto implica que los administradores del framework deben estar regsitrados en  
la base, y esto sería parte de la suite de administración del framework.

Tenemos Helpers y DisplayHelpers, unirlos en Helpers y que todos se puedan
llamar con el acceso corto h();

Esto se podria hacer mas ordenado mediante la inclusion ocntrolada de JS a la
vista, o sea, diciendole a la vista que JS se va a usar, en lugar de
incluirlo aca como un string simple que se pega en la pagina. Ahorraria
codigo y la inclusion de JS es mas ordenada. Idem para YUI Calendar,
NiftyCorners, Prototype, etc.

Esto permitirá saber quien es el autor, la versión y toda la información 
necesaria para poder instalar el componente como una app en yupp.

Alguna otra info útil sería la de dependencias de otras apps o de plugins, 
como para chequear en la instalación.

Puede estar relacionado con el ticket #34 de agregar configuracion por 
componente, ya que capaz que el app descriptor esté adentro de la config, pero 
hay que analizarlo bien, ya que la config es php y el descriptor la idea es que 
sea algo declarativo como para poder consumir facilmente.

ahora esta en /core/config y deberia estar en /config

Verificar donde se usa, si la funcionalidad que contiene ya está en otra 
clase o debería estar, si no se usa y la funcionalidad ya está contemplada en 
otra clase, eliminarla del framework.

REF: TICKET #7

Agregar soporte para listas, conjuntos y conjuntos indizados (mezcla de
ambos). Esto es para mantener los valores de los objetos asociados por hasMany.

Si es una lista, los objetos se guardan en el mismo orden en el que son
ingresados en la lista, para esto es necesario agregar una columna en la
tabla de la asociación que guarde el indice, así cuando se cargan estos
objetos, dicho orden es respetado.

Si es un set, básicamente lo que se hace es verificar si el objeto no esta
ya presente, o sea, no permitir el ingreso de objetos repetidos. Para
chequear igualdad de objetos se puede hacer primero por el id y el tipo, y
si no tiene id, uso el === de PHP, o tal vez deberia comparar los punteros,
pero solo los tengo si me pasan las cosas por referencia, si no son copias
de estos...

Por ultimo, si es un conjunto indizado, aparte de chquear repetidos, guardo
el indice.

Ahora el mensaje de error se arma en base al contexto para dar una idea de 
los errores que ocurrieron al validar una instancia de PO, pero estos 
mensajes estan orientados al programador no al usuario final.

Para poder presentar errores al usuario final el programador debe manejar 
estos mensajes de error de alguna forma y mostrar un mensaje amistoso al 
usuario.

El objetivo de este ticket es poder crear mensajes, que puedan ser 
presentados al usuario, directamente en al validación. Aparte estos 
mensajes deben ser i18n.

La solución es generar una estructura donde se almacene el contexto de la 
restricción que no se cumple (campo, valor que viola la restricción, etc), 
y por el tipo de la restricción se genera una key i18n para marcar ese 
error. Luego alguien (por ejemplo un helper) procesa esa key i18n y con el 
contexto de la estructura, arma un mensaje para mostrarle al usuario. Esto 
requiere implementar i18n paramétrico, o sea que permita inyectar valores 
en textos i18n para contextualizar el mensaje a mostrar.

http://localhost:8081/YuppPHPFramework/blog/entradaBlog/index

Me da error porque intenta mostrar la accion index de CoreController aunque
el controller en la url es entradaBlog.

Puede ser un bug en el router.

Para hacer helpers que permitan crear un formulario web sin necesidad de
utilizar YuppForm.

Si tengo un modelo:

A->(*)B->(1)C

a: A

poder hacer: a.path('bs.c') y que devuelva una lista de el c de cada b de a, o 
sea que sería equivalente a hacer:

cs = array()
foreach (a.bs a b) {
  cs[] = b.c
}
return cs

O si el modelo es:

A->(*)B->(*)C

a: A

Al hacer a.path('bs.cs') retornar todos los cs de los bs de a, o sea que sería:

cs = array()
foreach (a.bs as b) {
  foreach (b.cs as c) {
    cs[] = c
  }
}
return cs

REF: TICKET #8

Agregar soporte para listas y mapeos de atributos simples. (lista
persistente de datatypes)

Por ejemplo: Tengo una clase Persona que tiene varios telefonos y solo
quiero el numero de telefono, no voy a hacer un objeto persistente solo
para guardar un string (el telefono), entonces le agrego como atributo una
lista de strings, la cual se sabe persistir (es una lista persistente). Es
muy parecido a tener un objeto persistente asociado por hasMany, las tablas
siguen el mismo principio, pero la lista persistente ya la tengo
implementada y no necesito implementar un objeto persistente cada vez, solo
uso la lista del tipo de objeto que quiero guardar (no se pueden mezclar
tipos).
El mismo principio va con el Map, básicamente lo que guardo son pares
key/value.

Si una clase del dominio tiene un campo booleano, al cargar un valor para ese 
campo desde la base, el tipo del valor (usando gettype) es string, en lugar 
de ser boolean.

Corregirlo para que los tipos guardados sean igual a los tipos cargados.

[REF TICKET #72]

Hacer: <?php msg("blog.entrada.list.title", "es"); ?>
En lugar de: <?php echo DisplayHelper::message("blog.entrada.list.title",
"es"); ?>

msg deberia ser una función global que llame al helper y ya haga el echo.

Poder crear la estructura de una aplicacion vacia.

Para los arhivos comunes como las vistas de list, show, create y edit, y el app 
descriptor, tener unos archivos templates para copiarlos cambiando los nombres 
de las clases y componentes. Tambien tener un controller de template para hacer 
lo mismo con las acciones list, create, edit, save, show.

Quien se encargará de hacer la creación de directorios, la construcción a 
partir de templates y la creación de archivos, será la clase App.

Si yupp está directamente en el root, digamos en /www, entonces el método 
debe retornar "/".
Su yupp está instaladn en /www/yupp, el método debe retornar /yupp.

Etc.

Sirve para que Yupp Portal pueda armar urls para poner en los mails que se 
mandan automaticamente.

Tengo una clase A que tiene muchos Bs.
Bs tiene una subclase C que se guarda en una tabla distinta a la de B.

Tengo una instancia a:A con un c:C en su coleccion de Bs.
Al intentar guardar a->c pide el super_id a c, o sea el id del b:B que
extiende y se guarda en la tabla de los Bs.
Al pedirlo no llama a YuppConventions, entonces pide el atributo super_id_B
en lugar de la convension que es super_id_b.

La solucion es NO armar el nombre del atributo super_id_B a mano, si no
llamar al metodo YuppConventions::superclassRefName.

hacer que las reglas se definan en una linea de codigo y que el procesado 
lo haga el framework, algo como:

$Route->connect ('/blog/:action/*', array('controller'=>'Blog', 
'action'=>'index'));

dispatch('%s-%d', function($titulo = '', $id = 0) 
{ 
  echo $titulo; // el-titulo-de-la-noticia 
  echo $id; // 33 
}):

La definicion actual usando expresiones regulares no es muy clara.

Helpers que generan controles web como HTML y CALENDAR dependen de
librerias JS.
Para los Helpers que dependan de librerias:

  * Crear una clase nueva y poner adentro todos los helpers que dependan de
la misma libreria.
  * Que esas clases sean incluidas opcionalmente y por el usuario, o sea
que no sean incluidas por el framework.
  * Que cuando esas clases sean incluidas, el JS se cargue automaticamente.
Se podria inyectar la llamada al JS en la vista.

[REF TICKET #66]

Los flash no llegan cuando hay redirect.
Por ejemplo cuando elimino una entrada, no se ve el mensaje.

SOLUCION:
Lo que se puede hacer es que si el redirect se da cuenta que se puso algo
en flash, lo mande tambien como params en el nuevo request.

Ver el test 002 donde al salvar la cara se salva la nariz.
Las restricciones de la nariz no se están verificando al guardar la cara.
El test3 tiene un error en la nariz a propósito y no se está verificando la 
existencia del error.

Llevar el router a su minima expresion.

1. Hacer el router, el filter y el executer en una sola clase.
2. Solo públicas las operaciones que se llamen desde RequestManager, las
demás privadas.
3. Que haga todo el manejo de parámetros GET, POST y FILES.

En Yupp v0.1.5 se incluyeron FKs en la generación de las tablas, pero
SQLite no las soporta, por eso da errores al querer generar las FKs.

En cambio, SQLite puede implementar FKs mediante triggers que se lanzan
cuando la restricción es violada, el mecanismo está descrito aquí:

http://www.sqlite.org/cvstrac/wiki?p=ForeignKeyTriggers
http://www.rcs-comp.com/site/index.php/view/Utilities-SQLite_foreign_key_trigger
_generator

Para que si no recibe component o controller que no de error y tome los
valores del contexto.

Agregar que detecte si hay params de ordenamiento en un listado, para que al 
mostrar la siguiente página ser conserve el orden previo.

Poder guardar los logs en archivos en disco.

Otra opcion seria poder guardar el log en la base de datos.

Para JSON falta hacer el soporte de generación recursivo y para XML falta el 
soporte de agregar referencias cuando se encuentran loops.

Agregar que si se retorna un array con variables, estas se agreguen al 
modelo que es accesible desde la vista, con esto se logra que los casos 
mostrados abajo sean equivalentes:

ahora:
$this->params['a'] = 'A';
$this->params['b'] = 'B';
$this->params['c'] = 'C';
return;

nuevo:
return array('a'=>'A', 'b'=>'B', 'c'=>'C');

persona->getByName( "pablo" ) // busca por eq
persona->getByNameLike( "a%" ) // busca por like
persona->getByBirthdateLessThan( fecha ) // busca por <
persona->getByBirthdateBetween( fecha1, fecha2 ) // busca fecha1<= birthdate 
<=fecha2

Si un campo tiene las siguientes restricciones y viene un valor vacio en 
lugar de salir por la primera verifica la segunda y falla, y nullable deberia 
ser mas fuerte que inList.

Constraint :: nullable(true),
Constraint :: inList( array("1","2","3","4","5") )

Para poder aplicar filtros en los listados, tal que puedan ordenarse por 
columnas y hacer paginación usando los helpers estándar de Yupp, hacer que si 
 hay parámetros cuyo nombre empieza con "filter", agregarlos a los links del 
paginado y del ordenamiento de columnas.

Cuando la vista y los templates necesitan incluir las mismas librerías 
javascript no hay forma de decir que se incluyan una sola vez.

La idea sería hacer un ViewManager, o mismo hacerlo dentro del LayoutManager, 
para que cada coponente (vista, template, etc) pueda decir qué librerías JS 
desea usar, y que al momento de generar el HTML cada librería sea incluida en 
el header de la página sin repetirse.

PersistentManager::save PageAccessLog
PersistentManager::save_cascade PageAccessLog SESSIONID: 1236028091_11531_14312
PersistentManager::save_cascade User SESSIONID: 1236028091_11531_14312
PO:update_simple_assocs
PersistentManager::save_object User
DAL::exists portal_user (1)
DatabaseMySQL::query : SELECT id FROM portal_user WHERE id=1
DAL::update portal_user User
DatabaseMySQL::query : UPDATE portal_user SET nombre='Pablo
Pazos',email='[email protected]',clave='asdqwersdf',edad='27',fechaNacimiento='1981
-10-24',type='admin',class='

User',deleted='0' WHERE id=1
PersistentManager::save_cascade Page SESSIONID: 1236028091_11531_14312


Tengo un usuario colgado desde el PageAccessLog, pero la referencia desde
el log al usuario es blanda, al crear o destruir un log, el usuario ni se
da cuenta, la referencia es solo para saber que usuario fue el que genera 
el log. La solucion seria meter un tipo de relacion hasOne @weak@, o tomar
la politica de que si la relacion hasOne unidireccional no dice belongsTo
en el item referenciado, entonces al salvar el que tiene la referencia no
se salva el referenciado (que no tiene belongsTo) y considero eso como
relacion blanda.

Para lograr una API completa, el framework debe proveer funcionalidades de 
inspeccion de sus distintos elementos:

Componentes:
 - que componentes hay
 - en que version
 - tiene icono del componente?
 - con que version de yupp son compatibles
 - que dbms usan, y que dbms usan por modo de ejecucion
 - tiene reglas de seguridad?
 - tiene filtros de ruteo?
 - obtener el arbol de dependencias de cada objeto del componente
 - Modelo:
   - que clases forman el modelo, inlcuyendo estructura de subdirectorios o paquetes
   - que relaciones hay entre las clases
   - con que tablas se mapean
   - fechas de creacion y ultima modificacion
 - Controladores:
   - que controladores tiene el componente
   - que acciones implementa
   - cuales acciones son estandar y cuales no
   - fechas de creacion y ultima modificacion
 - Vistas:
   - que vistas hay
   - que vistas con nombres estandar hay
   - fechas de creacion y ultima modificacion
 - Servicios:
   - que servicios hay
   - fechas de creacion y ultima modificacion
 - Tests:
   - que tests hay
   - fechas de creacion y ultima modificacion
 - Otros elementos:
   - tiene bootstrap?
   - tiene bootstrap por modo de ejecucion?
   - tiene JS? que librerías JS usa y en que versiones?
   - tiene imagenes? archivos? otros recursos estaticos?
   - tiene librerias PHP? cuales? que versiones tienen?
   - tiene hojas de estilo?

Falta el poder crear una agregación al crear una consulta con Query.
Y falta la interpretación de los dinstintos DBMS de esas agregaciones.

Esto servirá para especificar clases del dominio mediante descriptores XML.

Esto se usaría para 2 propósitos:

1. Generación de código a partir de los descriptores XML.
2. Interoperabilidad, enviando descriptores en conjunto con instancias XML, se 
pueden regenerar las estructuras del lado del receptor.

Por un lado poner las fuciones de consulta y por otro las funciones de creacion 
y modificacion del FS (crear archivos, crear directorios, cambiar nombres, etc).

REF: TICKET #6

Esto seria util para verificar correctitud de modelos de componentes cuando
estos son empaquetados para poder instalarlos en sistemas, para cuando se
esta desarrollando y se elige explícitamente “verificar modelo” o tambien
cuando se instala un componente lo primero que deberia hacer es verificar
correctitud del modelo.

Cosas a verificar:

1. Valores de hasOne deben ser clases persistentes
2. Valores de hasMany deben ser clases persistentes
3. Verificar que si tengo varias asociaciones entre 2 clases, tengo los
nombres correspondientes a cada asociación codificados en los nombres de
atributos.
4. 

Para los elementos HasOne relacionados, generar los links al show de ellos.

REF: #28

Mejorar el helper de lista y show para que luego de mostrar los atributos
simples, muestre los atributos hasOne con links a los details de esos
atributos.

La misma idea para los links hasMany, pero mostraria una lista de
elementos, que son todos los que tiene la instancia que yo veo primero, no
son todos los de la tabla!.

Estaria bueno tambien poder modificar edit y create de forma que pueda
asociar elementos ahi mismo mediante "set xxx" me lleve al create de xxx, y
el objeto se crea y se asocia a la clase que estoy creando o editando, lo
mismo para hasMAny con "add yyy" me muestra una lista de los yyy existentes
y se lo agrega a la coleccion de yyy's del objeto que estoy creando o editando.

El problema se da porque las constraints se setean directamente y no a travez 
de un método.
La idea sería que mediante el método se agreguen restricciones a los campos y 
que las restricciones de lassubclases no sean sobreescritas por la 
superclase.
A su vez, la superclase podria definir restricciones para campos que en las 
subclases no se definen.

En lugar de tener los parametros, la url y demás por separado y acceder a 
ellos mediante las variables globales de PHP, usar la clase HTTPRequest para 
meter todo ahí y que el router le pida lo que necesite a esta clase.

Esta instancia deberia ser de acceso global, directamente como singleton, o 
mediante alguna instancia global de otra clase, como la de contexto.

Si B hereda de A, A declara withTAble='ta' y B declara withTable='tb',
withTable de B será 'ta'.

El problema es que obviamente el campo de la superclase sobreescribe el
campo de la subclase, pero esto no me permite cambiar el nombre de la tabla
a la que se mapea la superclase, en el caso de que se necesite un nombre de
tabla particular para A.

Corregir de modo de que tanto para A como para B se pueda declarar el
nombre de la tabla a la cual se mapea.