ウィジェット開発の一般的なガイドライン

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間:7分
  • カスタムウィジェットを開発するときは、最適なパフォーマンス、スケーラブルな開発、優れたユーザーエクスペリエンスのために、次の一般的なガイドラインを念頭に置いてください。

    エンドユーザーに例を示すデフォルトのステータスを作成します

    ウィジェットには、最初にページに追加されたときに定義されたインスタンスオプションがありません。この空ステータスのウィジェットは空白で表示され、混乱を招く可能性があります。ウィジェットに何らかの初期設定が必要な場合は、ウィジェットのデフォルトステータスが設定され、どの設定が必要かをアドミニストレーターに伝えることを確認します。

    ウィジェットはデモデータを使用して作成することもできます。デモデータは、次の目的でも使用できます。

    • ウィジェットの機能をユーザーに明確に示します。
    • ウィジェットエディターでウィジェットをプレビューするときにデータを提供する。(デモデータはデザイナーには表示されません)。

    詳細:「チュートリアル:カスタムウィジェットをビルドする」。

    可能な場合は、クローンを作成するのではなくウィジェットを埋め込む

    既存のウィジェットをカスタムウィジェットに埋め込むと、コードのクローン作成や複製を行うことなく、既存の機能を利用できます。埋め込みウィジェットにパラメーターを渡して、その動作を制御することもできます。

    詳細を見る: 既存のウィジェットの埋め込み

    パフォーマンスを向上させるために、大きなデータセットの使用は避けてください

    データのクエリ、ACL の評価、ビジネスルールの実行、およびデータ処理には時間がかかり、パフォーマンスが低下する可能性があります。ポータルユーザーが必要とするデータの量を判断し、スクリプトとクエリに適切な制限とフィルターを適用します。大量のデータや処理を必要とするウィジェットは、ポータル内の個別のページに分離します。大きなデータセットを使用する次のアイテムの実装は避けてください。

    • 大量のデータをロードするスクリプト化されたメニューアイテム。これにより、ポータル内のすべてのページのロードが遅くなる可能性があります。
    • 高解像度のメディアファイルや添付ファイル [sys_attachment] テーブルのフォントなどの大きなファイルや添付ファイル。
    • 自動リフレッシュウィジェット。ウィジェットのクライアントコントローラーが server.update()spUtil.update()server.refresh()、または spUtil.refresh() を呼び出すたびに、アプリケーションはウィジェットのサーバースクリプトを実行し、データオブジェクトをクライアントに送り返します。
    • フィルター処理されていないレコード監視。recordWatch() 関数は、テーブルまたはフィルターの更新を監視し、コールバック関数から値を返します。監視する特定のフィールドのフィルターを追加すると、ウィジェットがサーバーに対して行う呼び出しの数が削減されます。コールバック関数で更新があることをクライアントに通知するレコードプロデューサーに応答して、ウィジェットをリフレッシュするタイミングを指定することも、パフォーマンスを向上させることができます。
    • setLimit 関数なしで GlideRecord クエリを使用するサーバー側スクリプト。setLimit 関数を使用すると、返されるレコードの数を制限し、クエリーの応答時間を改善できます。柔軟性を高めるために、ハードコードされた値を割り当てるのではなく、この制限をインスタンスオプションに関連付けることができます ( 例:gr.setLimit(options.limit || 100))。
    複雑なウィジェットを埋め込むのではなくディレクティブを作成する

    埋め込みウィジェットがサーバーから呼び出されると、そのウィジェットに関連付けられているすべてのスクリプトが返されます。ウィジェットのサブセクションのみが必要な場合、ウィジェット全体を埋め込むと不要なオーバーヘッドが発生します。代わりに、ディレクティブを使用してウィジェット間で軽量コードを共有します。ディレクティブは、UI コンポーネントをビルドする場合などに役立ちます。サーバーサイドとクライアントサイドの機能を持つ複雑なコンポーネントは、ウィジェットとして残しておくことをお勧めします。埋め込みウィジェットの代わりにディレクティブを使用して、次の操作を行います。

    • スコープまたはカスタムスコープの動作を複数のウィジェットと共有します。
    • ウィジェットの再利用可能で軽量なサブセクションを共有します。
    • リストやアバターなどの一般的な UI 機能を共有します。
    • ウィジェットの動作を拡張します。

    詳細:「Angular プロバイダーでのコンポーネントの再利用」。

    サービスまたはファクトリを使用してデータを共有し、ステータスを保持する

    データサービスとファクトリは、サーバーを複数の呼び出しを必要とせずにウィジェット内のステータスを維持および保持するため、次のことが可能になります。

    • レコードまたはフィルターを変更するときにウィジェットの同期を維持します。
    • ウィジェット間でデータを共有します。
    • よりパフォーマンスの高いウィジェットを開発します。

    詳細:「Angular プロバイダーでのコンポーネントの再利用」。

    パブリッシュ/サブスクライブサービスによるイベントの処理

    DOM では $broadcast を使用しないでください。 $broadcast は、登録済みリスナーに通知するすべての子スコープにイベント名をディスパッチします。これは、 $rootScope グローバルオブジェクトの使用を必要とする負荷のかかる呼び出しになる可能性があります。

    代わりに、パブリッシュ/サブスクライブサービスを使用してイベントを処理します。パブリッシュ/サブスクライブサービスを使用する場合、コールバックハンドラーを介してウィジェット間に明確な関係が形成されます。このモデルでは、イベントのステータスをより適切に制御できます。

    REST 呼び出しまたは server.get を使用してサーバーからデータをフェッチする

    server.update() を呼び出すと、ウィジェット全体がサーバーから返されます。ウィジェットに異なるコードパスが含まれている場合、サーバーを更新するための複数の呼び出しがパフォーマンスに影響を与える可能性があります。原則として、サーバースクリプトを使用してウィジェットの初期状態を設定します。後続の更新には、インスタンスでスクリプトインクルードを呼び出すスクリプト化された REST API を使用します。このプラクティスでは、次のことを行います。

    • ビジネスロジックを UI 要素から分離します。
    • コードを一元化し、1 か所で変更できるようにします。
    server.get を使用して情報をサーバーに渡すこともできます。この関数を input.action とともに使用して、サーバースクリプトの特定の部分を実行します。
    ローカリゼーション、アクセシビリティ、UI を念頭に置いて開発する

    ユーザーに最高のエクスペリエンスを提供するには、次のガイドラインに従ってください。

    • モバイル環境におけるウィジェットの影響を考慮してください。たとえば、マウスオーバーや、モバイルデバイスに変換されないその他のイベントは使用しないでください。
    • SCSS 変数を使用してアイテムを再利用します。「SCSS 変数」を参照してください。
    • 色を使用する場合は変数名を使用します。
    • ローカリゼーション API で翻訳するために文字列を折り返します。「ウィジェットのインターナショナライズ」を参照してください。
    クライアントスクリプトから未使用の Angular プロバイダーを削除
    メンテナンスを容易にするために、クライアントスクリプト関数ステートメントに挿入された未使用の Angular プロバイダーを削除します。
    使用を避ける <script> tags in HTML templates
    での本番上の問題の可能性を減らすため サービスポータル、を使用したインラインテンプレートの使用は避けてください <script> tags in a widget's HTML template. Instead, create a related Angular ng-template record for the widget.