Fundamentos

Módulo uno. Su primera aplicación Wisej.NET. Construiremos una pequeña pantalla que solicite un nombre y muestre un saludo. Esto presenta el flujo de trabajo básico: diseñar la interfaz, manejar un evento y probar el resultado en un navegador.

Comience en Visual Studio y elija Crear un nuevo proyecto. Wisej.NET utiliza el flujo de trabajo de proyecto familiar, con plantillas que proporcionan los archivos de aplicación iniciales. La interfaz se ejecutará en el navegador, mientras que nuestro código de evento se ejecutará en el servidor.

Busque Wisej.NET. Este tutorial utiliza la plantilla de aplicación web Wisej.NET 4 con C#. Seleccione esa plantilla y continúe. Si falta en su propia instalación, verifique que la extensión Wisej.NET y las plantillas de proyecto estén instaladas antes de continuar.

Elija un nombre de proyecto y una ubicación, luego haga clic en Crear. Visual Studio genera el proyecto y su ventana de inicio. Mire Solution Explorer: aquí es donde encontrará los archivos de la aplicación y regresará a la ventana a medida que construye la pantalla.

Construya el proyecto antes de abrir el diseñador. La compilación compila la aplicación para que el diseñador pueda cargar sus tipos. Mire la ventana de Salida y espere a que la compilación se haya realizado correctamente. Si la compilación falla, resuelva los errores antes de continuar con el diseño.

En Solution Explorer, haga doble clic en Window1 para abrir su vista de diseño. Esta es la superficie donde disponemos los controles. El diseñador registra su diseño en Window1.Designer.cs. Mantenga ese archivo generado bajo el control del diseñador; escriba el comportamiento de la pantalla en Window1.cs.

Arrastre los controles del Toolbox a la ventana. Una etiqueta solicita el nombre del usuario, un cuadro de texto acepta la respuesta y un botón ejecutará el saludo. Agregue una segunda etiqueta para el resultado. Cada control ahora tiene un papel claro en la interacción.

Configure Name y Text de cada control en la ventana Propiedades. Name es el identificador utilizado por su código; Text es lo que ve el usuario. Utilice txtName para la entrada, btnSayHello para el botón y lblStatus para el resultado. La etiqueta del título es lblTitle.

Haga doble clic en el botón para crear su controlador Click. Lea txtName.Text y recorte los espacios. Si el resultado está vacío, configure lblStatus.Text como un mensaje que solicite un nombre y luego regrese. En caso contrario, pon el saludo en la etiqueta. La validación ocurre antes de la respuesta exitosa.

Presione Inicio para ejecutar la aplicación localmente. Cuando se abra el navegador, ingrese un nombre y haga clic en Saludar. El controlador Click se ejecuta y la etiqueta del resultado muestra el saludo. Ha conectado una pantalla diseñada visualmente al código C# y ha visto la respuesta en el navegador.

En esta lección, crearemos un panel Wisej.NET en Visual Studio Designer. Organizaremos sus controles, les daremos nombres significativos y conectaremos un botón a un controlador Click. Verás qué trabajo pertenece al diseño generado y cuál pertenece a tu propio código.

Abra DashboardWindow en la vista de diseño. Esta ventana recopilará el estado del servicio, los comandos y el historial de eventos en un solo lugar, para que los usuarios puedan comprender el resultado de cada acción sin cambiar de pantalla.

Utilice el diseñador para organizar los controles, el Toolbox para agregarlos y la ventana Propiedades para configurarlos. Estas tres superficies funcionan juntas: seleccione un control en el lienzo antes de cambiar sus propiedades.

Agregue un encabezado y una etiqueta de estado separada, luego coloque las tres etiquetas de servicio dentro de un panel. El panel agrupa información relacionada, mientras que el estado general sigue siendo fácil de encontrar encima de él.

Agregue los botones Iniciar, Detener, Restablecer y Actualizar, seguidos de la lista de eventos. Los botones inician acciones; la lista explica lo que pasó. Mantener ese historial visible hace que las acciones repetidas sean más fáciles de seguir.

Configure Text para las palabras que ve el usuario y Name para el identificador que utiliza su código. Un nombre como btnStart debería identificar el propósito del control, de modo que su controlador de eventos sea fácil de localizar más adelante.

Haga doble clic en Inicio para crear su controlador de clic. Actualice las etiquetas de estado allí y llame a un ayudante para agregar el evento. La reutilización del asistente de registro mantiene el historial de eventos coherente en los cuatro comandos.

Comportamiento de escritura en el archivo C# normal de la ventana. El diseñador mantiene su propio archivo generado para la creación y el diseño de controles. Mantener esas responsabilidades separadas evita que un cambio de diseño posterior sobrescriba su lógica escrita a mano.

Ejecute el proyecto y espere a que se abra el navegador. La pantalla que diseñó ahora es la interfaz de usuario de la aplicación en ejecución. Comprueba su estado inicial antes de probar los botones.

Click Inicie y observe cómo las tres etiquetas de servicio cambian a En línea. El estado general pasa a ser En ejecución y la lista de eventos registra la acción. Esos cambios visibles deberían concordar entre sí.

Click Deténgase a continuación. Cada servicio pasa a estar fuera de línea y una nueva entrada registra la parada. Mantener la entrada de inicio anterior permite al usuario ver la secuencia de acciones en lugar de solo el estado actual.

Click Restablecer para devolver la demostración a su estado inicial. Las entradas del registro anterior desaparecen y el estado pasa a estar inactivo. Registre el reinicio para que el historial vacío tenga una explicación comprensible.

Finalmente, haga clic en Actualizar para leer nuevamente el estado actual y agregar una entrada de registro. Actualizar comprueba el estado; no significa Iniciar o Restablecer. Los comandos distintos deberían producir resultados distintos y comprensibles.

Construiremos un shell compartido para la aplicación para que cada página utilice la misma navegación y diseño. El encabezado, el área de navegación, la región de contenido y la barra de estado tienen cada uno una función clara. Centralizar los cambios de página también nos brinda un lugar para reflejar los permisos del usuario actual en la navegación.

Observe cómo el marco exterior permanece en su lugar mientras cambia la vista central. Este shell compartido le da a cada función un hogar consistente y evita reconstruir la navegación en cada pantalla.

Organice el encabezado, la navegación, el área de contenido y la barra de estado como regiones separadas. Cada uno tiene una responsabilidad diferente: orientación, elección de una característica, realización del trabajo e informe del resultado.

Coloque el encabezado en la parte superior, la navegación a la izquierda y la barra de estado en la parte inferior. Deje que el contenido llene el espacio restante para que el cambio de tamaño preserve la estructura general.

Enrute cada botón de navegación a través de NavigateTo. Un único método puede aplicar las mismas reglas de cambio de página de forma coherente; Las implementaciones separadas en cada botón variarían a medida que se agreguen funciones.

Siga a NavigateTo a través del cambio de página: elimine el contenido anterior, cargue la vista seleccionada y luego actualice la ruta de navegación y el estado. Los comentarios de navegación deben describir la vista realmente mostrada.

La configuración permanece visible para el agente de soporte, pero Guardar está deshabilitado en esta demostración. Esto ilustra un permiso en la interfaz; el trabajo de autenticación posterior también debe hacer cumplir la autorización real.

El shell ahora separa la navegación compartida de las vistas de funciones reutilizables. Al agregar una página, conéctela a través del mismo método de navegación y verifique que su ubicación y estado permanezcan claros.

Mostraremos una lista de tickets en un DataGridView y conectaremos el ticket seleccionado a los controles de detalle. Un servicio proporcionará los datos, mientras la pantalla coordina la selección y visualización. Esta separación mantiene las decisiones comerciales y de bases de datos fuera del alcance de los controladores de eventos de la interfaz de usuario.

Cree el editor de tickets en torno a un modelo de datos compartido en lugar de copiar valores entre controles no relacionados. Binding conecta el registro seleccionado a la pantalla, mientras el servicio maneja las operaciones de tickets.

Coloque los campos de detalles a la izquierda y deje que la cuadrícula del ticket llene el lado derecho del contenedor dividido. Los usuarios pueden seleccionar un registro e inspeccionar sus detalles sin salir de la lista.

El ticket describe los campos de un registro. TicketService proporciona operaciones como cargar y guardar. La pantalla llama a esas operaciones en lugar de convertirse en el lugar donde se implementan las reglas de persistencia.

Conecte la lista y la cuadrícula a través de un BindingSource, luego vincule los campos de detalles a esa misma fuente. Compartir el registro actual mantiene el título, el estado, la prioridad y la descripción alineados con la selección.

Primero guarde a través de TicketService, luego notifique al sistema de vinculación con ResetBindings. Actualizar la pantalla es independiente de guardar los datos: una cuadrícula actualizada por sí sola no prueba que la persistencia haya sido exitosa.

Ejecute el editor y seleccione diferentes filas de tickets. Mire los campos de detalle siga la selección a través de BindingSource. Esto confirma que la cuadrícula y el editor comparten el mismo registro actual.

Cambie el estado del ticket seleccionado y haga clic en Guardar ticket. Siga la operación hasta el servicio y regrese a la red actualizada. La fila visible ahora debería reflejar el valor que guardó.

Mantenga separadas las responsabilidades del modelo, el servicio y la pantalla. Cuando un valor parece incorrecto, esta separación le brinda una pregunta útil: ¿el registro es incorrecto, falló el guardado o la visualización está obsoleta?

Usaremos un cuadro de diálogo para crear un ticket o editar uno existente. El cuadro de diálogo verifica los campos obligatorios e informa que la operación se realizó correctamente solo después de que la operación se haya realizado correctamente. Las operaciones de tickets permanecen en la capa de servicio, por lo que se aplican las mismas reglas en cualquier pantalla que abra el cuadro de diálogo.

Cree un cuadro de diálogo enfocado para ingresar un ticket y editar uno existente. Proporcione resultados distintos a Guardar y Cancelar para que cerrar el cuadro de diálogo nunca implique silenciosamente que se aceptaron los datos.

Agrupe los campos del ticket dentro del cuadro de diálogo y mantenga Guardar y Cancelar fáciles de encontrar. El diálogo debe recopilar un cambio coherente, con suficiente información para que el usuario la revise antes de aceptarlo.

Inicialice el mismo cuadro de diálogo de forma diferente para cada flujo de trabajo. Lo nuevo comienza con una entrada vacía; Editar carga el ticket seleccionado. La reutilización del diseño mantiene la coherencia de los dos flujos de trabajo sin confundir sus estados iniciales.

Ejecute ValidateForm antes de devolver un resultado aceptado. Si faltan valores requeridos, mantenga el cuadro de diálogo abierto. DialogResult.OK debe comunicar una entrada aceptada válida, no simplemente que se presionó el botón Guardar.

Abra Nuevo e intente guardar sin título. El mensaje identifica la información que falta y el cuadro de diálogo permanece abierto, dándole al usuario la oportunidad de corregir la entrada sin reiniciar la operación.

Complete los campos requeridos y acepte el diálogo. Luego, el padre llama a TicketService y actualiza la cuadrícula. Siga ese orden para que el usuario vea el resultado del cambio aceptado y guardado.

Seleccione un ticket existente y abra Editar. Sus valores actuales deberían aparecer en el mismo cuadro de diálogo. Cambie un campo, guárdelo y verifique que la fila correspondiente se actualice en lugar de crear otro ticket.

Utilice la misma secuencia para ambos flujos de trabajo: validar, aceptar, guardar a través del servicio y actualizar. Mantener esas etapas explícitas hace que los errores de cancelación y validación sean más fáciles de manejar sin escrituras accidentales.

Ejecutaremos una exportación o importación simulada en segundo plano y mostraremos su progreso sin bloquear la interfaz. Cada usuario conectado mantendrá su propio estado de operación. También manejaremos las fallas con un mensaje útil para el usuario mientras mantenemos los detalles del error interno fuera de la pantalla.

Utilice la demostración de exportación e importación para seguir un trabajo a lo largo del tiempo. Una pantalla receptiva necesita más que una barra de progreso: los usuarios deben comprender si el trabajo se está ejecutando, finalizado, cancelado o fallido.

Mantenga visibles juntos los comandos de inicio, cancelación, progreso y registro. Responden a diferentes preguntas: ¿qué puedo hacer, hasta dónde ha avanzado el trabajo y qué ha sucedido ya?

En RunJobAsync, espere cada paso e informe su progreso. Utilice el controlador de errores para fallas y el bloque finally para limpieza, de modo que la interfaz pueda dejar su estado ocupado incluso cuando falla el trabajo.

Inicie Importar y observe cómo cambian los controles mientras se ejecuta el trabajo. Deshabilite los comandos que entrarían en conflicto con la operación activa, pero mantenga el progreso y los comentarios disponibles para que el usuario pueda seguir el trabajo.

Mantenga el progreso y otros valores específicos del usuario en la sesión actual. Un campo estático se comparte entre los usuarios, por lo que almacenar el estado del trabajo de una persona allí podría hacer que otra persona lo vea o lo cambie.

Habilite Simular error y ejecute el trabajo nuevamente. Mantenga los detalles de diagnóstico en el registro para su investigación, mientras el usuario recibe un breve mensaje de seguridad. Los detalles de la excepción técnica no deben convertirse en texto de error público.

El botón inicia la operación, el trabajo realiza el trabajo y la pantalla informa su estado. Mantenga estos roles separados para que el éxito, la cancelación y el fracaso puedan devolver la interfaz a una condición utilizable.

Actualizaremos la apariencia del panel mediante un tema integrado, tarjetas y una navegación consistente. Los servicios, la validación y el enlace de datos existentes seguirán haciendo su trabajo. Esto nos permite mejorar la forma en que los usuarios leen y navegan por la pantalla sin reescribir el comportamiento comercial de la aplicación.

Modernice la pantalla existente sin reconstruir su comportamiento. Un tema Wisej.NET ofrece opciones visuales consistentes; Las mejoras en el diseño y la navegación hacen que la aplicación sea más fácil de entender.

Haga que el título de la página sea fácil de identificar, agrupe métricas relacionadas y coloque comandos junto al contenido al que afectan. La jerarquía visual debería ayudar a los usuarios a decidir dónde buscar y qué hacer a continuación.

El selector de temas cambia Application.Theme.Name, mientras que SetActiveButton marca el elemento de navegación seleccionado. Trate la apariencia y la ubicación como preocupaciones separadas para que los usuarios aún sepan dónde están después de cambiar de tema.

Cambie entre los temas integrados y compare los mismos controles. Su apariencia cambia mientras el flujo de trabajo sigue siendo el mismo. Verifique la legibilidad y los estados activos en lugar de juzgar el tema solo por sus colores.

Revise el panel terminado en su totalidad. El espaciado, las tarjetas y la navegación consistentes deben respaldar el enlace y la validación de datos existentes. Se produce una actualización visual cuando el flujo de trabajo familiar se vuelve más claro.

Agregaremos una pequeña visualización del estado de JavaScript a una pantalla de Wisej.NET. Los controles nativos seguirán manejando la interacción ordinaria y C# será el propietario de los datos, las decisiones y el registro. El widget mostrará los valores que recibe, brindándonos un objeto visual especializado sin crear una segunda fuente de estado de la aplicación.

Agregue una pequeña visualización JavaScript a la aplicación Wisej.NET existente. Mantenga la lógica principal en C# para que el elemento visual adicional no se convierta en un segundo propietario de las decisiones de la aplicación.

Utilice etiquetas, botones y registros nativos Wisej.NET para una interacción normal. Introduzca un Widget solo para el visual especializado. Esto mantiene la integración enfocada en lugar de reemplazar los controles que ya resuelven el problema.

Envíe al widget solo los valores de visualización que necesita: estado, recuento de tickets y carga del sistema. C# sigue siendo responsable de esos valores; la visualización del navegador los presenta sin recibir datos del servidor no relacionados.

El controlador de botones actualiza las etiquetas nativas y envía los mismos datos a través de UpdateWidget. Usar un resultado para ambas presentaciones evita que el texto y la visualización describan estados diferentes.

Click Actualiza los datos del servidor y compara las etiquetas con el widget. Deberían cambiar juntos desde la misma operación del servidor. Si no están de acuerdo, inspeccione los datos pasados ​​a través del límite de integración.

Pruebe Saludable, Advertencia y Crítico por turnos. Los eventos de C# actualizan el estado visual y registran el cambio. El historial de eventos ayuda a explicar por qué el widget tiene su apariencia actual.

Revisaremos la aplicación antes de empaquetarla para su lanzamiento. La configuración, los secretos, el registro y los permisos necesitan una verificación explícita. El flujo de trabajo de lanzamiento utilizará esas comprobaciones para decidir si el paquete está listo, manteniendo al mismo tiempo los detalles confidenciales fuera de los mensajes dirigidos al usuario.

Utilice la pantalla de revisión para recopilar pruebas antes de su liberación. Las comprobaciones de configuración, seguridad e implementación pertenecen a un proceso repetible, por lo que la preparación depende de las comprobaciones completadas y no de una impresión tranquilizadora.

Registre primero el entorno, el destino del alojamiento, la versión y el revisor. Estos detalles identifican exactamente lo que se está revisando; una lista de verificación completa para un entorno no cubre automáticamente un objetivo de lanzamiento diferente.

Realice las comprobaciones de configuración requeridas por separado de las notas opcionales. Una nota puede explicar una excepción, pero no debe hacer que una verificación requerida faltante desaparezca de la decisión de preparación.

Mantenga secretos y excepciones detalladas fuera de la pantalla de revisión. Muestre un resumen seguro y deje detalles de diagnóstico en los registros del servidor, para que el paquete de revisión se pueda compartir sin exponer las credenciales.

Separe la preparación del permiso. Las comprobaciones requeridas determinan si la revisión está completa, mientras que una verificación de roles determina quién puede crear el paquete. Pasar la lista de verificación no otorga al usuario autoridad adicional.

Complete los elementos requeridos restantes y observe cómo la cuenta llega a nueve de nueve. El estado cambia a Listo para revisión. Eso significa que la lista de verificación está completa, no que el despliegue ya se haya producido.

Cree el paquete de revisión e inspeccione su resumen, incluidos los problemas conocidos y la información de reversión. Un traspaso útil le dice al revisor qué está listo, qué sigue siendo incierto y cómo recuperarse si falla la publicación.

Módulo diez. Cree el mini servicio de asistencia técnica Wisej.NET. Este final reúne el curso en una sola aplicación. Seguiremos su navegación, flujo de trabajo de tickets y pantallas de soporte, luego veremos qué hace que el proyecto esté listo para su revisión e implementación.

Comience con la aplicación completa y siga su capa de navegación. Los ejemplos de cursos separados ahora comparten un diseño, por lo que los usuarios pueden moverse entre funciones sin aprender un nuevo patrón de navegación cada vez.

Siga Tickets, Clientes y Empleos a través de sus principales interacciones. Las cuadrículas presentan registros, los cuadros de diálogo recopilan cambios y los trabajos en segundo plano informan del progreso. Después de cada acción, comprueba que el resultado visible explica lo que realmente sucedió.

Rastree un cambio de boleto a través de sus responsabilidades. El cuadro de diálogo valida la entrada, TicketService maneja la operación y la cuadrícula presenta el resultado. Etiquetas consistentes y mensajes de estado conectan esas etapas para el usuario.

Utilice Despliegue y Arquitectura para explicar la aplicación más allá de sus pantallas. Revise la configuración, la seguridad y el registro, luego rastree los datos a través de la capa de servicio. Una manifestación de trabajo también debería hacer comprensible su organización.

Termine con la revisión del código y los próximos pasos. Verifique los nombres específicos y las responsabilidades claras, luego registre el trabajo de producción restante. El final demuestra una aplicación funcional al mismo tiempo que hace explícitos el trabajo inacabado y las decisiones de diseño.