0

現在、すべてのステップ モデル クラスが基本の WizardStep クラスのサブクラスである、ウィザードのような機能をアプリ用に開発しています。今は 3 つしかありません (ただし、常に 12 未満になります)。

実際のウィザード NSView をバックエンドするための WizardControllerがあり、UI でこのポリモーフィックな WizardStep クラスを管理する方法の問題に直面しています。ステップのサブクラスごとに Cocoa バインディングを幅広く使用することに注意してください。

次の 3 つの解決策が思い浮かびました。

1) WizardStep のタイプごとに個別の NSViewを作成し、同数の NSObjectController を作成して、それらの間で特定のサブクラス プロパティをバインドします。ユーザーがステップに移動すると、NSObjectController のコンテンツが入力され、ウィザード ビューに (もちろんサブビューとして) ビューが表示されます。

2) WizardStep のタイプごとに個別の NSView を作成し、単一の NSObjectController を作成して、すべてのサブクラス プロパティをそれにバインドします (コントローラ コンテンツのタイプによっては、それらの一部が使用できなくなります)。ユーザーがステップに移動すると、NSObjectController のコンテンツが入力され、ウィザード ビューに (もちろんサブビューとして) ビューが表示されます。

3) WizardStep の各タイプごとにタブを持つ NSTabView を作成し、単一の NSObjectController を作成 (またはウィザードの ViewController を使用) し、すべてのサブクラス プロパティをそれにバインドします (解決策 2 のように、それらのいくつかは使用できなくなります)。ユーザーがステップに移動すると、NSObjectController のコンテンツを入力し、特定のステップ タイプに応じてタブ ビューの selectedIndex プロパティを設定します。

解決策 1) が最も正確で洗練されているように感じますが、やり過ぎになる可能性があるのではないかと思います(多くの NSObjectController、多くの NSView)。解決策 2) と 3) は、私にはばかげているように感じます (バインディングが利用できないため)。

進め方について何かアドバイスはありますか？

みんなありがとう、ピーター

4

1 に答える 1

1

これを行う方法は、現在のステップを示す 1 つのプロパティを使用して、ワークフローのすべてのステップに対して有効な (または少なくとも発生しない) 単一のモデル クラスを作成することです。次に、NSTabView をcurrentStepプロパティにバインドし、各タブの他のすべてのコントロールを表示するプロパティにバインドできます。ステップごとのモデル サブクラスのアプローチをあきらめるには道が遠すぎる場合でも、複数のステップを 1 つのオブジェクトに集約する別のモデル オブジェクトを作成できます。

このアプローチは、X モデル クラス、Y ビュー クラス、および Z NSObjectController サブクラスの代わりに、1 つのモデル クラスを使用することを意味します。FWIW、この状況で NSObjectController をサブクラス化する理由を想像するのに苦労しています。より広い意味では、NSView をサブクラス化する理由はたくさんありますが、この特定のシナリオで何が必要なのかは明確ではありません。

利用できないバインディングについては、時々利用できない可能性があるバインディングの「Raises For Not Apply Keys」のオプションをオフにすることができますが、そのオプションをオフにすると例外がスローされるため、例外スローにブレークポイントが必要な場合、これは苦痛になる可能性があります。例外がスローされるのを止めると、コントロールが例外を飲み込むだけになります。

于 2012-12-03T13:49:13.277 に答える