Question Calendrier

bilbao écrit:

Je te conseil tout de même de suivre la solution de Laurent car elle permet d'en apprendre plus sur Powershell

C'était effectivement l'objectif de mon dernier post, éclairer d'autres aspects sur la gestion des dates sous dotnet/PS.
bilbao écrit:

mais la plus \"sale\" est de passer par une variable [string]

Tant que l'approche ne génère pas d'effets de bords cela ne pose pas de pb, le principal est que l'approche choisie réponde au besoin

Le fait de creuser des sujets qui peuvent paraître futile pour du scripting, permet de ne pas recoder ce qui existe déjà.
Un des avantages d'utiliser le formatage présenté précédement est de donner une cohérence pour tous vos scripts, un autre est que lors de la relecture du code, pour ceci :
$date.ToLongDateString()
on se concentre, avec un peu de pratique, sur le nom de la méthode
ToLongDateString
puisque le préfix est le plus souvent un nom de variable.

Là ou la solution la plus simple, demande de relire tout la phrase pour connaître le résultat:
\"$($date.day)/$($date.Month)/$($date.Year)\"

Bruce Payette parle dans son dernier ouvrage à paraître de pattern de commande, des suites de commandes récurrentes dont seul le paramètrage change, ici il s'agit plutôt de méthodes de classes dotnet qui prennent en charge des traitements récurrents.

Lorsque je dis qu'il vaut mieux enrichir l'objet existant, je pensais au cmdlet Add-Member qui permet d'ajouter dynamiquement une propriété à un objet (et seulement celui-là).
[code:1]
$Date=Get-Date
#force l'adaption de l'objet dotnet en objet PowerShell
$Date.Hour>$null
#On échappe le caractère de formatage h avec \
$Date|Add-member noteproperty MonFormat \"le yyyy-MM à HH \heure\"
\"{0:$($date.MonFormat)}\" -f $date
#le 2010-05 à 19 heure
[/code:1]
On peut aussi généraliser l'approche en utilisant un fichier de formatage de type (.ps1xml), qui permet en quelque sorte d'automatiser l'ajout de ce type de membre pour chaque instance du type.

Puisque PowerShell est un langage dynamique, le code peut se modifier lui même pendant l'exécution, on peut faire en sorte qu'il s'automatise lui-même...
Bon, je m'arrête là

Concernant ceci :
Laurent Dardenne écrit:

Puisque PowerShell est un langage dynamique, le code peut se modifier lui même pendant l'exécution, on peut faire en sorte qu'il s'automatise lui-même...

Une petite démo en V2 avec un module à télécharger.
On construit dynamiquement un fichier de configuration de type, puis on le charge :
[code:1]
#http://huddledmasses.org/a-dsl-for-xml-in-powershell-new-xdocument/
import-Module xml_module

#Génére le fichier ps1xml
$filename=\"$env:Temp\test.ps1xml\"
Function New-TypeData($Type,$name,$code,$filename){
# Le code de la fonction New-XDocument ne semble gérer que des variables globales
# on doit donc construire l'appel avec les variables locales
invoke-expression @\"
New-XDocument Types -Encoding \"UTF-16\" {
Type {
Name {\"$Type\"}
Members {
ScriptProperty {
Name {\"$Name\"}
GetScriptBlock { \"$code\"
}#GetscriptBlock
}
}
}
} | % { `$_.Declaration.ToString(); `$_.ToString() } | out-file \"$filename\" -encoding \"UTF8\"
\"@

}
New-TypeData \"System.DateTime\" \"MonFormat\" \"[string] 'le yyyy-MM à HH \heure'\" $filename
#signe $filename
Update-TypeData $filename

$Date=Get-Date
\"{0:$($date.MonFormat)}\" -f $date
#le 2010-06 à 19 heure
[/code:1]
Je reconnais que ceci est assez éloigné du post d'origine, c'est juste pour infos <br><br>Message édité par: Laurent Dardenne, à: 3/06/10 15:34