[R] Intégration d'un fichier ini dans un tableau 2D

[lerin57]

Bonsoir à tous,

Avec l'aide de membres (experts) de ce forum, j'ai élaboré un programme qui me permet de générer des mails pré-formaté en vue d'escalades définie pour des groupes particuliers.

Le scripts est désormais au point, je pense d'ailleurs à fournir une version suffisamment dépouillé et explicite dans la rubrique des exemples, pour les intéressés.

Une autre idée m'est alors venue à l'esprit, à savoir concevoir un autre script qui me permettrait de générer un programme de mailing approprié pour chacun de nos clients.

Afin de simplifier au maximum sa création, et ajouter également un peu d'ergonomie, j'ai opté pour l'utilisation de fichiers *.ini

les variables principales dont je doit tenir compte son les suivantes :

1ere variable : référence du groupe (incréménté de 0 à n nombre de groupe - fait office de clé primaire pour les puristes)
2eme variable : identification du groupe d'escalade
3eme variable : association d'une ou plusieurs adresses mails à ce groupe
4eme variable : association d'un modele de mail à ce même groupe

Concrètement, voici un exemple de fichier *.ini (il faudra enregistrer le fichier sous le nom de data.ini

► Afficher le texte

Code : Tout sélectionner

[grp_names]
Grp1=lili
Grp2=lulu
Grp3=lala
Grp4=lolo

[Grp_mails]
Grp1=lili@test.com
Grp2=lulu@test.com
Grp3=lala@test.com
Grp4=lolo@test.com

[Grp_models]
Grp1=lili.html
Grp2=lulu.html
Grp3=lala.html
Grp4=lolo.html
 

Et voici un exemple d'interpretation :

► Afficher le texte

Code : Tout sélectionner

#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <GUIListBox.au3>
#include <WindowsConstants.au3>

$data = @WorkingDir & "\data.ini" ; creer le fichier et le placer à coté du script

$var01 = IniReadSection($data, "grp_names")

$var02 = IniReadSection($data, "Grp_mails")

$var03 = IniReadSection($data, "Grp_models")

local $i

#Region ###
$Form2 = GUICreate("selection", 335, 271, 382, 214)
GUISetFont(12, 400, 0, "MS Sans Serif")
GUISetBkColor(0xA6CAF0)
$listes_groups = GUICtrlCreateList("", 16, 16, 300, 166)
$mail = GUICtrlCreateInput("", 16, 192, 300, 28)
$model = GUICtrlCreateInput("", 16, 232, 300, 28)
GUISetState(@SW_SHOW)
#EndRegion ###

For $i = 1 to $var01[0][0]
    GUICtrlSetData($listes_groups, $var01[$i][1])
Next


While 1
    $nMsg = GUIGetMsg()
    Select
        Case $nMsg = $GUI_EVENT_CLOSE
            Exit
        Case $nMsg = $listes_groups
            _result()
    EndSelect
WEnd

Func _result()

For $i = 1 to $var01[0][0]
    If GUICtrlRead($listes_groups) = $var01[$i][1] Then
        GUICtrlSetData($mail, $var02[$i][1])
        GUICtrlSetData($model, $var03[$i][1])
    EndIf
Next

EndFunc

Jusqu'ici le code fonctionne, mais voila la problématique, le nombre de groupe d'escalade peut varier.

Je souhaiterait réunir les valeur dans un tableau 2D de 4 colonnes :
[référence_groupe, nom_du_groupe, Mails, modele_de_mail]

j'ai a peu prêt compris le principe de construction d'un tableau, mais ici, je ne sais pas comment le "générer".

Les fonctions liées aux Array sont nombreuses, et je m'y perd.

Je souhaiterais en fait créer la condition suivante :

si je choisi, dans sa colonne correspondante, le nom d'un groupe, je veut pouvoir, au sein d'un résultat, l'associer à son adresse mail, ainsi qu'à un modèle correspondant.

J'espère avoir été suffisament clair dans mes explications.

Si quelqu'un à une piste, je l'en remercie par avance

[jchd]

Je ne sais pas si tu n'as pas plus intérêt à envisager un stockage SQLite à la place de fichiers .ini, qu'il est très (trop) facile d'esquinter involontairement en ne respectant pas les règles d'emploi que tu te fixes (4 clés dans 4 sections).

A défaut, je verrais plutôt les 4 clés d'un groupe dans une section et le nom/référence du groupe en nom de section. IniReadSectionNames pour charger la liste des groupes et IniReadSection pour charger les 4 clés d'un groupe. Par contre, rien ne contraint à la cohérence dans un fichier .ini.

Ceci dit, je ne vois plus trop d'intrêt à des fichiers .ini pour ce type de choses, étant donné la souplesse et la facilité de mise en oeuvre d'une base SQLite pour du stockage applicatif. Ca se gère en quelques lignes de code, c'est d'une robustesse à l'épreuve des missiles (comparativement à d'autres solutions), c'est d'une puissance de recherche et de contrôle bien supérieure aux solutions "ad hoc" et une base SQLite se gère par programme, par ligne de commande, par script, par navigateur, etc. Seul hic, éventuel, la présence requise d'une version pas trop ancienne de sqlite.dll (qu'on trouve en N exemplaires sur tout système Windows ayant quelques programmes standard installés).

[lerin57]

Bonjour, jchd

Je te remercie pour ce retour.

J'ai déja pensé à ton idée d'utiliser chaque clé dans une section, mais cela risque effectivement de toucher à la cohérence , d'autant plus que je suis susceptible d'utiliser des groupes généraux, avec des sous groupes répondant aux criteres de ces 4 variables.

Je vais penser à ton idée de sqlite, le probleme, c'est un langage que je ne maitrise pas, mais pas du tout.

Sans vouloir passer pour un boulet, j'aimerais savoir si l'idée du tableau reste envisageable.

je reste bien entendu ouvert à toute les suggestion.

[jchd]

Tu peux certainement t'en tirer aver un tableau, mais ton application risque peut-être de se compliquer avec une introduction de sous-groupes et éventuellement des critères supplémentaires qui s'affirmeront ultérieurement comme nécessaires.

C'est un peu pour cette raison que je reste sceptique sur le seul format .ini, qui risque de ne pas pouvoir se plier à tes besoins futurs. Et il me semble anormal de devoir modeler des fonctionnalités sur les possibilités de l'organisation au niveau fichier(s). J'étais un peu comme toi il n'y a pas si longtemps, n'ayant jamais eu l'occasion de plonger sérieusement les mains dans les bases de données. L'activité dont je m'occupe m'y a contraint et je dois dire que j'ai trouvé (surtout avec l'incroyable souplesse de SQLite) de quoi réviser à 180° certaines idées reçues. Une fois qu'on y a gouté, on peut difficilement s'en passer et on oublie bien des listes chaînées, des tableaux dans tous les sens, des recherches pénibles et des formats de fichier fragiles. Sincèrement, je me vois mal me passer des caractéristiques "ACID", quelque soit le volume considéré.

Tu trouveras de l'aide si tu le souhaites sur ce forum --je vois qu'il y a des SQLiters chevronnés ici-- et des tutoriaux en grand nombre un peu partout. Autre bonne raison : c'est un gros plus professionnel de ne pas être comme un phoque dès que l'acronyme DB pointe son nez...

[lerin57]

Bonsoir,

Je ne saisi pas trop l'allusion au "phoque", ?

Mais je vais laisser cela de coté.

Je vais rester pour le moment sur mon idée de tableaux, avec ou sans fichier *.ini, c'est un domaine que je tient à approfondir.

Pour les bases de donnés, il me faudra plus de temps car mon métier ne me permet pas de travailler directement dans le vif du sujet.

je laisse le sujet en suspend pour quelques jour, le temps de trouver une autre approche.

Je reste bien entendu ouvert à toute suggestion.

[jchd]

bah, comme un phoque ≈ comme un couillon

IniReadSectionNames et IniReadSection t'aideront, sans aucun doute.

Bonne réflexion en tous cas.

[mimione]

Bonjour
Suggestion:
1/ Tenir "l'annuaire" à jour avec un tableur (c'est plus clair)
2/ Enregistrer une copie au format "texte" avec séparateur
3/ Lire ce fichier texte dans votre programme avec "_FileReadToArray"
et.. hop !
Bonne journée.

[lerin57]

Bonjour, à tous

Je vais finalement me passer de l'idée du fichier *.ini, et utiliser plutôt un fichier proche du csv.

Effectivement, L'emploie de la fonction _filereadtoarray me mene vers une piste.

je vous remercie pour votre aide.

[lerin57]

Bonjour,

Bon , j'ai trouvé une autre approche, mais il y a quelque chose que je n'arrive pas à comprendre au niveau des tableaux.

Je cloture ce sujet et je vais poser ma question sous une autre forme.