Crear nuevo modulo
Clonar reporsitorio
Es necesario conectarte al VPN del ORA con los datos de accesos proporcionados.
Url del repositorio:
ssh://[usuario]@172.16.10.20:/opt/git/ora
Comando para clonar:
git clone ssh://[usuario]@172.16.10.20:/opt/git/ora
Módulos disponibles
Estructura de archivos en módulo
Pasos para levantar un nuevo módulo
- Copiar el contenido de la carpeta moduledefault en la carpeta del nuevo módulo(nuevo_modulo).
- Configurar campos en el archivo nuevo_modulo > package.json, es necesario definir un nombre único para el módulo y reemplazarlo en examplemodule.
- Ir a la carpeta recursos_ora y ejecutar los siguientes comandos:
- Dentro de la carpeta nuevo_modulo ejecutar los comandos:
yarn install
yarn link
yarn install
yarn link @ora/recursos
Configurar archivos .env
Es necesario tener disponible el nombre del módulo asignado para el backend, en el ejemplo se tiene como tal a nombremoduloejemplo las urls en BASE_URL deben apuntar al entorno según corresponda REAC_APP_LOCAL_URL es el nombre de la página asignada al módulo después del dominio: para el caso de prueba para la URL https://oraotca.org/basicmodule
solo debemos tomar basicmodule.
.env.production
.env.development
Levantar módulo
Una vez pre configurado el nuevo módulo, podemos levantarlo con el siguiente comando: yarn start. Al terminar de cargar, se mostrará el siguiente mensaje.
Esto nos abrirá una pestaña con el url asignado para el desarrollo del módulo. En caso se muestre el siguiente mensaje, es necesario habilitar el acceso haciendo click en avanzado y luego en procesar.
Al cargar el contenido en la web este apunta a https://localhost:3000/wp-content/plugins/ora-examplemodule/build es necesario que la url local apunte a unos de los urls ya configurados para este módulo.
Módulo de ejemplo
Este es el resultado del módulo de ejemplo una vez levantado.
Contenido de una vista que tenga habilitado el uso de la intranet.
Agregar rutas al módulo
En el archivo nuevo_modulo > indexj.js la variable listUrls contiene las rutas y componentes ligados a esta, así como opciones de autenticación y permisos.
- auth: define si a ruta debe verificar si usuario necesita haber iniciado sesión.
- path: url asignada a la vista.
- comoponent: componente asignado a la vista para la ruta.
- can: asignar permisos para la vista, ejemplo: permiso1, permiso2, permiso_tres
Cuerpo del módulo
En el archivo nuevo_modulo > indexj.js se encarga de renderizar el cuerpo sobre el que cargarán nuestras vistas. Se deben configurar unas tres secciones de ser necesarios.
- (1) modulo de traducción: se puede asignar un conjunto de traducciones del propio módulo o de otro módulo, pero por defecto siempre carga las traduccines generales.
- (2) redirección despues de iniciar sesión: Modificar en caso no necesitemos que redireccione a una ruta diferente.
- (3) root renderizado: este es el id sobre el cuál va a correr nuestro aplicativo de React deben ser modificados en este apartado como en el de
nuevo_modulo > public > index.html.
// public/index.html 31 <div id="modulodefault_app" class="ora_apps"></div>
Estructura de los archivos de idiomas:
Dentro del repositorio principal existe la carpeta languages en ello se tienen carpetas con las traduccines de cada módulo, de esta manera no sobrecargamos un solo fichero y se puede personalizar y sobreescribir una variable de traducción dependiendo del módulo.
Por cada carpeta existen tres ficheros location.xx.json por cada idioma. Cada fichero tiene la estructura JSON mostrada en la imagen de arriba, es en content donde agregaremos nuestras traducciones en la forma «key»: «value»
Views
Las vistas de cada ruta están basadas en React Class Component los ficheros en nuevo_modulo > src > components > views poseen la estructura mínima para tener una vista.
Tomando en cuenta el fichero nuevo_modulo > src > components > views > Protegido2.jsx existe un proceso para dar persistencia a cierto grupo de datos según sea necesario. En el constructor se verifica si el datos almacenado en un LocalStorage existe, de no ser así se procede a realizar la carga de estos y guardarlos en los states del componenete según corresponda. Los datos obtenidos persisten durante toda la aplicación.
También existe una función en la cual podemos definir cierto comportamiento de la vista:
- titulo: Define el título que se mostrará, en esa misma línea se hace uso de la propiedad this.props.language() la cual nos permite obtener el valor traducido de una variable y asignarle un valor por defecto en caso no exista.
- isbackend: Definir si mostramos en menú de intranet, debe considerarse que este menú solo debe ser mostrado si el usuario inició sesión.
- hasBreadcrumb: Definir si mostrar el breadcrumb.
- hasHeroBar: Definir si mostrar la barra superior donde se encuentran el título, sutítulo y breadcrumb.
- be_itemselect: etiqueta única para la vista que se utiliza para activar el item referenciado en el menú de intranet.
- breadcrumb: definir los elementos del breadcrumb.
La función render debe tener siempre como primer componente BasePageRoute2 que viene desde la paquetería de @ora/recursos. Este componente maneja la estructura del menú intranet, el título y las traducciones.
Consideraciones por cada componente
Agregar HEADER a las peticiones al backend
Es necesario agregar una HTTP Authorization como medida de seguridad, para ello se implementan varios funciones. Estas funciones están en el apartado Helpers.ValidationAuth de @ora/recursos.
Agregar token a urls
Existen casos en el que se soliciten url de manera directa, pero al no poder modifica el header podemos pasar como parámetro la variable token siempre y cuando este esté disponible. En el ejemplo de abajo, obtenemos el hash del token proporcionado para el módulo y lo asignamos a la variable token. Debe considerarse que la url solicitada está configurada para recibir ese parámetro (revisar sección de backend)
Configurar backend
Dentro de la raíz del repositorio tenemos la carpeta ci4 en el cual se encuentra el backend hecho en PHP con el framework CodeIgniter. La carpeta está separada por módulos. Dentro de cada módulo existen las carpetas Config, Controllers y Models. Para un nuevo módulo solo basta con copiar la carpeta ModuloEjemplo y hacer las modificaciones para acondicionarlo a un módulo personalizado.
De ser posible revisar la documentación de Code Igniter, no se hizo modificaciones sobre el core, pero se agregaron características para los Modelos y Controladores.
Rutas
Las urls deben estar agrupadas, de esta manera podemos decir que nuestro conjunto de Urll solo pertenecen a «nuestro módulo». Tomando como ejemplo la imagen de abajo.
Resultado de lo declarado en el ejemplo, se puede notar que nombremoduloejemplo es el nombre que formará parte de la url y con el que agruparemos nuestras url para este módulo.
- https://dominio.com/nombremoduloejemplo/listaprueba
- https://dominio.com/nombremoduloejemplo/listaprueba2
- https://dominio.com/nombremoduloejemplo/listadotodo
El namespace debe apuntar a la carpeta de controladores de nuestro módulo como es en el caso de Modules\ModuloEjemplo\Controller.
Debajo de las urls que podamos definir, debemos hacer unas configuraciones adicionales, en este caso tenemos un $scope con el mismo nombre con el que agrupamos nuestras urls, en protected declaramos las url que deben pasar por autenticación, en public, aquellas que solo necesitan una autenticación básica(las que poseen cada módulo) y en tokenUrl están aquellas url que pueden recibir la variable token y no usar un HTTP Authorization.
En este apartado es posible restringir el acceso a las url, mediante la propiedad filter en el que se define a can, seguido de los permisos a los que pertence: can:permisoo1, permiso2;permiso_tress
Controladores
Para el caso de los controladores se agregó CustomResourceController el cuál nos permite identificar el idioma y arrancar con el helper de traducciones y permisos.
Modelos
Los modelos también reciben una configuración adicional, deben agregarse los traits TraitImport y TraitBaseModel, adicional a ello, debe definirse el schema al cual pertenece dicho modelo.
