当サイトの記事投稿作業はここにあるとおり、独自のvscode拡張機能を作成して行なっています。ところがいつのまにか記事をアップ出来ない問題が発生していることに気づきました。
これは最近の話では無いのですが、以前トラブったことがあったので記事にしておこうと思います。
.NETでは、オプション引数とオーバーロードに違いがあるということを皆さんご存知でしょうか?
「ん?」という方もいれば、「そんなの常識だろう」と思う方もいるのではないかなと思います。
結論から言うと、「オプション引数が記述されたメソッドを含むアセンブリ」と「呼び出す側のアセンブリ」が別の場合は要注意です。
大先生がオプション引数・名前付き引数という記事で2009年に(名前付き引数といっしょに)まとめられていますので、deep diveしたい方はそちらを見ていただくとして、本記事では簡単にまとめます。
前回の記事、WPFでもValidationAttributeのメッセージリソースの既定値を設定したいの最後の方で「ReactivePropertyにも対応したい」ということでReactiveProperty用の拡張メソッドも作ってみました。
でも、ひとつひとつに設定するのも面倒ですよねぇ。
ということで、ReactiveProperty用にクラスライブラリプロジェクト(DataValidation.ReactiveProperty)を追加して、まとめて処理するヘルパメソッドを追加してみました。
ソースは前回のものをそのまま修正してGitHubのこちらに置いてあります。
2019/09/28
.NET Core 3.0でWPFしてみました。Nekoni.DataValidation
という記事で.NET Core 3.0のサンプルプロジェクトを追加しています。併せてご覧ください。
WPFにてViewModelやModelでデータ検証を行う際に System.ComponentModel.DataAnnotationsの検証属性を使用することが多いのではないかと思います。その場合、メッセージリソースと共に使用したいんじゃないかと思いますが、
/// <summary>
/// メールアドレス
/// </summary>
[Display(Name = "メールアドレス")]
[Required(ErrorMessageResourceType=typeof(ErrorMessage), ErrorMessageResourceName="Required")]
[EmailAddress(ErrorMessageResourceType=typeof(ErrorMessage), ErrorMessageResourceName="EmailAddress")]
public string MailAddress {
get => _MailAddress;
set
{
if (_MailAddress == value) return;
_MailAddress = value;
OnPropertyChanged();
}
}
private string _MailAddress;
のように、エラーメッセージリソースのTypeとリソースキーを指定することになります。
この記述、例えば必須チェックのメッセージなんて全て一緒になることがほとんどなのに、全ての項目にやたら長い属性指定を付けなければいけません。
ASP.NET MVCには DefaultModelBinder.ResourceClassKey
や、~AttributeAdapter
を使って既定のメッセージリソースを指定する方法があります。
今回は「WPFでもどうにかならないのか?」と思い1週間ほど格闘してみました。
場合によってはWPF以外でも使える...かもしれません。
格闘結果のソースはGitHubのこちらに置いてあります。
煮るなり焼くなりお好きにどうぞ。
part2の記事を書きました。
これに伴い、GitHubのソースも変更しています。
2019/09/28、さらにさらに、
.NET Core 3.0でWPFしてみました。Nekoni.DataValidation
という記事で.NET Core 3.0のサンプルプロジェクトを追加しています。併せてご覧ください。
本記事中のConfiguration
クラスは上記の記事中で、ValidationConfig
という名前に変更しています。
最新ソースと一緒に本記事を読まれている方は、適宜読み換えていただけると幸いです。