LxLeChat
Subgraphs & stuffs
J'ai repenser aux histoires de scripblock dans des variables et les definitions de fonctions. On pourrait éventuellement essayer de les découvrire je pense notamment à toute les commandes de types "Invoke"...
$varx = {somecode}
$varx = if (something) {}
invoke-expression/command ...
on pourrait les détecter je pense ... ...il faudrait implémenter la détection de variables et voir ce qu il y a derriere ... ça demande l invetigation (tout du moins de mon côté :p )
en tout cas, ca nécessiterait la création d une nouvelle classe d objet, une ou plusieurs ? sous forme de subgraph ?? pas forcément ...
pareil pour les definitions de fonctions ... mais je crois que j avais déjà tester cela et j avais du mal à connecter les subgraphs ... ou alors le rendu n'était pas fou ...
ce que j'avais essayé aussi c'était pour les foreach-object .. mais le pb c'est que si on en a qui s'enchaine ... aie .. !
tet avoir une cmdlet qui ira chercher les definitions de fonctions dans un script, pour en faire des graphs dédié à part ?? hummm ! je crois bien que le rendu n'était vraiment pas ouf ... surtout quand t as une fonction avancé avec du begin,process,end ...
J'ai repenser aux histoires de scripblock dans des variables et les definitions de fonctions. On pourrait éventuellement essayer de les découvrire je pense notamment à toute les commandes de types "Invoke"...
Cela dépend de l'objectif et du niveau de détail. Selon moi, les appels à Invoke permettent de retrouver un type de dépendance (Winrm) comme les job mais ici c'est un autre type d'information. De tout placer dans le graphe n'est pas la voie à suivre je pense. Il y a au moins deux usages de ce type de graphe, la documentation et la découverte d'une solution.
ça demande de l'investigation (tout du moins de mon côté :p )
Le code de PSscriptAnalyzer contient de nombreuses informations sur ce type de recherche.
sous forme de subgraph ?? pas forcément ...
Le sous graphe permet de zoomer/filtrer (profondeur), mais comme tu couples le résultat à un format on ne peut visualiser le résultat/usage, de plus cela nécessite Visual Studio Pro je crois , donc un 'truc de riche' ;- )
pareil pour les definitions de fonctions ... mais je crois que j avais déjà tester cela et j avais du mal à connecter les subgraphs ... ou alors le rendu n'était pas fou ...
De mon côté j'avais rencontré un pb de nommage des noeuds dans un graphe.
J'avais ceci en rendu (msagl) :
Le lien permet de porter l'information qui appel qui et qui déclare quoi. De plus l'outil permet de réorganiser le graphe, c'est un peu buggé mais reste utilisable et utile.
ce que j'avais essayé aussi c'était pour les
foreach-object.. mais le pb c'est que si on en a qui s'enchaine ... aie .. !
Le pipeline c'est du code compressé, ici le mieux est de le laisser de côté.
Un exemple dgml ( avec un sous graphe 'fermé'):
'ouvert' :
Une définition :
<?xml version='1.0' encoding='utf-8'?>
<DirectedGraph xmlns="http://schemas.microsoft.com/vs/2009/dgml">
<Nodes>
<Node Id="a" Label="a" Background="Blue"/>
<Node Id="b" Label="b" NodeRadius="16"/>
<Node Id="c" Label="c" NodeRadius="0"/>
<Node Id="d" Label="d" NodeRadius="4"/>
<Node Id="c1" Label="c" NodeRadius="8"/>
<Node Id="d1" Label="d" NodeRadius="24"/>
<Node Id="e" Label="e" NodeRadius="32"/>
<Node Id="f" Label="f" NodeRadius="12"/>
<Node Id="GroupA" Group="Expanded" />
<Node Id="GroupB" Group="Expanded" />
<Node Id="GroupC" Group="Expanded" />
</Nodes>
<Links>
<Link Source="a" Target="b" />
<Link Source="a" Target="c" />
<Link Source="a" Target="d" />
<Link Source="c" Target="d" />
<Link Source="c1" Target="d1" />
<Link Category="Contains" Source="GroupA" Target="c" />
<Link Category="Contains" Source="GroupA" Target="d" />
<Link Category="Contains" Source="GroupB" Target="c1" />
<Link Category="Contains" Source="GroupB" Target="d1" />
<Link Category="Contains" Source="GroupC" Target="e" />
<Link Category="Contains" Source="GroupC" Target="f" />
<Link Category="Contains" Source="GroupA" Target="GroupC" />
</Links>
</DirectedGraph>
et son rendu :
Salut, je me suis souvenu de cette remarque concernant ce projet :
Il y a au moins deux usages de ce type de graphe, la documentation et la découverte d'une solution.
J'ai eu besoin de visualiser les dépendances de modules de test pour un projet, le script joint construit ceci :
le script : Show-ModuleDependencies.zip
Les données du graph au format msagl : Dependencies-magl.zip
On a rarement ce type de graphe de dépendances, mais au cas où ce script pourra t'être utile.