サイトコアのヘッズアップフロントエンド開発者

Sitecoreサイトでは、フロントエンドチームがHTMLを作成する際に考慮しなければならないことがあります。

サイトコアはHTMLに何の制限も課していませんが、バックエンドコンポーネントとHTMLの統合をスムーズにし、バックエンドのSitecore開発者がベストスタンダードにシームレスに従えるようにするための、ある種のベストプラクティスがあります。

フロントエンドチームは、Webサイトの開発に必要なHTMLとフロントエンドのアセットを提供し、このガイドラインに従うだけです。サイトコアを使ったサイト開発の経験がないフロントエンドチームでも、これらのガイドラインに従うことで、シームレスな開発が可能になります。

1.HTMLページのレイアウト

サイトコアのページは、コンポーネントベースのアーキテクチャを採用しています。

ページのデザインができたら、ページレイアウトを作成するのがベストです。ページをデザインに応じた列に分割し、コンテンツをページレイアウト内のコンポーネントに分割します。これにより、コンポーネントをドロップできるプレースホルダーやバケットを作成することができます。プレースホルダーにもコンポーネントを割り当てることができ、デザインの整合性を保つための制約となります。

プレースホルダーを使ったページレイアウトの例を以下に示します。

また、1つのページに複数のレイアウトを組み合わせることもできます。

これにより、デザインで指定された通りにページやコンポーネントを柔軟に構成することができます。

ここで注意しなければならないのは、レイアウトのマークアップで、どのページで使用しても一貫していなければなりません。つまり、必要な方法でカラムを作成するラッパータグは、互換性のあるすべてのコンポーネントをドロップできる共通のインナータグで、一貫していなければなりません。例えば、デザインで「2カラムの左サイドバー」レイアウトを使用するページが複数ある場合、これらのページでは、ページを2カラムに分割する同じアウターマークアップを使用する必要があります。

バックエンドの開発者としては、もちろん、背景色の違いなど、必要な不整合を考慮することはできますが、これらは最小限にとどめ、理想的には、実現可能な限り一番外側のラッパーdivで各ケースに単一のクラスを使用して対応すべきです。これにより、バックエンドの開発者は、レンダリングパラメータを使用してこのような不整合を管理し、選択された値に基づいてマークアップ内の指定されたクラスを追加/削除することができます。

2.モジュラーコンポーネント

すべてのコンポーネントはモジュール化されていなければならず、独立したコンテナの中で自分自身を完全にレンダリングするために必要なすべてのクラスや属性を持っていなければなりません。識別されたコンポーネントの間には相互依存関係があってはならず、決定されたページレイアウトのマークアップを除いて、複数のコンポーネントの周りには追加のラッパーがあってはなりません。

一貫したマークアップを保証するために、フロントエンドチームはテンプレートエンジンを使用することをお勧めします。

各コンポーネントは独立しているので、複数のページ、ページ内のさまざまな位置、異なるプレースホルダー(デザイン上必要な場合)で再利用できます。

CSS(カスケーディング・スタイル・シート)やJavaScriptでは、IDではなくクラスを厳密に使用することで、このような状況に対応できます。

3.再利用可能なコンポーネントの特定

プロジェクトやクライアント、代理店によってウェブサイト開発のビジネスプロセスは異なりますが、デザインからコンポーネントを特定し、あるコンポーネントがわずかな調整や構成で再利用できるかどうかを判断する段階があるべきです。この作業は、ビジネスアナリストが機能仕様書を作成する際に行うものであれ、プロジェクトマネージャーがフロントエンドおよびバックエンドチームとの計画会議で行うものであれ、特定のページやセクションのHTML開発を行う前に行うべき作業です。

これは、視覚的に比較して、(可能であれば)わずかな違いのある類似したコンポーネントをグループ化するための活動です。例えば、同じコンポーネントが異なるページで異なる背景色で表示されていたり、任意の左マージンがある場合などです。注意していただきたいのは、違いは本当に些細なものであるべきだということです。理想的には、1つまたは2つのクラスや小さなマークアップの変更で管理することができ、必要に応じてコンポーネントのデータソースのレンダリングパラメータやフィールドを使用してバックエンドから処理することができます。正しいHTMLを出力するために複雑なバックエンドロジックを作成するのではなく、別のコンポーネントを作成することをお勧めします(メンテナンスが難しく、オーサリングも複雑なコンポーネントになってしまいます)。

4.デザインの不整合に対応

フロントエンド開発者として、UX/デザインチームから提供されたデザインに基づいて作業を行います。モジュール化されたコンポーネントやコンポーネントの再利用など、これまでのポイントを踏まえ、コンポーネント間の間隔やフォントサイズなど、デザインの不整合が見られる場合は、UXデザイナーと一緒に再編成することをお勧めします。UXデザイナーも交えて再編成するのが良いでしょう。このような不整合の多くは、通常、デザインチームと一緒に解決することができ、最終的な開発段階で多くの複雑さを回避することができます。

5.ページ固有のマークアップ – 禁物

前述の通り、サイトコアのページは独立したコンポーネントで構成され、一般的なページレイアウトを使用してブロックにまとめられるのが理想的です。

フロントエンドでは、ページレベルのクラス(about-us / search-resultsなどのbodyタグ)を使用しないことが理想的です。このようなマークアップはすべて、モジュール式コンポーネントの一部としてのみ使用されるべきです。

バックエンドの観点から補足すると、ページアイテムの「class」フィールドを使ってこのようなケースを解決したいと思うかもしれませんが、これは良い方法ではありません。全体のポイントは、コンテンツとプレゼンテーションを分離することであり、この種の関連付けには、コンテンツ作成者が不用意に変更してデザインを壊すことがないように、このようなフィールドをロックするための追加のセキュリティ作業が必要です。

6.リンク

ページ上のリンクを作成する際に留意すべき点をいくつか挙げてみます。

  • アンカーには常に<a>タグを使用し、スイッチの役割を果たす要素にはボタンを使用してください(ボタンを使用すると、JavaScriptで補助されたアクションが実行されます)。
  • 可能であれば、アンカータグにクラスを追加する方が、内部のテキストを追加のタグでラップするよりも好ましい。そうすることで、バックエンドのコードをすっきりさせることができ、エクスペリエンスエディタのサポートを確保しやすくなります。

7.リッチテキスト

サイトコアにはリッチテキストタイプのフィールドがあり、コンテンツ作成者はフォーマットされたコンテンツを管理することができます。これは内部的にはHTMLとして保存されており、コンテンツ作成者はこのコンテンツをHTMLとして表示・編集することができます。この機能は、使い方によっては便利なものでもあり、不便なものでもあります。

理想的には、コンテンツブロック内にハイパーリンクや強力なフォントを使用したページボディなどのフォーマットされたコンテンツが表示されている場合、それがサイトコアのリッチテキストフィールドに対応します。

コンテンツ作成者はこのフィールドに表示されるHTMLを完全に制御でき、さらにサイトコアではリッチテキストエディタにコンテンツが直接入力される際にいくつかの規則を使用するため、ここではフォーマットされたコンテンツをスタイリングする際に留意すべきポイントをいくつか紹介します。

フォーマットされたコンテンツのマークアップは、できるだけシンプルで予測可能なものにしてください。

  • リッチテキストコンテンツに必要なスタイリングは、リッチテキストフィールド全体のコンテンツをラップするラッパーのクラスを使って行うのが理想的です。デザインの複雑さのために100%実現できない場合もありますが、クラスや他の属性を使って複雑なマークアップを追加すると、コンテンツ作成者がコンテンツ編集中に誤ってマークアップを変更し、デザインを壊してしまうリスクが高まることを覚えておいてください。
  • サイトコアのリッチテキストフィールドに入力されるHTMLに多くのクラスや特殊タグがある場合、コンテンツ作成者が使用できるようにリッチテキストエディタにカスタムクラスやスニペットを提供することを検討してください。
  • コンテンツ作成者がリッチテキストエディタでコンテンツを入力すると、サイトコアはコンテンツに<p>タグを追加して、改行ではなく段落を表すようにしています。ベストプラクティスとしては、リッチテキストフィールド用のHTMLに<p>タグを使用しないことです。これは、<p>タグのネストや、リッチテキストフィールドのエディタモードでコンテンツを編集した際に生じる互換性のないマークアップを避けるためです。

8.エクスペリエンスエディタ

サイトコアには、コンテンツを編集するための強力なWYSIWYGエクスペリエンスエディタモードがあります。エクスペリエンスエディタモードの機能と競合しないように、HTMLをオーサリングする際にいくつか考慮すべき点があります。

エクスペリエンスエディタモードでは、追加のマークアップが挿入されることを考慮してください。CSS/JavaScriptで位置ベースのセレクタの使用を避ける。

スライダーやカルーセルなど – は、JavaScriptを使用して初期化されますが、これらの構造の中でコンテンツを編集するのは厄介なことです。コンポーネントの複雑さに応じて、スライダー/カルーセルを通常モードのみで初期化することもできます(補足:バックエンドチームは、サイトを簡単に表示するためにどのモードを使用しているかを示すクラスを body タグに追加できます)。エクスペリエンスエディタモードでこれらを初期化しないことで、これらのコンポーネント内のすべてのコンテンツを簡単に編集することができます。ただし、この場合、そのようなコンポーネントの編集モードのWYSIWYGプロパティが制限されます。ここでの良い解決策は、ウェブサイトのプレビューにはプレビューモードを使用し、コンテンツのポストエディットにはエクスペリエンスエディタを使用するようにコンテンツ作成者を教育することです。これらのモードは、通常、同じデータベース(したがって、コンテンツ)から実行されます。

9.jQuery

プロジェクトで jQuery を使用している場合は、フレームワークの衝突を避けるために noConflict() を使用することを強くお勧めします (エクスペリエンス エディタの場合)。

クロージャを使用し、コードを自己起動型の関数でラップしましょう。そのための参考文献を紹介します。

https://api.jquery.com/jquery.noconflict/

https://programmersought.com/article/72996716873/

https://blog.mgechev.com/2012/08/29/self-invoking-functions-in-javascript-or-immediately-invoked-function-expression/

10.APIインテグレーション/jQuery作業

ページネーション、ファセット、フィルタ、ソートなどの機能があるリスティングや検索などの機能では、APIを介してバックエンドと連携し、ページ全体を更新することなく、ユーザーのアクションに応じて更新されたコンテンツを取得し、ページに表示する必要があるかもしれません。データの種類やビジネス上の必要性に応じて、以下のようなアプローチをとることで、バックエンドとの連携を迅速に行い、やり取りを少なくすることができます。

  • 必要なデータをJSON文字列としてマークアップに追加し、このJSONを使って機能するようにコード化する。この場合、バックエンドの開発者は、サイトコアのコンテンツからマークアップで提供する必要のあるJSONの例を得て、意図したとおりに機能を動作させることができます。- 決められたフォーマットでJSONを返すモックAPI( https://apiary.io/ のようなホスト)を使用します。APIのURLはマークアップに含まれていなければなりません。バックエンド開発者は、これを自分が作成したAPIに置き換えて、自分が規定したのと同じJSON形式でデータを返すことができます。

これらの機能は通常、フロントエンドとバックエンドのコラボレーションが必要ですが、上記のような方法ですぐに実装することで、プロセスを合理化し、機能を稼働させるためにチーム間で行き来するオーバーヘッドを削減することができます。

11.サイトコアフォーム

デザイン上のフォームの種類に応じて、カスタムフォームとサイトコアフォームのどちらを使用するかは、サイトコアチームが判断するのが理想的です。

サイトコアフォームは、コンテンツ作成者によるカスタマイズが必要なフォームによく使用されます。この場合、コンテンツ作成者は、フィールドの追加/削除、バリデーションの設定、フォームデータの送信先、フォーム送信後のユーザーのリダイレクト先などを設定することができます。サイトコアには、このような作業を支援するために、独自のフォームデザイナーアプリケーションが組み込まれています。

OOTB(アウトオブザボックス)では、サイトコアフォームでは、クラスの追加(Sitecore 10.1では、バックエンドチームがクラスのリストを設定して、コンテンツ作成者が選択できるようになっているので、コンテンツ作成者にとってはるかに簡単です)や、フィールドを特定のラッパーにグループ化するなど、タグの基本的な変更が可能です。マークアップを作成する前に、バックエンドチームに、デザイン上のフォームで使用されているほとんどの構造を持つサンプルフォームを作成して、フロントエンドチームが同じものを利用できるようにすることを要求するのが良いでしょう?フロントエンドチームは、生成されたマークアップをカスタマイズしようとするのではなく、生成されたマークアップを使って作業することができます。

以下の例をご紹介いたします。

 

デモを申し込む

弊社の専門家は最適なソリューションをサポートさせて頂きます。

 

►►►サービスについて