Blog GIS & Territories

Collecting user input is an important milestone in QGIS plugin development. However, a useful plugin does more than simply read values entered in a dialog box. It validates data, applies rules, and makes decisions based on the user’s choices.

In this article, we will learn how to add business logic to a QGIS plugin. We will see how to validate user input, display helpful messages, and control the plugin’s behavior according to predefined rules.

This tutorial is aimed at beginners who already know how to create a dialog and retrieve user input, and who now want to make their plugins smarter and more reliable.

From User Input to Business Logic

In the previous article – Developing a QGIS Plugin: Why and How to Create a Plugin , Developing a QGIS Plugin: Creating a Plugin with Plugin Builder , Developing a QGIS Plugin: Adding a Button and a Dialog – we learned how to create a plugin, add a user interface, and retrieve values entered by the user..

At that stage, the plugin can collect information, but it does not yet know whether that information makes sense.

This is where business logic comes in.

Business logic is simply a set of rules that determine how your plugin should behave.

For example:

• A buffer distance must be greater than zero.
• A percentage must be between 0 and 100.
• A required field cannot be empty.
• An advanced option should only be available under specific conditions.

Without these rules, a plugin becomes fragile and prone to errors.

Why a Button Does Not “Do Anything” by Itself

Before going further, it is important to understand a fundamental concept:

A Qt dialog does not perform any action on its own.

Its role is simply to:

• display input fields (text boxes, drop-down lists, check boxes, etc.),
• allow the user to enter or select values,
• present information in a graphical interface.

If your plugin does not explicitly read those values and use them in Python code, nothing happens—and that is perfectly normal.

The dialog is only a user interface. The actual behavior of the plugin is defined by the code you write.

Where Are the Values Stored?

Every widget displayed in the dialog is a Python object created from the .ui file.

Common examples include:

• QLineEdit → text field
• QComboBox → drop-down list
• QCheckBox → check box
• QSpinBox → numeric input

These widgets are accessible through the dialog object (dlg).

For example:

self.dlg.lineEdit
self.dlg.comboBox
self.dlg.checkBox

The value entered by the user is stored inside the widget itself.

Your plugin must explicitly retrieve that value before it can use it.

For example:

name = self.dlg.lineEdit.text()

This line reads the contents of a text field and stores it in the variable name.

From that point on, your plugin can apply validation rules, perform calculations, or launch processing algorithms.

Reading Values: Simple Examples

Once you know where the values are stored, the next step is to retrieve them from the dialog widgets.

Each widget type has its own method for accessing the user’s input.

Text Field (QLineEdit)

text = self.dlg.lineEdit.text()

text contains whatever the user typed into the field.

Drop-Down List (QComboBox)

choice = self.dlg.comboBox.currentText()

choice contains the currently selected item.

Check Box (QCheckBox)

enabled = self.dlg.checkBox.isChecked()

enabled contains either True or False.

Numeric Field (QSpinBox)

value = self.dlg.spinBox.value()

value contains a numeric value.

The Critical Moment: When to Read Values

A common beginner mistake is trying to read values before the user has validated the dialog.

In a typical QGIS plugin, values should be retrieved only after the dialog has been accepted.

For example:

result = self.dlg.exec_()

if result:
    # read the values here

The call to exec_() displays the dialog and waits for the user to interact with it.

If you try to read the values before exec_() is executed, you are usually reading empty fields or default values.

The user must first fill in the dialog and click OK before your plugin can reliably access the entered data.

Validating User Input

Imagine a plugin that asks the user to enter a buffer distance.

Before using that value, the plugin should verify that it is valid.

distance = float(self.dlg.lineEditDistance.text())

if distance <= 0:
    QMessageBox.warning(
        self.dlg,
        "Invalid Distance",
        "Please enter a value greater than zero."
    )
    return

In this example:

• the value entered by the user is converted to a number,
• the plugin checks whether the value is positive,
• a warning message is displayed if the value is invalid,
• processing stops immediately.

This simple check prevents many avoidable errors.

Handling Empty Fields

One of the most common user mistakes is leaving a required field empty.

For example:

name = self.dlg.lineEditName.text()

if not name:
    QMessageBox.warning(
        self.dlg,
        "Missing Information",
        "Please enter a project name."
    )
    return

Instead of failing later, the plugin immediately explains what is missing.

This greatly improves the user experience.

Checking for missing values is one of the simplest ways to improve the reliability of a plugin.

Different Inputs, Different Actions

Business logic is not limited to validation.

It can also determine which action should be performed.

Imagine a combo box containing two processing modes:

Processing Mode
- Standard
- Advanced

The plugin can execute different code depending on the selected option.

mode = self.dlg.comboBoxMode.currentText()

if mode == "Standard":
    self.run_standard_processing()
else:
    self.run_advanced_processing()

The same interface can therefore lead to completely different workflows.

Combining Multiple Rules

Real-world plugins rarely rely on a single condition.

More often, several checks are combined before processing begins.

if distance > 0 and percentage <= 100:
    self.process_data()
else:
    QMessageBox.warning(
        self.dlg,
        "Invalid Parameters",
        "Please review the values entered."
    )

The plugin verifies that all conditions are satisfied before continuing.

This approach makes tools more robust and predictable.

Providing Useful Feedback

Users appreciate plugins that explain what is happening.

Whenever possible, display clear messages.

For example:

QMessageBox.information(
    self.dlg,
    "Processing Complete",
    "The analysis finished successfully."
)

Or:

QMessageBox.warning(
    self.dlg,
    "Invalid Input",
    "The buffer distance must be greater than zero."
)

Good messages should:

• explain the problem,
• indicate how to fix it,
• avoid unnecessary technical terms.

A helpful message is often better than a detailed error traceback.

Business Logic Does Not Mean Complex Code

Many beginners assume that business logic requires advanced programming.

In reality, most business rules are simply a series of questions:

• Is the value valid?
• Is the field empty?
• Which option was selected?
• Should processing continue?

Most useful plugins are built from many small decisions rather than sophisticated algorithms.

Good business logic is often more valuable than sophisticated code.

Testing Your Rules

Whenever you add validation rules, test several situations:

• valid values,
• invalid values,
• empty fields,
• unexpected inputs.

A plugin should behave correctly even when users make mistakes.

Testing helps identify weaknesses before your users do.

Common Beginner Mistakes

At this stage, beginners often:

• trust user input too much,
• forget to check for empty fields,
• display vague error messages,
• continue processing despite invalid values.

These mistakes are normal and become easier to avoid with experience.

What You Have Learned

By the end of this article, you now understand:

• what business logic is,
• why input validation is important,
• how to display helpful messages,
• how to execute different actions depending on user choices.

Your plugin is no longer just collecting information—it is starting to make decisions.

What’s Next?

In the next article, we will see how to:

• work with the active layer,
• access selected features,
• process only the selected features.

This is where your plugin begins to interact directly with geographic data and becomes truly useful.

Si cet article vous a intéressé et que vous pensez qu'il pourrait bénéficier à d'autres personnes, n'hésitez pas à le partager sur vos réseaux sociaux en utilisant les boutons ci-dessous. Votre partage est apprécié !

Atilio Francois