PuntoExe Tools Manual de Uso Volumen 5 Montaje Inicial INTRODUCCIÓN Este Volumen 5 del Manual de Uso de las PXTools es la transcripción del quinto de los seis videos que contienen la versión completa del Curso de Entrenamiento dictado por el Ing. Juan Marcelo Bustamante (autor de las PXTools) a un grupo de nuevos usuarios de esta herramienta, a fines de 2007. Todas las referencias internas para la ubicación de sus contenidos temáticos o imágenes remiten al momento en que fueron abordados o mostrados en la grabación original, de modo de poder ampliar en ella cualquier asunto que pueda haber perdido claridad en la transcripción. Los títulos de cada tema hacen referencia expresa al video y momento de la reproducción en el formato: V Nº HH:MM:SS (HoraHora:MinutoMinuto:SegundoSegundo) de modo que el índice de cada volumen permite ubicar los temas en el propio documento o en el correspondiente video indistintamente. Las imágenes se identifican con una combinación de video y momento de la reproducción en el formato: VH:MM:SS (VideoHora:MinutoMinuto:SegundoSegundo) para que puedan ser referenciadas en cualquiera de los volúmenes del manual. Con el fin de minimizar el peso de estos documentos en su versión digital, todas las imágenes contenidas tienen baja resolución, por lo que se recomienda regular el nivel de Zoom del visualizador antes de proceder a su lectura. Página 1 de 74
INDICE TEMA UBICACIÓN Pg. Instalación - Estructura V 5 00:00:00 4 Patterns V 5 00:00:55 4 License V 5 00:02:17 5 XPZs V 5 00:04:05 6 Lib (pexe.jar) V 5 00:06:50 8 War V 5 00:08:32 8 Static V 5 00:18:33 12 Instalación - Datos Personalizables V 5 00:23:50 15 Folder PXPersonalized V 5 00:27:24 16 Login V 5 00:28:05 17 Master Page V 5 00:36:45 20 Seguridad V 5 00:38:21 21 System V 5 00:45:16 25 Themes V 5 00:51:21 30 Instalación - Login V 5 00:52:52 32 CheckContext V 5 00:53:06 32 CheckUser V 5 00:53:16 32 SaveContext V 5 00:53:25 32 Lógica de recuperación de pantalla post login V 5 00:53:39 32 Instalación - Manejo de Menús V 5 01:03:45 37 Folder PXAccesories V 5 01:05:33 38 Menú Superior, Menú Izquierdo V 5 01:07:20 39 Optimización y Login V 5 01:10:08 40 Menús Personalizados V 5 01:14:50 44 Importación de Menús, Exportación de Menús V 5 01:24:37 49 Instalación - PXToolsParameters V 5 01:29:45 50 Static Path V 5 01:30:55 51 Images Path V 5 01:31:35 51 System Images Folder V 5 01:32:20 52 Check User-Menu Relation V 5 01:34:03 53 Menu Bullet V 5 01:35:43 53 Recent Link Bullet V 5 01:37:30 54 Recent Link Levels V 5 01:38:42 54 Login Support V 5 01:39:52 54 Página 2 de 74
TEMA UBICACIÓN Pg. Soporte de Help en Línea - Filosofía V 5 01:40:45 54 Abstraer al programador del conocimiento de HTML V 5 01:41:33 56 Documentación a nivel de la instancia V 5 01:43:40 56 Soporte múltiple idioma V 5 01:50:29 60 Manejo de Help MasterPage V 5 01:54:16 62 Página 3 de 74
Instalación - Estructura V 5 00:00:00 Hoy vamos a ver todo lo correspondiente al montaje inicial de las PXTools, instalación incluida. Trataremos de profundizar en las rutinas que van a tener que tocar para poner a punto ese montaje inicial. Lo primero a tener en cuenta es la estructura de instalación y para eso vamos a ver una instalación: Ésta es básicamente la estructura de directorios de instalación (recuadro) y vamos a mencionar un poco el contenido de cada una de estas carpetas. Patterns V 5 00:00:55 Comencemos por la carpeta Patterns, con los directorios que contienen los Patterns que se van a incorporar al Development Environment de Patterns. Los Patterns cuando se instalan, por defecto van a quedar en: Página 4 de 74
la carpeta de instalación del Pattern (recuadro), en este caso Patterns11 (las últimas versiones ya no son compatibles con Patterns 10). Dentro de esta carpeta hay otra que se llama Patterns (seleccionada en azul) que contiene una carpeta para cada uno de los Patterns que están definidos en el sistema. En este caso ya están instaladas las tres carpetitas con los Patterns de las Pxtools. Instalarlas es copiarlas, es copiar esas tres carpetitas al directorio Patterns, nada más que eso. Con esta primera parte cumplida, ya cuando se abre el editor de Patterns en la combito que vimos en la figura 10:55:19 ya tienen habilitados los Patterns, pero vamos a ver que le faltan algunas cosas para poder funcionar. License V 5 00:02:17 Van a requerir poner en el directorio de Patterns las licencias: pues de lo contrario les va a dar error la generación del Pattern. En la licencia siempre va a haber un archivo.lic (recuadro rojo), que es parte de la definición de la licencia y unas Dll de las licencias, habilitadas para los.net FrameWorks 1.1 y 2.0 (recuadro azul): Hemos hecho algunas pruebas con el 2.0 y no anda muy bien. Página 5 de 74
Inclusive aunque sólo se tenga el DotNet FrameWork 2.0, si se ponen las Dlls de la 1.1 funcionan bien. O sea que en principio prueben con las.net 1.1. Estas Dll hay que copiarlas directamente en la raíz del Pattern, en la figura 50:01:46, Patterns11 en recuadro rojo. Se trata de la carpeta donde está el archivo GeneXusPatterns.exe que es el ejecutable de GeneXus Patterns: que en este ejemplo destacamos con el mouse. También hay que copiar a este directorio el archivo de licencia que recuadramos en rojo en la figura 50:02:24. En este caso no está porque ya se instaló la licencia, pero tienen que tomar el archivo.lic y copiarlo en este mismo directorio Patterns11. Sólo con esto ya por defecto tienen 15 días de prueba sin costo de lo que sería una versión Trial. Posteriormente se nos puede pedir la renovación o les cambiamos la licencia para que sea anual o permanente según la hayan contratado. XPZs V 5 00:04:05 En importancia, la siguiente carpeta de la instalación es la de los XPZs. Página 6 de 74
De los cuatro XPZs que muestra la figura anterior, los que son específicamente requeridos por las PXTools, son los tres últimos (recuadro) y deben ser instalados. El otro, PXAccesories.xpz es un XPZ accesorio, que sólo deben instalar si van a resolver el tema de los Menús de vuestros sistemas con los recursos que les brindan las PXTools, cosa que van a tener que decidir en su momento y de la que vamos a hablar más adelante en esta clase. Pero no hay obligación de usar estos recursos. Ahora vamos a ver cada una de estas XPZ a qué corresponden y para qué sirven. Un detalle importante a tener en cuenta: Cuando vayan a consolidar los Patterns, para que no les dé error la consolidación tienen que ir a las Propiedades del Modelo y poner la propiedad Functions en Allows non-stardard functions on saving. Página 7 de 74
Esto es porque hay funcionalidades que no se pudieron programar en GeneXus directamente para el soporte de Java, Gráficas y otras cosas, de modo que hubo que hacer rutinas en Java puro. Entonces hay programas de GeneXus que están llamando a rutinas entre comillas que son Java. Luego, si no establecen esta propiedad, esas rutinas (son tres o cuatro) que son las que llaman a las funciones Java directo, les van a dar error. Hay que acordarse de hacer esto tanto cuando se consolida como cuando se pasa a un Modelo de Prototipo que también tienen que establecer esta misma propiedad. En este último caso creo que dice algo así como Error on especify non standard functions. El texto es parecido pero no es el mismo. Lib (pexe.jar) V 5 00:06:50 En la carpeta Lib de la instalación existe un archivo.jar en donde, justamente, están metidas esas rutinas externas: Estamos viendo dos archivos.jar porque actualmente en la Web está oficialmente la versión 2.2 de las PXTools y en la figura se destaca el correspondiente a la versión 2.3, todavía no liberada. Este.jar va a ser requerido si habilitan la funcionalidad de Export a Excel o Generación de Gráficas, o si usan el LoadConfig o si usan cosas que utilizan APIs que están metidas en la referencia a este.jar. Por defecto, si hacen un WorkWith común y corriente, cuando compilen no se va a requerir este archivo, pero en la medida que utilicen alguna de las rutinas que llaman a este.jar, ahí va a ser necesario que este archivo esté en el ClassPath del Compilador si no, no les va a funcionar. Más adelante vamos a ver que este archivo.jar está en el War para el armado de la WebApp, pero también tiene que estar afuera porque lo van a requerir ustedes en tiempo de compilación. Además entonces, lo van a requerir en tiempo de ejecución y está en los War generados que ahora les voy a mostrar. Obviamente estamos hablando de plataforma Java, recuerden que lo que les dije acerca de la generación de gráficas, ilustradas en la figura 11:34:40, está específicamente orientado a la plataforma Java. War V 5 00:08:32 Después dentro de la carpeta War de la instalación: Página 8 de 74
hay dos archivos.war (el primero para quienes tengan instalado el Upgrade 2 del generador Java y el segundo para quienes tengan el Upgrade 3) que les entregamos porque es parte de la metodología que nosotros usamos. No es la metodología que Artech documenta para que ustedes hagan una aplicación Web. Hay una metodología para desarrollar una aplicación Web que es usar el Deployment Wizard de GeneXus, etc. A nosotros no nos quedaba claro el Deployment y encontramos una manera muy rápida de hacer las cosas, que consiste en lo siguiente: Nosotros tenemos armado en este webapp.war un.war con lo mínimo que requiere GeneXus para armar una WebApp. Es lo que arma el Deployment si arrancáramos GeneXus desde cero. Agarramos GeneXus, lo dejamos libre, hacemos una rutinita mínima y ya ahí pedimos el Deployment para la Web, entonces me armaría algo parecido a este archivo webapp.war. O sea que este es el.war en su mínima expresión, no tiene nada. Esto les facilita en que no tienen que armar el Deployment, ya tienen un.war sobre el que trabajar y deben saber que el nombre del archivo war tiene que ser el nombre de la aplicación que van a crear. De modo que lo que hacemos es tomar nuestro webapp.war, lo copiamos, lo pegamos en la propia carpeta para cambiarle el nombre y después lo movemos al directorio donde tenemos instalado el Tomcat. En nuestro caso les voy a mostrar el directorio que usamos para un servidor Linux: Esta es la raíz de la WebApp). Página 9 de 74
Y simplemente acá, donde estamos viendo todos los.war, pegamos nuestro archivo con el nombre modificado y ya el Tomcat se encarga de crear todas las carpetas con una estructura que los servidores Web Java crean para soportar los servlets y que es similar a esta: META-INF, WEB-INF, classes, lib, etc. Tengan paciencia, a veces demora. Así, ya les va a quedar creada toda la estructura y después, lo único que tienen que hacer es ir a las propiedades de GeneXus, en el modelo Java: Página 10 de 74
y lo que importa es en Web Information apuntar a lo que serían los directorios Servlet directory (recuadro rojo) y Static content directory (recuadro azul). Ven que a aquí están separados los directorios por la razón que ya vimos: El Servlet directory y el Static content directory por lo general en Linux están separados y parte del Path es distinto, como pueden ver en la figura anterior. En el caso que estén trabajando con Windows, con un Apache Tomcat instalado por Windows, el Path va a ser el mismo, lo único que uno va a ser uno más largo que el otro. Uno va a llegar hasta las clases, directorio donde están las clases almacenadas, que es parte de lo que el Tomcat automáticamente generó (figura 50:10:50, directorio classes) y para el Static tenemos un estándar que consiste en ponerlo en lo que sería la raíz de la WebApp, pero en este caso que estamos viendo, como se trata de otro directorio separado, en realidad no es la raíz de la WebApp. En otros casos, si fuera el mismo directorio, lo ponemos realmente en la raíz, quedaría algo así como \\nautilus\webapps\pxt-demo. Pero esto no tiene por qué ser así. Vi que algunos de ustedes apuntaron el Static a un directorio que crearon con el nombre \\...\images, lo que no está del todo bien porque en realidad no se graban sólo imágenes, se graban JavaScripts, se graban los css que generan los Temas, en fin, toda la lógica que el servidor requiere de archivos estáticos. Los JavaScripts son archivos estáticos entonces también se graban en aquí. Creo que como nombre sería más apropiado \\...\static, o algo así. El Static content base URL (recuadro verde) también, es el Path relativo visto desde el punto de vista que se está posicionado en la raíz del servidor. De haber puesto \\...\static para el Static content directory, aquí debemos poner /static pero ahora como una URL. Y ahora estamos en condiciones de empezar a trabajar sobre el modelo en cuanto a especificación y compilación GeneXus para trabajar directo contra la WebApp. Y una vez que tengamos el modelo funcionando vamos a ver que es fácil armar un.war, ahora sí, con toda la aplicación dentro. El tema es que si: Si cliqueamos dos veces un archivo war y lo abrimos con WinRAR: Página 11 de 74
vemos que no es más que un ZIP con dos carpetas que ya nos son conocidas dentro. Por lo tanto si tenemos la WebApp armada y estamos probando la aplicación en un modelo de Testing o de Producción, lo único que tenemos que hacer es, estando posicionado en el directorio de la WebApp: seleccionar las dos carpetas recuadradas y solicitar su compresión en formato ZIP: Ojo, no funciona con RAR que tiene una estructura distinta. Tiene que ser en formato ZIP y simplemente incluir esas dos carpetas. Esto nos genera un archivo.zip que lo cambiamos a.war y listo. Ya tenemos el archivo war de nuestra aplicación sin haber pasado por el Deployment. Static V 5 00:18:33 Por último, dentro de la carpeta Static de la instalación: Página 12 de 74
que tiene por un lado el contenido estático de JavaScripts que nosotros requerimos y tiene que estar en el directorio que se configuró en GeneXus para el Static content (figura 50:11:44 recuadro azul) y por otro lado el directorio images. Lo que deben hacer no es copiar la carpeta Static y pegarla en la WebApp, sino que deben abrir la carpeta Static, copiar lo que tiene adentro y pastearlo en donde ustedes hayan declarado que es el Static. Si han declarado que este directorio se llama pepe, tienen que estar debajo de pepe directamente los archivos js. Dicho de otro modo, los.js que están en la figura anterior tienen que quedar mezclados con los.js de GeneXus. Bien, con esto hemos repasado la estructura de la instalación: Finalmente digamos que todo lo que les hemos explicado está documentado en este ReadMe (recuadro) que yo tengo aquí impreso y al releerlo observo que omití algo importante en relación con los XPZs: Una vez que ustedes consoliden los XPZ, lo primero que tienen que hacer es, en modo Diseño, en las propiedades, cambiar el Tema por defecto que trae GeneXus que se llama Default y allí ustedes deben declarar que el tema por defecto va a ser el de las PXTools: Página 13 de 74
De modo que consolidan los XPZ y después que lo hacen, cambian acá el Tema por defecto. Lo otro que recomendamos hacer en esta misma ventana para que a medida que vayan desarrollando con los Patterns puedan ir viendo las imágenes desde GeneXus, es apuntar el Base image path (recuadro) a ese mismo directorio images, dentro del Static que vimos en la figura 50:18:40. Si tienen la WebApp en Win, ya pueden apuntar directamente a la WebApp Static de Win o copian el directorio images debajo de algún directorio y referencian al padre. No tienen que incluir el \images porque éste es un directorio interno del Static y aquí hay que apuntar al directorio estático. Si hacen eso van a poder ver, por ejemplo en un Trabajar Con: van a poder ver las referencias a imágenes. Página 14 de 74
Instalación - Datos Personalizables V 5 00:23:50 Una vez que tenemos los XPZs consolidados, básicamente la estructura que estamos haciendo es la de una Folder por cada XPZ: Cada XPZ representa una Folder que se crea y vamos a empezar a hablar un poco de cada una de estas Folders. Hay una Folder que se llama PXPatterns que es muy sencilla, tiene nada más que una estructura que organiza en subfolders que tienen un nombre por cada tipo de patrón. Cuando ustedes por defecto generen con los Patterns, están configurados ya para que lo hagan sobre estos nombres de carpeta. El Composer va a generar sobre la primera PXTools_Composer, el ParameterRequest lo va a hacer sobre la segunda PXTools_ParameterRequest y el WorkWith sobre la tercera PXTools_WorkWith. Si ustedes no se consolidan este PXPatterns.xpz no pasa nada, simplemente cuando el Pattern Composer va a trabajar y va a decir que va a generar sobre la Folder PXTools_Composer que se la va a crear en la raíz, o sea debajo de Objects y van a quedar mezclados. Por eso simplemente este XPZ lo único que está organizando es que los objetos generados por los Patterns van a estar metidos en carpetas propias debajo de una Folder PXPatterns. Inicialmente estas carpetas lo único que tienen es un objeto Dummy porque en GeneXus no se puede distribuir sólo Folders. Hay que distribuir algún objeto para que las Folders se creen. Página 15 de 74
Después tienen la Folder PXTools en cuyas subfolders van a estar organizadas las APIs del sistema, que en la versión Trial habrán visto que están con Copyright. Son objetos que no deberían tocarse en el sentido de modificarse, pero sí se pueden utilizar tal como hemos visto en varias partes del curso. Son básicamente las APIs que muy por debajo utilizan los Patterns y ustedes también podrían utilizar como rutinas auxiliares que atienden requerimientos generales o particulares, como el AcSUV y DeSUV o el Debug y el TreeView que vimos en la clase pasada. Este último, como dijimos, seguramente se convertirá en un nuevo Pattern PXTreeView para facilitar el uso de este recurso. Pero la más importante Folder que ustedes van a tener que utilizar es la PXPersonalized. Folder PXPersonalized V 5 00:27:24 Las PxPersonalized son rutinas que vienen por defecto, que se utilizan por los Patterns, pero en este caso sí, que deberían ser modificadas por ustedes. Porque contienen datos personalizados para cada sistema que se está implementando. Si bien son rutinas que se utilizan en su mayoría por el Pattern y también por la Master Page según vamos a ver, ustedes van a tener que modificarlas. Vamos a analizar el contenido de estas subfolders de PXPersonalized comenzando por la PXTools_Context. Allí por ejemplo tenemos el CheckContext (recuadro) con el cual el sistema tiene contemplada la posibilidad de verificar un usuario logueado: Página 16 de 74
Login V 5 00:28:05 Es frecuente que si el usuario no está logueado se deba llamar al Login, pero eso depende de cada aplicación. Esta rutina CheckContext lo que hace es implementar la lógica que el sistema debe aplicar según queramos o no controlar el Login. Inclusive hasta la versión anterior estaban comentadas las líneas de código recuadradas y ahora le agregamos una parametrización para que las tome en cuenta o no según corresponda, sin tener que descomentar código sino sólo cambiando un valor en el dominio enumerado PXToolsParameters. Más adelante veremos que el LoginSupport encima del recuadro, cuando cambian esta propiedad en el dominio enumerado que por defecto viene en False y la pasan a True, el sistema pasa a controlar el Login sin necesidad de tocar el código del CheckContext. De todos modos esta rutina está editable porque nos ha pasado en algunos sistemas que no sólo hay que controlar el Usr.Cod sino también algunas otras cosas que obligatoriamente deban estar instanciadas para el buen funcionamiento del mismo. Y aquí podrían agregar más controles sobre valores del Context, además del Usr.Cod, que fuercen el Login. Estos otros valores de Context los tendrán que crear ustedes, porque como vimos en V 3 00:17:33, el Context viene en su estructura mínima: el usuario en UsrCod y después dos propiedades que vamos a ver con respecto al Menú, la última incorporada muy recientemente. Si no van a usar el PXAccesories de Menús estas dos propiedades no aplican y las tendrían que borrar. Hay algunas rutinas entre las que tienen Copyright, que estaban usando la propiedad UsrCod del Context, propiedad que declaramos inicialmente y por defecto para identificar al usuario logueado. La siguiente rutina en la Folder PXPersonalized es DeCtx01 (figura 50:27:51, debajo de CheckContext): Página 17 de 74
Lo único que está haciendo esta rutina es devolviendo del Context el valor de la propiedad UsrCod en la variable &UsrCod. Si hubiera algún inconveniente con el nombre elegido para esta propiedad del Context con el sistema de ustedes, accediendo a la pantalla de la figura 50:29:41, la podrían renomenclar a su gusto y en sólo dos lugares deben cambiar este nombre: donde el sistema pide y donde el sistema carga el código de usuario. El primero es en esta rutina, en la pantalla de la figura 50:30:25 (recuadro). Porque en todos los lugares donde el sistema tiene que pedir el usuario (incluso en las rutinas que tienen Copyright) siempre lo obtiene mediante esta rutina DeCtx01. El segundo es la rutina SaveContext, en la pantalla de la figura 50:34:13 (recuadros), que como veremos en un momento es donde el sistema hace la carga el Contexto. Después el LoadContext y el SetContext no son para que ustedes los modifiquen: y lo que hacen es recuperar el Context desde la Web Session o grabar el Context en la Web Session respectivamente. No deberían ser editables, pero hay razones para incluirlas en esta Folder. Veamos cuales son. Si se utilizan rutinas que llaman al Contexto, cuando se distribuyen, GeneXus distribuye también el Contexto. De modo que, cuando les mandemos Página 18 de 74
una nueva versión actualizada de las PXTools, antes de consolidarse el Personalized ustedes deberían distribuir la versión que tienen en esta Folder porque cuando se consolide esa nueva versión actualizada, le va a pasar por arriba a todo lo que ustedes pueden haber modificado. O quizás no tendrían que consolidar sino simplemente saber lo que tienen y que es lo que tendrían que agregar de lo que trae la nueva versión. La Personalized va a tener siempre una versión adaptada por ustedes a los requerimientos de vuestro sistema, por lo tanto si llegan a tener que consolidar una nueva versión de las PXTools tengan cuidado de no consolidarse el Personalized sin tomar precauciones porque le van a pasar por arriba a todas las adaptaciones que hayan hecho. Entonces, estas rutinas LoadContext y el SetContext antes estaban en la Folder PXTools: General PXPatterns Objects (figura 50:27:51) entre las PXTools básicas, pero el problema que se generaba es que, como en ellas estamos usando una variable basada en el SDT del Contexto, GeneXus nos distribuía el Contexto y repetía el problema que vimos para la Folder PXPersonalized en esta otra Folder PXTools: General PXPatterns Objects, donde se encuentra el núcleo básico del sistema que debe ser consolidado sin el menor inconveniente toda vez que requieran actualizar la versión de las PXTools. Por este motivo ambas rutinas aunque no deberían ser editables se incluyen en esta Folder, donde de todos modos ustedes deben respaldar el PXPersonalized que hayan modificado antes de consolidar una nueva versión. Lo otro que pueden hacer es consolidarse en otra KB y leer en los documentos que acompañan a la nueva versión cuales son los cambios que se introducen para simplemente agregar estos cambios a la versión adaptada que mantienen para su sistema. Como dijimos, el SaveContext es la rutina: que justamente hace la carga del Contexto. Esta rutina se llama en el Login, donde cuando el usuario se loguea hay una lógica para que cuando se termina de validar el Login se salve todo lo que se requiere en el Contexto. Entonces este SaveContext lo que hace es recibir el usuario validado (&UsrCod) y el Context (&Context): Página 19 de 74
para que ustedes carguen en él las propiedades con la lógica que tengan implementadas. Por ejemplo pueden haber definido en el Context el nombre del usuario. Porque en la Master Page de vuestro sistema, siempre se muestra el nombre del usuario logueado y no es recomendable que la Master Page esté continuamente yendo a la Base de Datos para conseguir este nombre a partir del User Code. Acuérdense que la Master Page se carga en cada pantalla, entonces lo recomendable es que todo lo que se muestra en la Master Page esté metido en el Context. Entonces esa información se carga la primera vez y muy esporádicamente se actualiza para que siempre esté disponible en memoria, sin trabajo sobre la Base de Datos. En el caso de GCI era la Caja Activa, como vimos en la figura 30:22:38. En otros casos puede tratarse de la Empresa seleccionada, en fin, es información que depende de cada sistema, pero casi siempre se trata de datos que se pueden determinar a partir del Login. Entonces, a partir del usuario, en el momento del Login ustedes pueden implementar las lógicas para determinarlos a partir de la información de sus Bases de Datos (Nombre, Empresa, Caja Activa, etc). Esa lógica es la que deben programar en la rutina SaveContext (figura 50:34:13) y está encapsulada allí de modo que sea transparente para las rutinas que nosotros tenemos de Login. En la figura 50:34:13 ven que tenemos comentada una rutina programada como si se tratara de una Tabla que existiera en el sistema, pero esta Tabla no existe en la distribución de las PXTools Master Page V 5 00:36:45 Pasemos a ver ahora la siguiente subfolder de PXPersonalized: Página 20 de 74
La PXTools_Master Pages. Es interesante porque la carpeta dice Master Pages (en plural): y hay una sola, pero esto fue consecuencia de lo que comentamos al analizar la figura 21:13:52. Hasta hace poco había dos, que eran la Básica y la de Promt (que no mostraba el entorno de Menús), ahora hay sólo una porque está metida toda la lógica de ambas en esta MPWkW01. Por otra parte no está mal el nombre de la carpeta en plural porque puede pasar que ustedes, dependiendo de los requerimientos del sistema que estén desarrollando, tengan que implementar alguna otra Master Page. Por ejemplo, nosotros en GCI nos encontramos que cuando el usuario entraba en el Módulo Financiero importaba saber en qué Caja estaba, pero para el resto de los módulos este concepto no aplicaba. Hubo que implementar una Master Page para mostrar información relativa al Módulo Financiero y otra Master Page para el resto de los módulos. De este modo parte de la información que se muestra en el entorno de navegación es la relativa al módulo en que nos encontramos. Después hay que tener la constancia de que a todos los programas que se desarrollen, asociarle la Master Page que le corresponde según el módulo al que pertenecen, pues esto no es automático. Por defecto a todos los objetos se les puede asociar una Master Page general y para los objetos que requieran alguna Master Page especial, hay una propiedad en los Pattern donde declarar que los mismos tienen asociada otra particular. Más adelante vamos a profundizar sobre las Master Pages. Seguridad V 5 00:38:21 Básicamente las rutinas de Security son estas tres que muestra la figura siguiente (recuadro): Página 21 de 74
de control de seguridad y esta NotAuthorized que está debajo y que simplemente dice en su Web Form: Si por algún motivo el usuario logra llegar a una pantalla a la que no puede acceder por razones de seguridad, el sistema va a llamar automáticamente a esta NotAuthorized. A este Web Panel lo tendrán que diseñar del modo que el sistema que están implementando requiera y por ahora sólo tiene un Event Viewer que automáticamente muestra un mensaje de error que dice no está autorizado. Después tenemos en la Security (figura 50:38:24), la CheckUser : que es una rutina que se usa para el Login. Página 22 de 74
Hemos encapsulado bastante el Login como para que su lógica no haya que tocarla mucho. Hay sistemas en los que el Login puede requerir algo más que usuario y contraseña. Por ejemplo para un sistema de Recursos Humanos que desarrollamos para Argentina se requería ingresar la fecha en que el usuario posicionalmente se quería ubicar y otras cosas por el estilo. Entonces hubo que adaptar el Login a esos requerimientos. Pero si se trata de un Login tradicional de usuario y contraseña, al código no va a haber que tocarlo mucho. Por ejemplo acá, el Login: cuando recibe el usuario y la contraseña se lo pasa a esta rutina (recuadro) que simplemente debe decirnos si son correctos o no. La lógica de lo que habría que hacer en esta rutina es la que aparece comentada en la figura 50:39:07, ir a la Tabla de Usuarios y verificar si este usuario con esa contraseña se encuentra registrado. En caso afirmativo devolver la variable booleana en True, en caso contrario en False. Aprovechamos para mencionar a la rutina PEXE_DePsw01 que es otra API del sistema (figura 50:39:07) y que permite encriptar la password. Hay una API para encriptar password (PEXE_DePsw01) y otra (PEXE_DePsw02) para desencriptarla. Están disponibles por si las quieren usar. En este caso hay una password de ingreso (&UsrPswIng) que se solicita encriptar (&UsrPswEnc) para luego buscar en la Base de Datos por ese valor encriptado (Where UsrPsw = &UsrPswEnc). Obviamente, cuando se crea el usuario y se define la password hay que hacer lo mismo, hay que llamar a la rutina para que nos devuelva la password encriptada y grabar esa password encriptada. Debajo en la figura 50:38:24, tenemos la IsAuthorized : que es una rutina que se llama en el arranque de todas las pantallas, a la que se le pasa por parámetro: Página 23 de 74
el Objeto GeneXus y lo que debe devolver es la confirmación de si está autorizado o no para acceder a él (&Authorized). Aparentemente falta el usuario, pero el usuario se puede obtener del Contexto. Podemos pedir el LoadContext y de éste obtener el Context.UsrCod con el usuario logueado. A modo de tentativa, porque la lógica podría estar basada en roles o en grupos de usuarios, en el Source de esta rutina (figura 50:41:06) habría que agregar: algo por el estilo del código recuadrado en la figura anterior. Esto es sólo una tentativa porque quizá la relación de objetos y usuarios no sea lo más recomendable y hubiera que definir usuarios y grupos de usuarios para que lo que esté asociado al objeto sea el grupo de usuarios. Pero sirve de base para que entiendan bien el concepto. Por defecto todas estas rutinas inicialmente siempre devuelven True para que al comienzo no impidan la ejecución, pero ustedes deberán modificarlas. La última rutina de la carpeta Security, la IsEnabled : Página 24 de 74