Tridion関連のコードには、特定のアイテム（スキーマ、テンプレート、またはコンポーネント）が必要になることがよくあります。テンプレート、コンテンツ配信、ワークフロー、またはビジネスコネクタ（コアサービス）は、定期的にTridion ContentManagerURIへの参照を必要とします。コンポーネントにリンクすることはできますが、他のすべてについては、通常、ハードコードされた値またはWebDAVURLのいずれかが表示されます。
ハードコードされた値
Tridion Content Manager（Native）URIをハードコーディングすることは、いくつかのシナリオを除いて悪い習慣であることを理解しています。
- サンプルコードを簡略化し、変数とは何かを明確にするため
- コンテンツ配信（CD）APIロジックで使用するために生成された場合
可能な限り、指定されたAPIまたはWebDAV URLを使用してアイテムを参照します。それ以外の場合は、TCM URIを参照するものにContentPorterを使用しないようにする必要があります（または、何らかの方法でこれらの参照をTridionの外部で「構成可能」にします）。
WebDAVのURL
WebDAV URLは、いくつかの理由で優れているようです。
- デザインテンプレートビルディングブロック（TBB）またはその他のテンプレート形式でハードコードされた値は、SDL Content Porterでそのまま残ります（以下で説明する例外を除いて、CMS環境を移動すると関係が失われます）
- 特定のアイテムを参照する「構成」コンポーネントは、SDL Content Porterでもうまく機能しますが、異なる名前のパスは関係を「壊す」可能性があります
ユースケース
Content Porterでうまく機能するテンプレートがあることに加えて、フォルダーや構造グループを下位の出版物にローカライズしたいと思います。これは次の場合に役立ちます。
- さまざまな言語を読むCMS作成者
- アイテム名とパスを適切な言語に翻訳する
- ユーザーがより適切にナビゲートするのに役立つかもしれません（たとえば、異なる名前のフォルダーは、作成者がBluePrintのどこにいるかについての混乱を減らす可能性があると思います）
1つのアプローチ
少なくともテンプレートビルディングブロックについて「コンテンツポーターフレンドリー」を参照するために、コンポーネントでWebDAV URLを使用して、子供向けの出版物の適切な場所に各パスを確実にローカライズできることを知っています。例えば：
- コードはパブリケーションメタデータをチェックします
- パブリケーションメタデータは「構成コンポーネント」を指します
- 構成コンポーネントには、WebDAVURLとしてのパスがあります
パブリケーションメタデータを設定し、フィールドをパブリケーションごとに正しいパスにローカライズする限り、これはほとんどのシナリオで機能します。
質問
- 私はこれを正しく理解しましたか？よりシンプルでメンテナンスしやすいセットアップはありますか？
代わりに、テンプレートコードでインクルードまたはアンマネージURIをマップすることもできると思います。
#include誰かがアプローチの例を持っていますか？TBBやDWTの上部でそれを使用し、テンプレートメディエーターに関係なく参照が置き換えられますか（たとえば、これはXSLTメディエーター、Razorメディエーターなどで機能しますか？）含まれているリファレンスは下位の出版物で機能しますか、それともContent Porter専用ですか？言い換えると、「tcm：5-123」を参照すると、テンプレートはパブリケーション17の「tcm：17-123」を正しく参照しますか？