バック/フォワード プロジェクト機能に関して優れた設計と見なされるもの。つまり、ユーザーはブラウザの戻る/進むボタンを介してのみアプリケーションをナビゲートできます。または、アプリケーションに戻るボタンも含めることができます。それを混在させることをお勧めします(ブラウザの戻るボタンとアプリケーションの戻るボタン)? それとも、GWT History はアプリケーション内の唯一のナビゲーターとして十分でしょうか?
さまざまな意見やアプローチを聞くことができてうれしいです。
ありがとう
バック/フォワード プロジェクト機能に関して優れた設計と見なされるもの。つまり、ユーザーはブラウザの戻る/進むボタンを介してのみアプリケーションをナビゲートできます。または、アプリケーションに戻るボタンも含めることができます。それを混在させることをお勧めします(ブラウザの戻るボタンとアプリケーションの戻るボタン)? それとも、GWT History はアプリケーション内の唯一のナビゲーターとして十分でしょうか?
さまざまな意見やアプローチを聞くことができてうれしいです。
ありがとう
Webアプリケーションのsecenerioによると、ブラウザの戻るボタンと進むボタンをナビゲートする方が望ましいです。なぜ車輪の再発明を行うのですか?
この機能でサポートされているすべてのブラウザとして。また、gwtでサポートされている大規模なアプリケーションにも取り組んでいます。システムのHistoryは、Historyトークンによって管理されています。ここから確認できます。
私は過去2年間、gwtの履歴管理に取り組んでおり、正常に機能しています。内側のパネルのナビゲーション要件に合わせてナビゲーションシステムを使用できますが、ブラウザの場合は、独自の機能を使用することをお勧めします。
人々はブラウザーの戻る/進むボタンを使用することに慣れているため、アプリに個別の戻る/進む機能はありません。これは機能を追加するものではなく、人々を混乱させるだけです。
GWT History はブラウザーの履歴機能をラップするため、ブラウザーのネイティブの履歴機能とまったく同じように動作します。
私の見解では、GWT History はアプリケーションの既存の機能を模倣するために使用されます。したがって、アクションを実行すると、ユーザーが追跡できる痕跡が残ります。
ずっとブラウザベースの歴史。
Web アプリケーションが内部およびブラウザーベースの履歴ナビゲーションをサポートするインスタンスは考えられません。
私が考えることができる最も近いのは、ブレッドクラムが提供される場合ですが、これらはほんの数種類のアプリケーションにのみ関連しています。
GWT 履歴管理は、アプリケーションのさまざまな状態をアドレス URL と一致させ、リスナーを使用して URL の変更を通知する方法です。
これは、標準の戻る/進むが意味のある方法で機能することを可能にする技術的なものです。
ここでデザインについて話しますが、「戻る」/「進む」ボタンはアプリケーション内で本当に便利ですか?
これは、アプリケーションが何をするかによって異なります。それが一連のステップを備えたある種のウィザードである場合、はい、アプリケーションに戻る/進むボタンがあります。
これが従来の UI である場合は、前に進む必要はありません。ユーザーを新しいビューに送るリンク/ボタンと、ユーザーが望む任意のビュー/画面に移動できる何らかのメインナビゲーションがあります。戻る/進むのサポートのみがブラウザーのみを使用します。