Aplicar lógica de negocio a los datos introducidos por el usuario es un paso importante en el desarrollo de plugins QGIS. Sin embargo, un plugin útil hace mucho más que simplemente leer los valores introducidos en una ventana de diálogo. Valida los datos, aplica reglas y toma decisiones en función de las elecciones del usuario.
En este artículo aprenderemos cómo añadir lógica de negocio a un plugin QGIS. Veremos cómo validar los datos introducidos por el usuario, mostrar mensajes informativos y controlar el comportamiento del plugin mediante reglas predefinidas.
Este tutorial está dirigido a principiantes que ya saben crear una ventana de diálogo y recuperar los datos introducidos por el usuario, y que ahora desean hacer que sus plugins sean más inteligentes y fiables.
De los datos introducidos por el usuario a la lógica de negocio
En los artículos anteriores — Desarrollar un plugin QGIS: por qué y cómo crear un plugin, Desarrollar un plugin QGIS: crear un plugin con Plugin Builder y Desarrollar un plugin QGIS: añadir un botón y una ventana — aprendimos a crear un plugin, añadir una interfaz de usuario y recuperar los valores introducidos por el usuario.
En esta etapa, el plugin puede recopilar información, pero todavía no sabe si esa información tiene sentido.
Aquí es donde entra en juego la lógica de negocio.
La lógica de negocio es simplemente un conjunto de reglas que determinan cómo debe comportarse el plugin.
Por ejemplo:
- Una distancia de buffer debe ser mayor que cero.
- Un porcentaje debe estar comprendido entre 0 y 100.
- Un campo obligatorio no puede quedar vacío.
- Una opción avanzada solo debe estar disponible en determinadas condiciones.
Sin estas reglas, un plugin se vuelve frágil y propenso a errores.
Por qué un botón no hace nada por sí solo
Antes de continuar, es importante comprender un concepto fundamental:
Un diálogo Qt no ejecuta ninguna acción por sí mismo.
Su función consiste únicamente en:
- mostrar campos de entrada (cajas de texto, listas desplegables, casillas de verificación, etc.),
- permitir que el usuario introduzca o seleccione valores,
- presentar información mediante una interfaz gráfica.
Si tu plugin no lee explícitamente esos valores y no los utiliza en código Python, no ocurrirá nada, y eso es completamente normal.
La ventana de diálogo es solo una interfaz de usuario. El comportamiento real del plugin está definido por el código que escribes.
¿Dónde se almacenan los valores?
Cada widget mostrado en la ventana de diálogo es un objeto Python creado a partir del archivo .ui.
Algunos ejemplos habituales son:
QLineEdit→ campo de textoQComboBox→ lista desplegableQCheckBox→ casilla de verificaciónQSpinBox→ campo numérico
Estos widgets son accesibles a través del objeto de diálogo (dlg).
Por ejemplo:
self.dlg.lineEdit
self.dlg.comboBox
self.dlg.checkBox
El valor introducido por el usuario se almacena dentro del propio widget.
Tu plugin debe recuperar explícitamente ese valor antes de poder utilizarlo.
Por ejemplo:
name = self.dlg.lineEdit.text()
Esta línea lee el contenido de un campo de texto y lo almacena en la variable name.
A partir de ese momento, el plugin puede aplicar reglas de validación, realizar cálculos o ejecutar algoritmos de procesamiento.
Leer valores: ejemplos sencillos
Una vez que sabes dónde se almacenan los valores, el siguiente paso es recuperarlos desde los widgets de la ventana de diálogo.
Cada tipo de widget tiene su propio método para acceder a los datos introducidos por el usuario.
Campo de texto (QLineEdit)
text = self.dlg.lineEdit.text()
textcontiene el texto introducido por el usuario.
Lista desplegable (QComboBox)
choice = self.dlg.comboBox.currentText()
choicecontiene el elemento actualmente seleccionado.
Casilla de verificación (QCheckBox)
enabled = self.dlg.checkBox.isChecked()
enabledcontiene el valorTrueoFalse.
Campo numérico (QSpinBox)
value = self.dlg.spinBox.value()
valuecontiene un valor numérico.
El momento clave: cuándo leer los valores
Un error muy frecuente entre los principiantes es intentar leer los valores antes de que el usuario haya validado la ventana de diálogo.
En un plugin QGIS típico, los valores solo deben recuperarse después de que el usuario haya aceptado el diálogo.
Por ejemplo:
result = self.dlg.exec_()
if result:
# leer los valores aquí
La llamada a exec_() muestra la ventana de diálogo y espera a que el usuario interactúe con ella.
Si intentas leer los valores antes de ejecutar exec_(), normalmente estarás leyendo campos vacíos o valores predeterminados.
El usuario debe completar la ventana y hacer clic en Aceptar antes de que el plugin pueda acceder de forma fiable a los datos introducidos.
Validar los datos introducidos por el usuario
Imaginemos un plugin que solicita al usuario una distancia de buffer.
Antes de utilizar ese valor, el plugin debe comprobar que es válido.
distance = float(self.dlg.lineEditDistance.text())
if distance <= 0:
QMessageBox.warning(
self.dlg,
«Distancia no válida»,
«Introduzca un valor mayor que cero.»
)
return
En este ejemplo:
- el valor introducido por el usuario se convierte en un número,
- el plugin comprueba si el valor es positivo,
- se muestra un mensaje de advertencia si el valor no es válido,
- el procesamiento se detiene inmediatamente.
Esta sencilla comprobación evita muchos errores innecesarios.
Gestionar campos vacíos
Uno de los errores más comunes de los usuarios es dejar vacío un campo obligatorio.
Por ejemplo:
name = self.dlg.lineEditName.text()
if not name:
QMessageBox.warning(
self.dlg,
«Información incompleta»,
«Introduzca un nombre para el proyecto.»
)
return
En lugar de fallar más adelante, el plugin explica inmediatamente qué información falta.
Esto mejora considerablemente la experiencia del usuario.
Comprobar la existencia de valores obligatorios es una de las formas más sencillas de aumentar la fiabilidad de un plugin.
Distintas entradas, distintas acciones
La lógica de negocio no se limita a validar datos.
También puede determinar qué acción debe ejecutarse.
Imaginemos una lista desplegable con dos modos de procesamiento:
Modo de procesamiento
- Estándar
- Avanzado
El plugin puede ejecutar código diferente según la opción seleccionada.
mode = self.dlg.comboBoxMode.currentText()
if mode == «Estándar»:
self.run_standard_processing()
else:
self.run_advanced_processing()
La misma interfaz puede conducir a flujos de trabajo completamente diferentes.
Combinar varias reglas
Los plugins utilizados en situaciones reales rara vez se basan en una única condición.
Con mucha frecuencia, se combinan varias comprobaciones antes de iniciar el procesamiento.
if distance > 0 and percentage <= 100:
self.process_data()
else:
QMessageBox.warning(
self.dlg,
«Parámetros no válidos»,
«Revise los valores introducidos.»
)
El plugin verifica que todas las condiciones se cumplan antes de continuar.
Este enfoque hace que las herramientas sean más robustas y predecibles.
Proporcionar mensajes útiles al usuario
Los usuarios aprecian los plugins que explican claramente lo que está ocurriendo.
Siempre que sea posible, muestra mensajes claros y comprensibles.
Por ejemplo:
QMessageBox.information(
self.dlg,
«Procesamiento completado»,
«El análisis ha finalizado correctamente.»
)
O bien:
QMessageBox.warning(
self.dlg,
«Entrada no válida»,
«La distancia de buffer debe ser mayor que cero.»
)
Un buen mensaje debe:
- explicar el problema,
- indicar cómo corregirlo,
- evitar términos técnicos innecesarios.
Con frecuencia, un mensaje claro y útil resulta mucho más valioso que una larga traza de error difícil de interpretar.
La lógica de negocio no significa código complejo
Muchos principiantes creen que la lógica de negocio requiere programación avanzada.
En realidad, la mayoría de las reglas de negocio se reducen a una serie de preguntas sencillas:
- ¿Es válido el valor introducido?
- ¿Está vacío el campo?
- ¿Qué opción ha seleccionado el usuario?
- ¿Debe continuar el procesamiento?
La mayoría de los plugins útiles están construidos a partir de muchas pequeñas decisiones, más que de algoritmos sofisticados.
Una buena lógica de negocio suele ser mucho más valiosa que un código complejo.
Probar las reglas
Cada vez que añadas una regla de validación, prueba diferentes situaciones:
- valores válidos,
- valores no válidos,
- campos vacíos,
- entradas inesperadas.
Un plugin debe comportarse correctamente incluso cuando los usuarios cometen errores.
Las pruebas permiten detectar debilidades antes de que lo hagan los propios usuarios.
Errores frecuentes de los principiantes
En esta etapa, los principiantes suelen:
- confiar demasiado en los datos introducidos por el usuario,
- olvidar comprobar si existen campos vacíos,
- mostrar mensajes de error poco claros,
- continuar el procesamiento a pesar de valores no válidos.
Estos errores son completamente normales y resultan cada vez más fáciles de evitar con la práctica.
Lo que has aprendido
Al finalizar este artículo, ya sabes:
- qué es la lógica de negocio,
- por qué es importante validar los datos introducidos por el usuario,
- cómo mostrar mensajes útiles,
- cómo ejecutar acciones diferentes según las elecciones del usuario.
Tu plugin ya no se limita a recopilar información: ahora empieza a tomar decisiones.
¿Y en el próximo artículo?
En el próximo artículo veremos cómo:
- trabajar con la capa activa,
- acceder a las entidades seleccionadas,
- procesar únicamente las entidades seleccionadas.
Es aquí donde tu plugin empieza a interactuar directamente con los datos geográficos y se vuelve realmente útil.
