No tendria objeto transaccion
Lo sustituyo por los objetos:
Structure (la parte de structure de las trn)
WebEntryPanel (el HtmlForm de las Trn)
WinEntryPanel (el WinForm de las Trn)
WabEntryPanel (el webform en WML)
TextEntryPanel (la pantalla verde)
WSEntry (el actual BC)
Un objeto structure estaria asociado a otros objetos (win,web,sdt) y me permitira hacer mas facil el mantener la estructura y tambien tendria menos redundancias.
Habria reglas que se asocian a la estructura (serian las que se usan para los BC) y las de interfaz, estarian solamente en lo EntryPanel.
Uso mas intensivo de los dominios.
Llegarian a la base de datos, haria mas estricto el control de dominios, por ejemplo los subtipos, deberian ser del mismo dominio.
Reglas Globales a toda la KB
Variables Globales
Variables a todos los programas que puedan ser compartidas (manejo de contexto)
Haria un "Trabajar con Objetos" potente
"Trabajar con Referencias" mas potente.
Poder hacer operaciones con los objetos que referencias a un objeto. Por ejemplo, especificar todos los objetos que hacen referencia a un objeto dado.
De esta forma, se podria llamar a rutinas que validaran politicas de la empresa, como validaciones de nomenclatura, realizar respaldos de objetos, notificar al KBA (Knowledge Base Administrator).
Tambien facilitaria la posibilidad de hacer control de versiones.
Analisis de impacto
Guardaria informacion de que tabla es utilizada por que objeto, para poder hacer analisis de impacto mucho mas detallados.
Al modificar un atributo, podria ver el impacto en la base de datos y tambien los cambios que se van a realizar en los objetos genexus.
Manejo de Usuarios
Integraria los usuarios del sistema operativo a Genexus
Reglas de Negocio en Runtime
Permitiria la definicion de reglas de negocios y formulas en runtime, de forma que pudieran ser interpretadas en la aplicacion. Estas reglas, en la primera etapa no seria necesario que interactuaran con la base de datos, sino que simplemente utilizarian un SDT. De esta forma se simplificaria muchisimo la primera version.
Mayor Potencia al For Each
For each
order <Att1> <Att2> ...
Distinct Att1 Att2...
Where <Condition> //incluiria condiciones que se ponen en HAVING...
Defined by <Att1> <Att2> ...
Group by Att1 Att2..
endfor
Alguna forma de solucionar el problema del Join
Tengo una tabla de Cabezal y Renglones.
Quiero traer Todos los Cabezales sin renglones, en un solo for each.
De esta forma si borro un objeto, puedo recuperarlo, si cambio una propiedad, puedo volverla a como estaba.
Estas acciones se guardarian mientras dure la sesion.
Lista de Objetos como categorias.
Hoy (2016) existen dos tipos de categorias. Las categorias dinamicas, que se basan el el Full Text Search para todos los objetos que tienen algun string o valor de propiedad, y las categorias no dinamicas que son las que se agregan a cada objetos.
Me gustaria tener categorias que fueran listas de objetos, que NO MODIFICARAN las revision de objetos al agregarse, sino que solamente modifique la categoria.
No tendria modelo de diseño
Los modelos tendrian una version y al hacer cambios lo haria en otro modelo (modelos de trabajo que podria usarse por programador) y luego esto se impactaria (total o parcialmente) sobre el modelo original.
Tendria un control de Versiones estricto e integrado
Permitiria atributos de usuario
Permitiria definirle diferente propiedades (atributos) a los objetos, definidas por el usuario.
Dejaria agrupar y buscar por esas propiedades.
Extensible
Agregaria la posibilidad de hacer llamadas a rutinas del usuario, para los eventos comunes:
Crear/Salvar/Borrar Objeto
Crear/Salvar/Borrar Atributo
Impacto de la Base de datos
Build All
Generacion de Objeto