2. Nuestra Empresa
• Conocemos GeneXus desde su versión 3.3
• Comenzamos el trabajo en Web con GeneXus desde
2002
• En el 2006 comenzamos a brindar soporte de
migraciones de aplicaciones Win a Web y creamos
nuestro producto PXTools.
• Tenemos Presencia en 8 países de America
• Tenemos más de 20 clientes que utilizan PXTools
• Superamos las 100 licencias otorgadas.
8. Evaluando el Pasado
1 Un programador PXTools desarrolle
SD con 2 días de entrenamiento.
2 Minimizar el impacto del cambio de
plataforma lo más posible.
18. Transacción a través de Busines Component (ReST)
Ins
Detail
Section General Section
Subordinados
Tabular
Grid
View View
Upd Dlt
19. Transacción a través de Busines Component (ReST)
Ins
Detail
Section General Section
Subordinados Business
Tabular Section
Grid Component
View View Edit
Transacción
Upd Dlt
20. Sections type View y Edit
Ins
Detail
Section General Section
Subordinados
Tabular Section 1 Section 2
Grid
View View Edit Edit
Upd Dlt
21. Sections type View y Edit
Ins
Detail
Section General Section
Subordinados Section 1 Section 2
Tabular
Grid Edit Edit
View View
Upd Dlt Save Cancel Save Cancel
23. Sections Edit vs. Section Edit y Tabs
Ins
Detail
Tabs
Section General Section
Subordinados Section 1 Section 2
Tabular
Grid Edit 1
Tab Tab 2
Edit
View View
Section
Upd Dlt Save Cancel Save Cancel
Edit
24. Sections type View y Edit
Ins
Detail
Tabs
Section General Section
Tabular Subordinados Business
Grid Tab 1 Tab 2 Component
View View Transacción
Section
Upd Dlt Save Cancel Edit
25. Visión desde PXWorkWith
Transacción
Tabs
Ins
Tab 1 Tab 2
Detail
Save Cancel
Section General Section
Subordinados
Tabular
Grid
View View
Upd Dlt
28. Funcionalidades básicas
• Form en Transacciones.
• Codes en Transacciones.
• Accion Update y Delete en Section invocan a Trn.
• Nodo Modes con Acción insert en Selection.
• PXParameterRequest genera Panel for SD.
• Confirm en Acciones.
• Parseo de comandos estándares a comandos SD.
• Soporte de Acciones Multirow
• Acción “Enter” en Transacción para SD.
• Separar manejo de clases para cada Plataforma.
• Atributo Platform en preferencias de Contextos.
29. Funcionalidades avanzadas
• Templates
– Form
– Eventos
– Condiciones
– Variables
• Soporte de Subrutinas.
• Soporte de Títulos en Grilla.
• Carga automática de clase ReadOnly.
34. Referencias
• PXTools Demo en Google Play:
https://play.google.com/store/apps/details?id=com.punt
oexe.pxtoolsdemo
• PXTools Demo en GXServer:
• http://xev2.genexusserver.com/gxserver/home.aspx?PXTo
olsDemo,0
• Conferencias relacionadas
• PXTools (for X Evolution 1) 4.0 y PXTools (for X Evolution 2) 2.0
Sala 4R, Martes, hora: 09:30
• Café con PXTools - Sala 25TG, Miércoles, hora: 10:30
• Stand de PuntoExe y PXTools en segundo piso.
Editor's Notes
Antes que nada vamos a dar una breveintroducción a nuestra empresa PuntoExe Consultores.
La primerapregunta quepuede ser natural hacersees ¿Porquéhacer um generador para Smart Device?La tecnología SD está basadaenlatecnologíapattern. Entonces ¿Porquéhacer que um patterngenere outro pattern?
Lasiguientepregunta que nos hicimosfue ¿Valióla Pena?
La siguientepreguntapodría ser ¿Qué se logró?
La última pregunta que tendremos que responder es ¿Cómololograron?
Este esel diagrama representando los elementos: Selection, Detail y Sections.Cuando vamos a incorporar Acciones para el ABM de los registros se distribuirán de lasiguientemanera.Vemos que elUpdate y el Delete solo están em elTab General del Detaul y no em elSelection.Estoesdebido a que larepresentación de lasacciones “InGrid” para elSeletion no esviable de implementarlo dentro de lagrilla por motivos de que no hay suficiente presición em este tipo de dispositivos para seleccionar controles dentro de um registro de lagrilla.Estamos evaluando alternativas para solucionar este problema:Soporte de Menú contextual al realizar um LongTap sobre el registro.Soporte de Selección de línea y ponerlasaccionesfuera de lagrilla.
En esta plataforma no se interactúa directamente con la Transacción, sino con un elemento que, al confirmar, se comunicará con la transacción como Business Component exponiéndola como WebService y protocolo ReST (RepresentationalState Transfer).Este elemento que mencionábamos es considerado un Section con una propiedad type en Edit. Los Section que vimos anteriomnete tenían el type en View.
Estanueva forma de encarar el ABM permite tener múltiples SectionscontypeView y también múltiples Sectionscontype Edit.
Vamos a tratar de enteder como se visualizanestosSectons de distinto tipo.
Partimos del List y el usuario seleciona un registro.Esto genera el pasaje al Detailposicionandose por defecto en el primer Sectioncomtype View.El usuario pordrá recorrer los distrintosSections.Cuando el usuario selecciona los botones Update o Delete cambia el estado del Detail a Edit y eso hace que desaparezcan los Sectionscon type View y comiencen a verse los Sectionscon type Edit.Cada Section tendrá un botón de Save para salvar los datos ingresados en el mismo con el BC y el Cancel para volver al estado View del Detail.
Creemos que esta solución de múltiples Sections con typeEdit no es muy recomendable.Esto se soportó para poder representar Registros con muchos campos en distintas Secciones debido a la restricción de la plataforma.Pero esto trae consigo otros problemas. Por ejemplo: si estoy queriendo insertar un registro y confirmo el primer Section, si tuviera un atributo no nulo puesto en el segundo Section tendría errores generados por el BC que no me permitirán salvar el primer Section.Por lo tanto lo que nosotros planteamos es que tengamos un único Section con typeEdit y la distribución de los atributos los hagamos con un control Tabs dentro del Section.
El modelo que estamos planteando completo sería el siguiente.Pero la realidad es que el concepto de SectiontypeEdit es complejo de entender por lo tanto lo que nos quedaría mucho más claro es visualizar el modelo de la siguiente manera…
Este modelo se parece mucho más al modelo del pattern que estamos acostumbrados a trabajar con Web.Y por lo tanto es el que finalmente decidimos implementar en nuestro pattern de PXWorkWith…
Form en Transacciones como recién hemos explicado.Codes en Transacciones para las dos plataformas. En Web lo generaremos en la Transacción mientras que en SD lo generaremos en el Sectiontype Edit.AccionUpdate y Delete que invoca automáticamente a la trn.Nodo Modes para SD. Por el momento en SD solo con el soporte de Insert.Nuestro patrón PXParameterRequest está generando el PanelSD.Confirm en Acciones de igual manera de cómo lo programamos para Web.Parseo de comandos estándares a comandos SD. En esta nueva plataforma se utilizan mucho los ExternalObjects y los comandos tradicionales no están soportados en la plataforma. Con PXTools estamos manteniendo el manejo de (Return y Refresh) a la manera tradicional.Soporte de acciones Multirow. Esta funcionalidad por el momento está bastante restringida en SD.Acción “Enter” en Transacción para SD. Teniendo en cuenta que se genera un SectiontypeEdit es que permitimos incorporar código previo a la invocación del Business Component como forma de interactuar con el mismo.Separar manejo de clases para cada Plataforma. Esto se hizo debido a que GeneXus representa distinto los anidamientos de clases. En Web cada clase se identifica con el nombre independientemente de que esté bajo otra clase. En la plataforma SD el nombre completo de una clase que está bajo de otra es <ClasePadre>.<Clasehija>Atributo Platform en preferencias de Contextos. Podemos tener Contextos distintos para la plataforma Web que para la SD.
Por otro lado hemos incorporado funcionalidades que consideramos han sido trascendentales para automatizar el desarrollo:Soporte de Templates. Hemos incorporado toda la potencia que logramos en Web para la plataforma SD. Esto quiere decir que usamos la platilla para predefinir comportamientos no solo a nivel del Form sino a nivel de Eventos, Condiciones y Variables.Soporte de Subrutinas. Las subrutinas no están soportadas en SD. Nosotros las hemos soportado realizando la sustitución del código en los lugares donde estén las invocaciones. Inclusive está soportado la invocación anidada de subrutinas. Lo que hay que tener en cuenta es que como se realiza sustitución si tenemos ForEach sobre subrutinas podemos estar generando anidamientos no deseados.Soporte de títulos en Grilla. Hay que tomar en cuenta como vimos en el Demo que las grillas se comportan como Grid Free Style en Web. Por lo tanto lo que declaremos en un nodo Attributes del Layout será un form tabular.Hemos incorporado lógica para indicar cuando queremos una representación tabular o una representación con formato de Columnas para facilitar el proceso de entendimiento de un programador PXTools acostumbrado a la plataforma Web.En el caso de que se indique que se manejarán como Columnas es posible solicitar que la propiedad Description de cada atributo sea considerado como título y por lo tanto se diseñará una tabla arriba de la grilla con la titulos.Carga automática de la clase ReadOnly. En la plataforma Web estamos acostumbrados de que si a un atributo o variable le asociamos una clase, si la definimos con ReadOnly automáticamente el control quedará asociado a la clase con el nombre agregado Readonly al final. Esto es debido a que cuando es editable tenemos las cajas de texto y el comportamiento de diseño puede ser radicalmente diferente cuando está readonly. Este comportamiento no está soportado en SD por lo que decimimos que PXTools debía soportarlo. La única restricción es que solo aplica para cuando utilizamos la propiedad ReadOnly en tiempo de diseño. No aplica cuando cambiamos a la propiedad ReadOnly por Evento.
