私は、より大きなブラウザベースのアプリケーションの一部として設計しているシステム構成/設定「アプリ」を持っています。私たちの全体的なアプリケーションには、これが1つの「アプリ」(開発アプリ、ユーザー管理アプリ、カタログアプリなど)があります。
このシステム構成アプリは(舞台裏)1つの巨大な構成オブジェクトがいくつかの論理的な子に分割され、それぞれが左側のメニュー(例:「一般的な構成」、「データベースの構成」など)。基本的に、各サイドメニューには合理的に複雑なフォーム(グリッド、タブなど)が含まれています。
これらの構成はいくつかあり、ユーザーはページの上部にあるドロップダウン(「構成」という名前)を使用して、編集するものを選択できます。
私の質問は、このアプリの保存と検証を処理するための最も論理的/合理的/期待される方法は何ですか?「保存」APIが(背後にある)シーン)アプリのコンテンツ全体に共通?
私が検討したオプション:
(1)オブジェクト全体を保存します。ユーザーがサイドメニューをナビゲートした場合、ユーザーが離れたときに変更が保存されます。変更が無効な場合、ユーザーは警告を介して通知されます。ユーザーが保存を押すと、現在開いていないタブに検証エラーがあることが通知されます。
(2)各サイドメニューの「サブオブジェクト」を保存します。ユーザーがサイドメニューをナビゲートすると、変更が消去されることが通知されます(変更を行った場合)。
ユーザーがフィールドからぼやけたときに通常フィールドを検証しますが、より複雑なサーバー側の検証も発生する可能性があります。
*注:これらのサイドメニューは、アプリケーションの他のアプリで使用され、「アクション」バー(保存が配置されている場所にあり、青色でマークされています) )。一部のアプリでは、サブメニューを終了する前に保存する必要があることは明らかです。
これがアプリです:
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
このような複雑なシナリオでユーザーを支援する保存と検証に関連するいくつかの推奨事項を次に示します。
上記のことを行うには、不完全な/正しくない構成オブジェクトの状態を保存するのメカニズムが必要になります。 (これは、ステートレスなWebブラウザーのパラダイムに多少反します。)