Project

General

Profile

Demande #4840

Revoir la redéfinition des contraintes

Added by Daniel Dehennin over 7 years ago. Updated almost 5 years ago.

Status:
Fermé
Priority:
Normal
Assigned To:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

40%

Spent time:

Description

Suite à la correction des fill et auto (#4774) il est nécessaire de revoir comment est gérée la redéfinition des autres contraintes.

patch.diff View (876 Bytes) Emmanuel GARETTE, 05/29/2013 10:32 AM


Related issues

Related to creole - Anomalie #4774: Impossible d'écraser un <fill> sur une variable 2.4 Fermé 01/28/2013 02/08/2013
Related to Documentations - Evolution #4835: Changement de comportement sur lors de la redéfinition d’une variable Fermé 10/07/2013 10/11/2013
Related to eole-common - Anomalie #5441: Problème sur le "fill" de "ssl_country_name" [2.4] Fermé 05/27/2013 05/31/2013
Related to creole - Anomalie #6016: Impossible de transformer une variable avec valeur par défaut en "auto" Fermé 09/16/2013
Related to creole - Anomalie #5848: Problème lié à la redéfinition de "nombre_interfaces" sur Amon Classée sans suite

Associated revisions

Revision c2683bcd (diff)
Added by Daniel Dehennin over 7 years ago

Impossible de faire un « hidden_if_in » avec un paramètre hors d’un « valid_enum »

  • creole/var_loader.py (CreoleVarLoader.update_requires): Ne forcer la
    propriété qu’en fonction du paramètre « True/False ».

Ref: #4840 @2m

History

#1 Updated by Daniel Dehennin over 7 years ago

  • Target version set to Eole 2.4-dev-2

À inclure dans un sprint.

#2 Updated by Joël Cuissinat over 7 years ago

  • Target version changed from Eole 2.4-dev-2 to Eole 2.4-dev-3

#3 Updated by Daniel Dehennin over 7 years ago

  • Status changed from Nouveau to En attente d'informations
  • Assigned To set to Emmanuel GARETTE

Je ne suis pas sûr que les hidden_if_in fonctionne correctement avec le code actuel.

Par exemple pour la famille interface_1 (eole-common:source:dicos/01_network.xml#L571?rev=8dfa70b3):

  • On définie que la famille doit être désactivée si la variable nombre_interfaces est égale à 1:
            <condition name='hidden_if_in' source='nombre_interfaces'>
                <param>1</param>
                <target type='family'>Interface-1</target>
            </condition>
    
  • La fonction CreoleConstraint.populate_condition() définie une liste contenant un tuple ('disabled', False) (source:creole/var_loader.py#L227?rev=ced77677)
  • La fonction CreoleVarLoader.update_requires() (source:creole/var_loader.py#L440?rev=ced77677):
    • reçoit [('nombre_interfaces', '1', 'disabled', False)] en paramètre
    • renvoie les valeurs (source:creole/var_loader.py#L673?rev=ced77677) :
      • props = ['disabled']
      • req = [(<tiramisu.option.ChoiceOption object at 0x1a6fec0>, '1', 'disabled', False)]

Je pense que le test source:creole/var_loader.py#L453?rev=ced77677 devrait prendre en compte la valeur actuelle de l’option opt, car opt.impl_get_values() renvoie la liste des valeurs autorisées par le valid_enum :

(u'2', u'3', u'4', u'5')

La valeur de nombre_interfaces est 2:

(Pdb) pp self.families['general']['vars']['nombre_interfaces']['value']
'2'

Mais le code (source:creole/var_loader.py#L453?rev=ced77677) :

            if isinstance(opt, ChoiceOption) and \
                    val not in opt.impl_get_values() and \
                    not opt.impl_is_openvalues():
                force_properties.append(value[2])

semble forcer la propriété disabled alors qu’il ne devrait pas.

Il est tout à fait possible aussi que je n’ai rien compris, ne sachant pas vraiment à quoi correspond le tuple ('disabled', False) ni ce qu’est sensé faire le code de CreoleVarLoader.update_requires().

#4 Updated by Emmanuel GARETTE over 7 years ago

Le diagnostique est bon. En fait, il n'est pas possible de faire un requirement sur un ChoiceOption avec une valeur non présente dans les values du ChoiceOption (sauf si open_values est à True).

Donc je pars du principe que si le test est fait sur valeur non existante, on "disabled" et on ne fait pas de requirements.

('disabled', False) correspond à hidden_if_in (voir ligne 228 du fichier), ('disabled', True) correspond à hidden_if_not_in (voir 2 lignes en dessous).

J'ai bien l'impression qu'il manque un test ligne 453. Il ne faudrait cacher que si la valeur n'existe pas dans le ChoiceOption et que le calcul est de type hidden_if_not_in (donc qu'il y ait True en 2eme valeur du tuple).

J'espère que ce commentaire permettra de résoudre le problème.

#5 Updated by Daniel Dehennin over 7 years ago

Emmanuel GARETTE a écrit :

Le diagnostique est bon. En fait, il n'est pas possible de faire un requirement sur un ChoiceOption avec une valeur non présente dans les values du ChoiceOption (sauf si open_values est à True).

Donc je pars du principe que si le test est fait sur valeur non existante, on "disabled" et on ne fait pas de requirements.

('disabled', False) correspond à hidden_if_in (voir ligne 228 du fichier), ('disabled', True) correspond à hidden_if_not_in (voir 2 lignes en dessous).

J'ai bien l'impression qu'il manque un test ligne 453. Il ne faudrait cacher que si la valeur n'existe pas dans le ChoiceOption et que le calcul est de type hidden_if_not_in (donc qu'il y ait True en 2eme valeur du tuple).

Ça me parait assez étrange comme test, peut-être contre intuitif.

Cache la famille Interface_1 si nombre_interfaces est égal à 1.

Peut-importe les valeurs possible de nombre_interfaces, seul la valeur courant est déterminante, et cette valeur courant est vérifié par le valid_enum.

Le soucis de l’approche actuelle, c’est que dès que l’on redéfinie les valeurs possible de nombre_interfaces, il faut refaire tous les hidden_if_in :

  1. 00_common : nombre_interfaces in ['1','2','3','4','5'], valeur par défaut 1
  2. 01_network : définition de tous les hidden_if_in pour les familles d’interfaces
  3. 30_amon : redéfinie nombre_interfaces in ['2','3','4','5'], valeur par défaut 2

Du coup, la famille Inteface_1 est disabled car son hidden_if_in avec le <param>1</param> est fait sur le range ['2','3','4','5'], alors qu’en fait la famille devrait être enabled.

Merci.

#6 Updated by Daniel Dehennin over 7 years ago

Emmanuel GARETTE a écrit :

Le diagnostique est bon. En fait, il n'est pas possible de faire un requirement sur un ChoiceOption avec une valeur non présente dans les values du ChoiceOption (sauf si open_values est à True).

Je pense en fait que l’histoire de la liste des valeurs et du open_values n’ont de sens que pour la saisie des valeurs de nombre_interfaces.

Merci.

#7 Updated by Daniel Dehennin over 7 years ago

Cela risque d’être un peu plus compliqué que prévu :

(Pdb) import tiramisu
(Pdb) b tiramisu.option.validate_requires_arg, name == 'interface_1'
Breakpoint 6 at /usr/lib/python2.7/dist-packages/tiramisu/option.py:797
(Pdb) c
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(799)validate_requires_arg()
(Pdb) p name
'interface_1'
(Pdb) p requires
[(<tiramisu.option.ChoiceOption object at 0x34f8890>, '1', 'disabled', False)]
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(811)validate_requires_arg()
-> if not req[0]._validate(req[1]):
(Pdb) 
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(812)validate_requires_arg()
-> raise ValueError(_('malformed requirements second argument '
(Pdb) 
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(813)validate_requires_arg()
-> 'must be valid for option {0}').format(name))
(Pdb) 
ValueError: ValueErr...face_1',)
> /usr/lib/python2.7/dist-packages/tiramisu/option.py(813)validate_requires_arg()
-> 'must be valid for option {0}').format(name))
(Pdb) l
808                 if req[0].impl_is_multi():
809                     raise ValueError(_('malformed requirements option {0} '
810                                        'should not be a multi').format(name))
811                 if not req[0]._validate(req[1]):
812                     raise ValueError(_('malformed requirements second argument '
813  ->                                    'must be valid for option {0}').format(name))
814                 if len(req) == 3:
815                     action = req[2]
816                     inverse = False
817                 elif len(req) == 4:
818                     action = req[2]

#8 Updated by Emmanuel GARETTE over 7 years ago

Voici un patch pour résoudre ce bug.

#9 Updated by Joël Cuissinat about 7 years ago

  • Assigned To changed from Emmanuel GARETTE to Daniel Dehennin
  • Target version changed from Eole 2.4-dev-3 to Eole 2.4-alpha
  • % Done changed from 0 to 40

#10 Updated by Joël Cuissinat about 7 years ago

  • Target version deleted (Eole 2.4-alpha)

#11 Updated by Joël Cuissinat almost 5 years ago

  • Tracker changed from Evolution to Demande
  • Status changed from En attente d'informations to Nouveau
  • Assigned To deleted (Daniel Dehennin)

Visiblement le patch a été appliqué depuis un bout de temps : creole:c2683bcd (>= EOLE 2.4.0)

Voir si une vérification supplémentaire et/ou l'ajout d'un test s'imposent avant fermeture définitive !

#12 Updated by Scrum Master almost 5 years ago

  • Assigned To set to Daniel Dehennin

#13 Updated by Daniel Dehennin almost 5 years ago

  • Status changed from Nouveau to Fermé

Cela fonctionne sur la version 2.5.1.

En ajoutant le dictionnaire suivant /usr/share/eole/creole/dicos/local/99_test.xml :

<?xml version="1.0" encoding="utf-8"?>
<creole>
    <files>
    </files>
    <variables>
        <family name='general'>
            <variable name='nombre_interfaces' redefine='True' mode='basic'>
                <value>2</value>
            </variable>
        </family>
    </variables>
    <constraints>
        <check name="valid_enum" target="nombre_interfaces">
            <param>['2','3','4','5']</param>
        </check>
    </constraints>
</creole>

Also available in: Atom PDF