タグ付けされた質問 「xaml」

だから、私は.Netで働いています。.Netでオープンソースプロジェクトを作成します。それに関する私の最大の問題の1つは、.Netではなく、その周辺のコミュニティとフレームワークに必要なことです。魔法のネーミングスキームと文字列は、すべてを行うための最良の方法として扱われているようです。大胆な発言ですが、見てください： ASP.Net MVC： Hello world route： routes.MapRoute( "Default", // Route name "{controller}/{action}/{id}", // URL with parameters new { controller = "Home", action = "Index", id = "" } // Parameter defaults ); これが意味することは、ASP.Net MVCが何らかの形でHomeControllerコードを検索するということです。どういうわけか、それの新しいインスタンスを作成してから、Index 明らかidに何らかのパラメーターで関数を呼び出します。そして、次のようなものがあります： RenderView("Categories", categories); ...or.. ViewData["Foobar"]="meh"; そして、XAMLにも同様のことがあります。DataContextオブジェクトとして扱われ、希望するタイプに解決されることを期待し、祈らなければなりません。DependencyPropertiesは、マジックストリングとマジックネーミング規則を使用する必要があります。そして、このようなもの： MyData myDataObject = new MyData(DateTime.Now); Binding myBinding = new Binding("MyDataProperty"); …

47 c#  .net  asp.net-mvc  static-typing  xaml 

Model View View-Modelは、イベント駆動型プログラミング、特にXAMLおよび.NET言語を使用する.NETプラットフォーム上のWindows Presentation Foundation（WPF）およびSilverlightをサポートするUI開発プラットフォームをターゲットとしてMicrosoftによって開発されました。それ以来、Angular、Knockout、ExtJSなどの多くのJavascriptフレームワークがこのパターンを採用しています。 ほとんどのソフトウェアパターンと同様に、MVVMには適切な用途と悪用があります。MVVMの使用はどのような条件下で適切ですか？いつお勧めしませんか？

47 wpf  mvvm  silverlight  angularjs  xaml 

多数の値の変換を必要とするビューを持つWPFアプリケーションに取り組んでいます。当初、私の哲学（XAML Disciplesに関するこの活発な議論に一部影響を受けました）は、ビューのデータ要件のサポートについて厳密にビューモデルを作成することでした。つまり、データを可視性、ブラシ、サイズなどに変換するために必要な値の変換は、値コンバーターと多値コンバーターで処理されます。概念的には、これは非常にエレガントに見えました。ビューモデルとビューの両方に明確な目的があり、うまく分離されます。「データ」と「外観」の間に明確な線が引かれます。 まあ、この戦略を「古い大学の試み」にした後、私はこの方法で開発を続けたいかどうか疑問に思っています。私は実際に、値コンバーターをダンプし、（ほとんど）すべての値変換の責任をビューモデルの手に直接置くことを強く考えています。 値コンバータを使用する現実は、明確に分離された懸念の見かけの価値まで測定しているようには見えません。値コンバーターの最大の問題は、使用するのが面倒なことです。新しいクラスを作成し、実装するIValueConverterかIMultiValueConverter、値をobject適切な型にキャストし、DependencyProperty.Unset（少なくとも多値コンバーターの場合）テストし、変換ロジックを記述し、コンバーターをリソースディクショナリに登録する必要があります [下記の更新を参照]、最後に、かなり冗長なXAMLを使用してコンバーターを接続します（バインディングとコンバーターの名前の両方にマジックストリングを使用する必要があります）[以下の更新を参照]）。特にVisual Studioのデザインモード/ Expression Blendでは、エラーメッセージはしばしば不可解であるため、デバッグプロセスもピクニックではありません。 これは、すべての価値変換を担当するビューモデルを作成するという代替策が改善であると言っているわけではありません。これは、草が反対側でより緑であるという問題である可能性が非常に高い。関心事のエレガントな分離を失うことに加えて、派生プロパティの束を記述し、RaisePropertyChanged(() => DerivedProperty)ベースプロパティを設定する際に慎重に呼び出す必要があります。これは、不快なメンテナンスの問題であることがわかります。 以下は、ビューモデルに変換ロジックを処理させ、値コンバーターを廃止することの長所と短所をまとめた最初のリストです。 長所： マルチコンバーターが排除されるため、総バインディング数が少なくなります 少ないマジックストリング（バインディングパス+コンバーターリソース名） 各コンバータを登録する必要はありません（さらにこのリストを維持します） 各コンバーターを作成する作業が少なくなります（インターフェイスの実装やキャストは不要） 変換に役立つ依存関係を簡単に挿入できます（例：カラーテーブル） XAMLマークアップは冗長ではなく、読みやすい コンバーターの再利用は引き続き可能です（ただし、ある程度の計画が必要です） DependencyProperty.Unsetに不可解な問題はありません（複数値コンバーターで気づいた問題） *取り消し線は、マークアップ拡張機能を使用すると消える利点を示しています（以下の更新を参照） 短所： ビューモデルとビューの間のより強い結合（たとえば、プロパティは可視性やブラシなどの概念を処理する必要があります） ビュー内のすべてのバインディングの直接マッピングを可能にする、より多くのプロパティ RaisePropertyChanged派生プロパティごとに呼び出す必要があります（以下の更新2を参照） 変換がUI要素のプロパティに基づいている場合、コンバーターに依存する必要があります おそらくおわかりのように、この問題については胸焼けがあります。私は、リファクタリングの道を進むのを非常にためらっていますが、値変換を使用するか、ビューモデルで多数の値変換プロパティを公開するかどうかにかかわらず、コーディングプロセスが同じように非効率的で退屈です。 賛否両論ありませんか？価値変換の両方の手段を試した人にとって、あなたにとってどちらがより効果的であると思いましたか？他の選択肢はありますか？（弟子たちは、タイプ記述子プロバイダーについて何かを言及しましたが、彼らが話していることを理解できませんでした。これについての洞察はありがたいです。） 更新 本日、「マークアップ拡張機能」と呼ばれるものを使用して、値コンバーターを登録する必要をなくすことができることを発見しました。実際、これらを登録する必要がなくなるだけでなく、を入力しConverter=たときにコンバーターを選択するためのインテリセンスが実際に提供されます。：ここでは私が始まった記事ですhttp://www.wpftutorial.net/ValueConverters.htmlが。 マークアップ拡張機能を使用する機能により、上記の長所と短所のリストと議論のバランスが多少変わります（取り消し線を参照）。 この啓示の結果として、私はハイブリッド私がコンバータを使用するシステムで実験てるBoolToVisibilityと私は呼んでMatchToVisibility、他のすべての変換のためのビューモデル。MatchToVisibilityは基本的に、バインドされた値（通常は列挙型）がXAMLで指定された1つ以上の値と一致するかどうかを確認できるコンバーターです。 例： Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue=Visible, IfFalse=Hidden, Value1=Finished, Value2=Canceled}}" 基本的にこれは、ステータスが終了またはキャンセルのいずれかであるかを確認します。そうである場合、可視性は「可視」に設定されます。それ以外の場合、「非表示」に設定されます。これは非常に一般的なシナリオであることが判明し、このコンバーターを使用すると、ビューモデルの約15個のプロパティ（および関連するRaisePropertyChangedステートメント）が節約されました。を入力するとConverter={vc:、「MatchToVisibility」がインテリセンスメニューに表示されることに注意してください。これにより、エラーの可能性が著しく減少し、値コンバーターの使用が面倒になりにくくなります（必要な値コンバーターの名前を覚えたり検索したりする必要がなくなります）。 興味があれば、以下のコードを貼り付けます。この実装の一つの重要な特徴は、MatchToVisibilityそれがバインドされた値であるかどうかをチェックしていることでenum、それがあれば、それはチェックを確認するためにValue1、Value2なども同じ型の列挙型です。これにより、列挙値のいずれかが誤って入力されているかどうかの設計時および実行時チェックが提供されます。これをコンパイル時のチェックに改善するには、代わりに以下を使用できます（手で入力したので、間違えた場合はご容赦ください）： Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue={x:Type {win:Visibility.Visible}}, IfFalse={x:Type {win:Visibility.Hidden}}, …

20 silverlight  wpf  mvvm  xaml 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 Metro AppsにXAML / C＃またはHTML5 / JavaScriptを使用することに大きな利点または欠点があるかどうかを疑問に思っていました。

19 c#  javascript  html5  xaml  metro 

XAMLは基本的にXMLのサブセットです。XMLに基づいたXAMLの主な利点の1つは、既存のツールで解析できることです。また、（構文的には重要ではない）属性値はテキスト形式のままであり、さらに解析する必要がありますが、かなりの程度まで可能です。 XML派生言語でGUIを記述するための2つの主要な代替手段があります。1つは、WinFormsが行ったことを実行し、それを実際のコードで記述することです。これには多くの問題がありますが、完全にアドバンテージがないわけではありません（このアプローチとXAMLを比較する質問）。他の主要な代替手段は、手元のタスクに合わせて特別に調整された完全に新しい構文を設計することです。これは、一般的にドメイン固有の言語として知られています。 それで、後知恵で、そして将来の世代への教訓として、XAMLをXMLに基づいたものにするのは良い考えでしたか、それともカスタム設計のドメイン固有言語としてより良いものでしたか？さらに優れたUIフレームワークを設計している場合、XMLまたはカスタムDSLを選択する必要がありますか？ それは現状維持、かなりのコミュニティに好かれ、特に1について積極的に考えるのは非常に簡単ですので、私はXMLの上に構築する理由の理由は、いくつかの例をあげるかもしれない間違いと見なされます。 XMLを基に言語を作成することには1つのことがあります：解析がはるかに簡単（コアパーサーが既に利用可能）であり、設計作業がはるかに少なくてすみます。 しかし、結果として生じる言語は、さまざまな点で不満になる可能性があります。かなり冗長です。何かのタイプを変更する場合は、終了タグで変更する必要があります。コメントに対するサポートは非​​常に貧弱です。属性をコメント化することはできません。XMLによる属性のコンテンツには制限があります。マークアップ拡張機能は、XML構文の「最上部」に構築する必要があり、XML構文に深く、うまく統合されていません。そして、私の個人的なお気に入りは、属性を介して何かを設定する場合、コンテンツプロパティとまったく同じものを設定する場合とはまったく異なる構文を使用することです。 また、誰もがXMLを知っているため、XAMLの学習はそれほど必要ではないと言われています。厳密に言えばこれは事実ですが、構文の学習は、新しいUIフレームワークの学習に費やす時間のほんの一部です。曲線を急にするのはフレームワークの概念です。その上、XMLベースの言語の特異性は、実際に「学習が必要」なバスケットに追加される可能性があります。 これらの不利な点は、解析の容易さによって重くされていますか？次のクールなフレームワークは伝統を続けるべきでしょうか、それとも既存のツールでは解析できず、誰もが構文を学ぶ必要のある素晴らしいDSLを設計するために時間を投資すべきでしょうか？ PS誰もがXAMLとWPFを混同しているわけではありませんが、一部は混同しています。XAMLはXMLのようなものです。WPFは、バインディング、テーマ設定、ハードウェアアクセラレーション、その他多くの優れた機能をサポートするフレームワークです。

16 language-design  xaml 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 まず、この質問はWPFとWinFormsに関するものではないことに注意してください。 マイクロソフトがXAMLを発明して、コンパイル可能なC＃コードを生成する「古い」アプローチを採用するようになった最高の利点は何ですか。 私の印象では、他の開発者は多くの欠点を見つけているようですが、Microsoftはそれを受け入れました。つまり、私には見られない利点があるということです。私が行方不明になっていることを説明してください。

8 language-design  xaml