2026-06-01 17:13:22 +02:00
|
|
|
Name and parameter conflict
|
|
|
|
|
================================
|
2026-05-31 21:22:53 +02:00
|
|
|
|
|
|
|
|
.. objectives:: Objectives
|
|
|
|
|
|
2026-06-02 09:03:12 +02:00
|
|
|
When a variable name conflicts with a family parameter,
|
2026-06-01 15:05:47 +02:00
|
|
|
do we have to abandon the variable name choice we made?
|
|
|
|
|
No because having a suitable variable name is really important.
|
|
|
|
|
The variable name you chose is undoubtedly the best.
|
2026-05-31 21:22:53 +02:00
|
|
|
|
2026-06-01 15:05:47 +02:00
|
|
|
Sometimes, the choice of a variable's name may correspond very exactly
|
2026-06-02 09:03:12 +02:00
|
|
|
to an parameter of the family in which that variable is placed...
|
2026-06-01 15:05:47 +02:00
|
|
|
|
2026-06-02 09:03:12 +02:00
|
|
|
In this section, we will learn how to create a variable name that conflict with a defined parameter name.
|
2026-05-31 21:22:53 +02:00
|
|
|
|
|
|
|
|
.. prerequisites:: Prerequisites
|
|
|
|
|
|
|
|
|
|
- We assume that Rougail's library is :ref:`installed <installation>` on your computer.
|
|
|
|
|
|
|
|
|
|
- It is possible to retrieve the current state of the various Rougail files manipulated in this tutorial step
|
|
|
|
|
by checking out the corresponding tag of the `rougail-tutorials` git repository.
|
|
|
|
|
Each tag corresponds to a stage of progress in the tutorial.
|
|
|
|
|
Of course, you can also decide to copy/paste or download the tutorial files contents while following the tutorial steps.
|
|
|
|
|
|
|
|
|
|
If you want to follow this tutorial with the help of the corresponding :tutorial:`rougail-tutorials git repository <src/branch/1.1>`,
|
|
|
|
|
this workshop page corresponds to the tag :tutorial:`v1.1_210 <src/tag/v1.1_210/README.md>`
|
|
|
|
|
in the repository.
|
|
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
git clone https://forge.cloud.silique.fr/stove/rougail-tutorials.git
|
|
|
|
|
git switch --detach v1.1_210
|
|
|
|
|
|
|
|
|
|
.. type-along:: Let's recap how far we've come
|
|
|
|
|
|
2026-06-01 15:05:47 +02:00
|
|
|
FIXME: changer le nom leadership
|
|
|
|
|
|
2026-05-31 21:22:53 +02:00
|
|
|
We have this leadership family in its structure definition file:
|
|
|
|
|
|
|
|
|
|
.. extinclude:: https://forge.cloud.silique.fr/stove/rougail-tutorials/raw/tag/v1.1_202/foxyproxy/00-foxyproxy.yml
|
|
|
|
|
:linenos:
|
|
|
|
|
:language: yaml
|
|
|
|
|
:caption: The `proxies` family with `leadership` type in the :file:`foxyproxy/00-foxyproxy.yml` structure file
|
|
|
|
|
|
2026-06-02 09:03:12 +02:00
|
|
|
The variable "type" that conflits with the family parameter "type"
|
2026-06-01 15:05:47 +02:00
|
|
|
----------------------------------------------------------------------------
|
2026-05-31 21:22:53 +02:00
|
|
|
|
|
|
|
|
Choice a good variable name is important. It's with this name that user will interact with here value.
|
|
|
|
|
|
|
|
|
|
The user has to define the type of the new proxy. So instinctively the name of the variable will be `type`.
|
|
|
|
|
|
2026-06-02 09:03:12 +02:00
|
|
|
But in the current family we have already the parameter `type` with the `leadership` value.
|
2026-05-31 21:22:53 +02:00
|
|
|
YAML do not permit to have two key with the same name.
|
|
|
|
|
Maybe we could choice an other variable name like `proxy_type` but the full path will be `proxies.proxy_type`.
|
|
|
|
|
Repeating the word proxy is not appropriate.
|
|
|
|
|
|
2026-06-02 09:03:12 +02:00
|
|
|
So the best way it to rename the `type` parameter to `_type`
|
2026-05-31 21:22:53 +02:00
|
|
|
|
|
|
|
|
Let's create a family named `manual` which obviously corresponds to the proxy's manual configuration choice.
|
|
|
|
|
|
|
|
|
|
.. extinclude:: https://forge.cloud.silique.fr/stove/rougail-tutorials/raw/tag/v1.1_210/foxyproxy/00-foxyproxy.yml
|
|
|
|
|
:language: yaml
|
|
|
|
|
:caption: The `proxies` family with `leadership` type and a variable with the name `type` in the :file:`foxyproxy/00-foxyproxy.yml` structure file
|
|
|
|
|
|
2026-06-02 09:03:12 +02:00
|
|
|
Technically it's possible to put `_` at the beginning of each parameter name, but it's still less readable.
|
2026-05-31 21:22:53 +02:00
|
|
|
|
|
|
|
|
.. keypoints:: Let's review the key points
|
|
|
|
|
|
|
|
|
|
**Keywords**
|
|
|
|
|
|
2026-06-02 09:03:12 +02:00
|
|
|
- parameters could start by "_" character or not
|
|
|
|
|
- do not add `_` in front of all parameters name
|