0

ユーザーが有効な値のリスト (コンボボックスなど) から InArgument / プロパティの値を指定できるようにする必要があります。有効な値のリストは、別の InArgument の値によって決定されます (その値は式によって設定されます)。

たとえば、設計時:

  • ユーザーがファイル パスをワークフロー変数 FilePath に入力する
  • DependedUpon InArgument が FilePath の値に設定されている
  • ファイルが照会され、有効な値のリストがユーザーに表示され、適切な値を選択できます (おそらくカスタム PropertyValueEditor を介して)。

これは可能ですか？

4

2 に答える 2

0

設計時または実行時のいつこれを検証しますか?

ユーザーは別の変数に依存する式を使用でき、設計時にそこから値を読み取ることができないため、設計時間は制限されます。ただし、式を見て、その方法で無効な組み合わせを推測することはできます。この場合、CacheMetadata 関数にコードを追加する必要があります。

実行時に実際の値を取得し、Execute 関数で検証できます。

于 2011-07-26T10:03:38.237 に答える
0

これが設計時に行われていることを考えると、アクティビティ自体ではなく、デザイナー内でこのすべてのロジックを提供することを強くお勧めします。

設計時のロジックをアクティビティに含めないでください。アクティビティは、どのデザイナーからも独立して実行できる必要があります。このように考えてみてください...

座って、アクティビティとそのデザイナーを使用してワークフローを設計します。完了したら、ワークフローを別の場所のサーバーにインストール/xcopyします。サーバーがアクティビティを実行する前にロードすると、設計ロジックが CacheMetadata で実行されるとどうなりますか? 設計時に実行されていないことを判断するヒューリスティックを使用してスキップされるか、そのファイルが見つからない場合にこのコードをスキップする追加のロジックを含めます。いずれにせよ、サーバーがこの設計時のコードを実行するのはなぜでしょうか? 答えは、それを実行すべきではないということです。そのコードは設計者のものです。

これが、フレームワークを見ると、アクティビティとそのデザイナーが異なるアセンブリに存在することがわかる理由です。コードも同じようにする必要があります。デザイン中心のコードは、アクティビティとは別のアセンブリで配信する必要があります。これにより、両方をデザイナーに配信し、アクティビティ アセンブリのみをアプリケーション サーバーに配信できます。

于 2011-07-26T12:50:52.227 に答える