事前設定可能な機能

コンポーネントには、ページ作成者が使用する編集ダイアログのほかに、テンプレート作成者が事前設定を行うためのデザインダイアログも含めることができます。テンプレートエディターでは、「ポリシー」と呼ばれるこれらの事前設定をすべて設定できます。

コンポーネントをできるだけ再利用できるようにするには、事前設定用の意味のあるオプションを用意する必要があります。そうすれば、コンポーネントの機能の有効・無効を切り替えることで、様々なサイトの特定のニーズに対応することができます。

プロキシコンポーネントパターン

各コンテンツリソースには、そのリソースをレンダリングするためのコンポーネントを参照する sling:resourceType プロパティがあります。通常はこれらのプロパティが、複数のサイトで共有されるコンポーネントではなく、サイト固有のコンポーネントを指すように設定することをお勧めします。そうすれば、コンテンツの柔軟性が高まり、あるサイトでコンポーネントの動作を変更する必要が生じてもコンテンツのリファクタリングが不要になります。なぜなら、サイト固有のコンポーネント上でこのカスタマイズを実現でき、そのカスタマイズの影響は他のサイトには及ばないからです。

ただし、プロジェクト固有のコンポーネント間でコードが重複しないようにするには、sling:resourceSuperType プロパティを使用して各コンポーネントが共通の親コンポーネントを参照するようにしてください。ほとんど親コンポーネントを参照するだけの、これらプロジェクト固有のコンポーネントは、「プロキシコンポーネント」と呼ばれます。機能をすべて継承する場合はプロキシコンポーネントを完全に空にすることができます。また、プロキシコンポーネントでコンポーネントのいくつかの側面を再定義することもできます。

ヒント
プロキシコンポーネントの作成方法について詳しくは、コアコンポーネントの使用を参照してください。

コンポーネントのバージョン管理

コンポーネントは時間が経過しても完全に互換性を維持する必要がありますが、互換性を維持できない変更が必要になる場合もあります。これらの相反するニーズへの解決策の 1 つは、リソースタイプパスと実装の完全修飾 Java クラス名に数値を追加して、コンポーネントのバージョン管理を導入することです。このバージョン番号は、セマンティックバージョン管理のガイドラインで定義されたメジャーバージョンを表します。メジャーバージョンは、後方互換性を維持できない変更でのみインクリメントされます。

コンポーネントの以下の側面に対して互換性のない変更を行うと、新しいバージョンになります。

  • Sling モデル(セマンティックバージョン管理のガイドラインに準拠)
  • HTL スクリプトおよびテンプレート
  • HTML マークアップおよび CSS セレクター
  • JSON 表現
  • ダイアログ

詳しくは、GitHub の Versioning Policies ドキュメントを参照してください。

コンポーネントのバージョン管理では一種のコントラクトが作成されます。このコントラクトはリファクタリングが必要なタイミングを明確にし、アップグレードの際に重要な役割を果たします。アップグレード時のカスタマイズの互換性の節も参照してください。この節では、アップグレード時に様々な形式のカスタマイズでどういった考慮が必要になるかについて説明しています。

コンテンツ移行時に困難が生じないようにするには、コンテンツリソースからバージョン管理されたコンポーネントを直接参照しないことが重要です。経験則として、コンテンツの sling:resourceType にバージョン番号を含めないでください。そうしないと、コンポーネントのアップグレード時にコンテンツのリファクタリングも必要になります。これを回避する最善の方法は、前述のプロキシコンポーネントパターンに従うことです。