Drupal8のモジュール（ckEditor）にソースコードハイライトプラグイン（ckeditor_syntaxhighlight）の追加方法

タグ

syntax highlighter

wyusiwyg

ckeditor

Drupal8ではckEditorモジュールがコアーに入っている

Drupal7ではリッチテキストエディターを必要な時に、WYSISWYGモジュールか、ckEditorモジュールなどをインストールする必要があります
Drupal8ではckEditorモジュールがコアーに入っているので、インストールする必要はありません
- ckEditoのプラグイン、ボタンを追加するには、Drupal7と比べると、ちょっと面倒な作業があるようです

ckEditoにソースコード・ハイライト（syntaxhighlight）プラグインをインストールします

ckEditoのソースコード・ハイライト（syntaxhighlight）モジュール：CKEditor Syntax Highlighter
モジュール（CKEditor Syntax Highlighter）が三つの部分を依存しています
モジュール（Drupal Syntax Highlighter module）を通常にインストールします
- syntaxhighlighterの本家からjsライブラリをダウンロードします
- jsライブラリ（syntaxhighlighter）をdrupal/libraries/syntaxhighlighterに展開します
  - shCore.js がdrupal/libraries/syntaxhighlighter/scriptにあることを確認します
通常のインストール方法でモジュール（Libraries）をインストールし、有効化します
プラグイン（CKEditor Syntax Highlight plugin）をgitHubからダウンロードします
- ダウンロードされたプラグインをdrupal/libraries/ckeditor_syntaxhighlightの配下に配置します
- プラグイン（plugins）ディレクトリはdrupal/libraries/ckeditor_syntaxhighlightの下にあることを確認します
- このプラグインのインストール方法はあまり詳細に説明されていなくて、戸惑うことが多いでしょう。

シリーズ記事一覧

記事カテゴリ

タグ

タクソノミー・タームの選択ツールについて

記事編集画面でタクソノミー・ターム（例：タグ）などの初期選択ツールが自動補完/セレクトボックスなどがあります
Drupal7では：Hierarchical Select モジュールをよく使用しました。
- とてもシンプルとは言えないですが、使いやすいモジュールでした
- 選択だけではなく、新規タームの作成もできました
Drupal8では： Hierachical SelectモジュールはDrupal8のバージョンを提供していない
- Drupal8では、Simple Hierarchical Select, Chosen などのモジュールがあります
- 階層別で選択では、Simple Hierachical Selectでは十分機能しています
- Chosenはサードパーティーのモジュールで、jsライブラリのダウンロード/インストールが必要です

モジュール（Simple Hierachical Select）が使いやすいが問題があり

現時点では、Simple Hierachical Selectモジュールのバージョン：8.x-1.0-alpha4
モジュールを通常にインストールして、設定画面で、新規ターム作成許可のチェックボックスが無効化されています
この点をインターネットで調べてみたら、実際に解決されていない問題があります
- 詳細説明ページ：https://www.drupal.org/project/shs/issues/2712115
- パッチ幾つかが提供されていますが、根本的な対応策が見つかっていないようです
- でも、ターム新規作成をしなければ、このモジュールが十分使えます

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7の基本

Drupal７の初期コンポーネントはいくつかしかない
- Content Type：　Article ⇒ 記事の構造（コメント機能、例Blogの構造）、Basic Page ⇒ Articleと似ている、単純的なページの機能（コメント機能なし、ほかにはArticleと同じ）
- Taxonomy：　タグをつける機能。データのツリー構造、キーワード／タグとして、記事の纏めに役に立つ
- People：　ユーザーのプロファイル、ログイン、アクセス権限などに利用される
- Menu：　メニューの構成を管理する
- Block：　ページの構成、コンテンツがどこに表示するかなどの管理
- Appearance：　サイト全体の構成、テーマ、表示などの管理
- その他
記事などのデータ／コンテンツ管理は：Content Type、Taxonomy、Peopleなど
記事などのデータ／コンテンツの表示管理は：Menu、Block、Appearenceなど
上記機能だけで、簡単なウェブサイト構築が可能となる

Contentsについて

ウェブページ上に表示されている内容がコンテンツです　＜－　エンドユーザーからの視点から見る
- コンテンツがContents Type（同じフィールドを持ち）に分類され、一つのコンテンツ・タイプが複数のコンテンツから構成されます。
一つウェブサイトに複数のコンテンツ・タイプがあります。
- Drupal7の初期コンテンツタイプ：Article、Basic Page。ほかにBook Page、Forum topic、Pollなどがインストールされている（無効化されている）
- ユーザーが必要なフィールド及びフィールドの入力/表示方式を決めて、新しいコンテンツタイプの作成が出来る
- コンテンツタイプにある各フィールド、フィールドの入力制御、フィールドの表示などを管理するルーツCCK（Content Constructuion Kit）がDrupal7に初期インストールされている

Nodeについて

Drupal での重要なコンセプトは、すべてのContentsをノードとして保管するということです。
Nodeはシステムの基本ビルディング・ブロックで、これを基礎としてDrupal に保管されたコンテンツを拡張します。
開発者は新しいノード・モジュールを作成することによって、それぞれのサイトのニーズに特有の追加フィールドをデータベースに定義し、保管できます。
Nodeはタイプによって分類されます。各ノード・タイプの操作とレンダリング方法は、そのユース・ケースに基づいて変えることができます。
標準ノード・タイプには、以下のものが含まれます。
- ページ (Pages)：　コンテンツを表示するためのシンプルなノード。PHP を使用して、コンテンツを動的に更新できます。コンテンツのどの部分でも、PHPを組み込むことによって動的にすることができます。
- ブログ・エントリー (Blog entry)：　オンライン・ジャーナルやウェブログを保持するノード。
- フォーラム (Forum)：　ノードとそれぞれのコメントのセット。これらのノードは、タクソノミー (taxonomy:分類方法) を割り当てることによってグループ化されます。
- ストーリー (Story)：　一定の日付が過ぎると期限切れになる汎用ページ。通常のページと同様ですが、スタイルを変えることができます。
- コメント (Comment)：　特殊なタイプのコンテンツで、他のノードで定義されたコンテンツに関するコメントをユーザーが追加できます。コメントはノードのタイプではないため、データベースの別個のテーブルに保管されます。
データベースは、Nodeに関する基本的な情報一式を記録します。
- この情報には、タイトル、簡単な記述(または要約)、および本文が含まれます。
- 作成者、作成時間、ステータスに関する情報も記録されます。通常、アプリケーションに必要な情報を追加するには、新しいノード・タイプを作成し、そのノード･タイプに対して明確に定義されたデータベース・テーブルに書き込む必要があります。
Drupal は、ノード・コンテンツに加えられた変更に対応するためのリビジョン・システムをインプリメントします。モジュール開発者はこのシステムを使用して、ノード・リビジョン専用に割り振られたテーブル内のそれぞれのノード更新に対する新規データベース・レコードを切り取ることができます。詳細は、Drupal revisions overhaul に記載されています。
詳細な説明はここです。

Entityについて

Drupal7ではContent TypeがNodesとも言われている：いろいろなコンテンツがNodesの扱いとなる
- Nodes：　すべてのコンテンツをノードとして保管するということです。ページ、アンケート、記事、フォーラム、Blogなどを指している
- CommentsがNodeではない。Commentsがいつもコンテンツ（例Articleなど）に付加されているし、単独な存在はしない。
- Nodesの大きな特徴は、いろいろなフィールド（Text、image、Fileなど）が自由自在に追加されることができる。入力フォームと表示フォームの管理ができる。作成者、作成年月日などのプロパティがある。メニュー／表示管理ができる
Drupal7のEntityはユーザー、コメント、ノートなどの元となる概念
- Drupal7 Dataで見ると以下のような構造となる
  - Custom Database table
  - Entity
    - User
    - Comment
    - File
    - Taxonomy Vocabulary
    - Taxonomy term
    - Node(・Page, ・Blog post, ・Articleなど)
  - Custom entity Type
Entityの構造はEntity Type、Entity、Bundleのようなもの
- Entity Type：　いろいろなコンテンツタイプ（Nodes (content), Comments, Taxonomy terms, User profiles）がEntity Typeの一種類となる
- Entity：　Entity Typeのインスタンス。
- Entity Properties：　Entity Typeの共通項目をプロパティで表現する（例：Content typeは作成者、作成日付、アクセス権限などがContent typeのプロパティとなる）
- Bundles ：　各Entity Typeで生成されたオブジェクトの束（例：車のEntityTypeに乗用車、トラック、救急車などのBundlesがある）
- Fields：　各Entityに追加された項目（Entity Properties以外のもの、共通なものではない）

Entity と Nodesの違い

Nodes　　　　　　　　　　　　　　　　　　　　　　　　　　Entities

サイトにすでに存在　　　　　　　　　　　　　　　　　　オプションで追加
コンテンツ、フィールドなどをUIで追加　　　　　　　開発に利用することが多い、UIのサポートが少ない
バージョン管理でリリース　　　　　　　　　　　　　　個人での管理
データがNodeテーブルに保存　　　　　　　　　　　データ保存の個人管理可能
各ケースに必要のないパーツも削除できない　　すべてのパーツが自由に組わせ、拡張性とパフォーマンスが良い

シリーズ記事一覧

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupal7と比較すると、Drupal8のノード（node）のデータテーブルこう構造が変わった

Drupal7ではノード（node）テーブルがタイトルが含まれています
- タイトル、編集ユーザーなどがあります
Drupal8ではノード（node）テーブルがタイトルなどが含まないです
- 単にノードID（nid）、リビジョンID（vid）のみの識別情報となります

Drupal8のリビジョン管理がnode_revisionテーブルで行います

ノード単位のリビジョンがnode、node_revisionテーブルで行います
nodeテーブルでは、単にnid、vid、typeの管理
node_revisionテーブルでは、nid、vidのみでリビジョンを管理しています

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ

Drupalのテーマレイヤー（theme layer）がロジック層（Logic）とプレゼンテーション層（Presentation）が徹底的に分離されています

初心者として、Drupalのテーマに関するソースコードを読む時に、どこで定義して、どこから呼び出されているかは分からなく、理解するときに少し難しいかもしれないです。
この難しい構造は、実はロジック層とプレゼンテーション層をしっかり分けたせいかもしれません。
ロジック層とプレゼンテーション層を分離したメリットがいろいろあります
- オーバーライトするのは簡単にあります（拡張性がよい）
- 簡単に、どこでも呼び出すことができます
抑えるポイントとしては：
- テーマの登録
- テーマの実装
- テーマの呼び出し

hook_themeの実装でテーマの定義を行います

任一の場所で呼び出す可能にするため、テーマをシステム登録する必要があります

hook_theme()でテーマを登録します

/**
 * Implements hook_theme().
 */
function MODULE_NAME_theme(){
    return array(
        // function テーマの定義
        // 実装時に form_a の名前で
        'form_a' => array(    
              'render element' => 'form_element' ,
              'variables' => array('vars' => NULL),
              ・・・・
        );

        // template テーマの定義
        // 実装時に form_b の名前で
        'form_b' => array(
             'template' =>  'form_temp' ,
              'path' => "theme_dir", // テンプレートファイルのパス
              'variables' => array('vars' => NULL),
              ・・・・
        );

    );
}

登録内容は抽象的に、具体的になロジックはありません：
- テーマの実装される名前（例：form_a/form_b）
- テンプレートファイル名
- テンプレートファイルのパス
- 渡すパラメーター配列のキー
- など（具体的にはAPIを参考）
テーマの定義を実装するのはファンクションか、テンプレートファイルか、2種類です

カスタム関数で（theme_ARRY_KEY）／テンプレートファイル（ARRY_KEY.tpl.php）でテーマ定義の実装

カスタム関数を新規作成して、テーマの定義を実装します
- カスタム関数名： theme_ARRY_EKY : ARRAY_KEYはロジック層の定義配列のキー（例：ARRY_KEY: form_a、関数名：theme_form_a() となります）
- テーマ具体的な内容を定義します
```
function theme_form_a(){
    return print( '<form method="get" ・・・・</form>') ;
}
```
テンプレートファイルを作成して、テーマの定義を実装します
- テンプレートファイル名： ARRY_KEY.tpl.php （例：ARRAY_KEY:form_b、テンプレートファイル名： form_b.tpl.php となります）
- 上記同様にテーマの内容を定義します
```
<-- HTMLでの出力  -->
<form method="get">
  ・・・・
</form>
```

theme()関数でパラメータを渡したり定義されたテーマを呼び出して出力します

どこかでtheme()関数でテーマにパラメータを渡して、HTMLコードを出力します
theme('ARRAY_KEY', array(パラメーター配列) )でテーマを呼び出し
- ARRAY_KEY：テーマ定義の配列キー（例： form_a、 theme('form_a') となります）
- パラメーター配列（例： array('vars' => 'some words') となります）
```
//  form_a テーマの呼び出し
$output = theme('form_a', array('var' => '1234'....) ) ;

//  form_b テーマの呼び出し
$output = theme('form_b', array('var' => '1234'....) ) ;
```

シリーズ記事一覧

記事カテゴリ

タグ

Drupalの構造は複雑で、簡単に説明が難しいです。ここで、いろいろな文書を参考しながら、いろいろな角度でDrupalの構造をまとめたいと思います。

Layerと処理フロー

Drupalがデータからプレゼンテーションまで、いくつかのレイヤーを分けることができます
データ：　DBからノードなどの単位でデータを取得したら、DBにデータを保存するなどに構成されます
モジュール：　コアモジュール/Contributeモジュール/Customモジュール（独自のモジュール）があります。ほとんどの機能、表示などを纏めて処理します。
ブロック/メニュー：　画面の表示場所と表示条件管理を行います
ユーザー権限：　ユーザーの各コンテンツの新規作成、更新、削除、表示などの権限管理を行います
テンプレート：　画面に表示管理を行います（画面から、フィールドまでのテンプレート化ができます）

Hierarchical MVC

Drupalの構造はPAC（Presentation-Abstraction-Control model）、またはHierarchical MVCとは言われています。
簡単に言うと、階層化されたMVC構造です
トップレベルから各表示のフィールドまでMVC化することができます
この特徴はモジュールViews、Panelsなどを利用するとよくわかります。

モジュールは縦構造

もし、Drupalコーアの各機能（例：データ、ビジネスロジック、プレゼンテーションなど）を横構造であれば、各モジュールが縦構造となります
モジュール内でデータデータ取得、ビジネスロジック、プレゼンテーションなどの機能を独自に書くことができます。
モジュールがコアとの連携はhookか、コアの関数で行います。
- コーアのコード変更は行わない。hookでオーバーライドするか、コアの関数でデータやり取りを行います
- コアのロジックは絶対に書き換えないことです（書き換えたら、次回のアップデータする際に書き換えた部分が消えます）。
モジュールとモジュールの連携は、モジュールに提供されたAPIで行います。
- モジュールに提供されたAPIはhookの形で操作します
- モジュールがAPIを提供していなければ、通常は連携できないです。
- モジュール内の関数を利用できる場合がありますが、注意深く利用する必要があります。

hookと関数の違い

hookは関数（function）です
hookを利用して独自なロジック/データ/形で元の機能をオーバーライドすることができります
- 例：hook_form_alter()、既存のフォームに要素の追加、削除、変更ができます。
- 元の機能/形を完全に変えることができます
関数はコアの機能/データなどの設定、利用に使われます。

ノード(Node)から積立てたもの

Drupalがパズルのように一ピース一ピースで積立てたものと言われています
そのパズルの元はノード(Node)であります。
複数のノードはコンテント（Content）となります。Drupalはコンテントの表示、入力、更新を管理します
Coreシステム、Theme、メニュー、ブロックなどはノードをサポートします
ModuleなどはCoreシステムをサポートします

シリーズ記事一覧

記事カテゴリ

タグ