ソースコードは github: https://github.com/lvyahui8/dbuilder.git にあります。記事内の写真が小さすぎてよく見えない場合は、「新しいタブで開く」を右クリックして元の写真をご覧ください

第 1 章の概要

1.1 研究の背景と意義

コンピュータソフトウェア技術の発展により、データベースはフォーマットされたデータを保存するために最も広く使用される媒体となり、データベースプログラム開発技術もますます完成し、データベースプログラム開発を簡素化し、運用の主流になりました。リレーショナルデータベース。データベースプログラムの主要なコードは CRUD (作成、取得、更新、削除) コードです。ORM フレームワーク機能の改良により、CRUD コードを作成することにより、別のデータベーステーブル上で動作する CRUD コードも高度に再利用できます。。現在、開発者は繰り返し CRUD コードを記述することが常態となっており、開発者の熱意が著しく低下するだけでなく、開発効率も低下します。そのため、この作業を軽減するために、CRUD コードを迅速に生成できる製品が急務となっています。開発効率を向上させます。

1.2 研究状況

現在、海外ではCrudKit、CRUD-Admin-Generator、Dadabik、GroceryCrud、SximoBuilderといった、上記のニーズを解決するユーザビリティの高いCRUDジェネレーター製品が生まれています。これらの製品にはそれぞれ独自の特徴がありますが、共通点もあります。それは、すべて PHP に基づいて開発されているということです (これは、PHP 構文の柔軟性と解析によってある程度決まります)。代表的なものとしては SximoBuilder が挙げられます。 SximoBuilder は、デザインが独特で使いやすさが高く、人気も高いのですが、次のような欠点もあります。

カスタムフォームコントロールはサポートされていません;

複数のデータベースはサポートしません;
検証ルールが不完全で、非同期検証はサポートされていません。
コードは非常に冗長です。
しかし、今日のますます複雑化する Web プログラムでは、上記の点は開発プロセス中に考慮する必要がある問題であるため、SximoBuilder の既存の機能を備えているだけでなく、その欠点を改善した CRUD ジェネレーター製品の開発が不可欠です。

1.3 研究内容

国内外の CRUD ジェネレーターの研究状況を踏まえ、著者は DBuilder (D は DataAdministrator の略) と呼ばれる CRUD ジェネレーターを開発しました。

DBuilder は、モジュールがコード単位であり、コードがテンプレートから生成されるという SximoBuilder の考え方を利用していますが、コード生成ロジックは SximoBuilder とは完全に異なります。 SximoBuilder のコアコード生成と一般的な CRUD 機能の実現に基づいて、コードロジックを書き換えることでその欠点 (大規模なコードの冗長性とフロントエンド検証の欠如) を改善します。

第 2 章 DBuilder システム分析

DBuilder の主なユーザーグループは Web バックエンド管理者と開発者であるため、そのシステム分析プロセスでは、より Web バックエンド管理者と開発者の観点から問題が考慮されます。

2.1 要件分析

プロジェクトは次のコア機能を実装する必要があります。

データソース管理ユーザーはインターフェースでプロジェクトの複数のデータソースを設定できます。設定されたデータソース情報には、データベースの種類、アドレス、データベース名、ポート、ユーザー名、パスワード、その他の情報が含まれます。データソースの追加、削除、変更、クエリをサポートし、データソースの追加、削除、変更、クエリによってシステムの問題が発生しにくくなります。

コード生成

この機能は、データソースとデータテーブルを選択した後、フォーム構成、リスト (テーブル) リスト構成、リレーションシップ構成、およびグローバル属性を含むデータベーステーブルのフィールドを簡単に構成できます。。構成。構成が完了したら、DBuilder はデータベーステーブルの CRUD MVC コードを生成できる必要があります。つまり、CRUD で使用可能な関数を実装する必要がありますが、コードを記述する必要はありません。

データベース

テーブルCRUD

生成されたコードは、データテーブルレコードの作成、削除、更新、およびクエリ操作をサポートする必要があります。

メニュー管理

DBuilder は、ユーザーがメニュー項目をクリックした後に DBuilder によって生成された CRUD 関数を使用できるように、生成されたコードをメニュー項目にバインドできる必要があります。このメニューにはバックグラウンドメニューが含まれている必要があります。フロントメニューは必要ありません。

ユーザー管理

ユーザーは複数の役割を実現する必要があります。電子メールアドレスは、ユーザーの一意の識別子として、またログインパラメーターとして使用できなければなりません。将来的には、OAuth2.0 に基づく QQ、WeChat、Sina Weibo の相互接続ログインのサポートも実装する予定です。

権限管理

DBuilder は、さまざまなユーザーロールに対するさまざまな CRUD コードの実行およびアクセス権の 3 次元構成機能を実装できなければなりません。たとえば、記事管理用の CRUD 機能モジュールがあり、ユーザーの役割がシステム管理者 (SuperAdmin)、管理者 (Admin)、ゲスト (Guest) に分かれており、DBuilder は次のような 3 次元の権限設定を実装できる必要があります。そしてそれをすべてのモジュールのデフォルトの権限として使用します。

表 2-1 モジュール権限設定表

ユーザーグループと権限	見る	編集	削除	エクスポート
スーパー管理者	√	√	√	√
管理者	√	√	√
ゲスト	√

7) サイトパラメータ設定

DBuilder は、Web サイトの Web バックグラウンドプログラムとして、サイトのグローバルパラメーターを構成するためにも必要です。これらのパラメーターには、Web サイト名、キーワード、連絡先アドレス、フレンドリーリンクなどが含まれます。

8) 操作ログ

DBuilder は、訪問したページ、実行された CRUD の種類、時間、その他の情報を含むユーザーの操作情報を記録する必要があります。ログ記録形式は、データベースとファイルの 2 つの方法をサポートしています。

9) 複数の言語サポート

DBuilder は複数の言語間の切り替えをサポートする必要があります。中国語と英語の少なくとも 2 つの言語がサポートされる必要があり、中国語がデフォルトになります。

10) 複数のデータベースタイプをサポート

DBuilder は複数の種類のデータベースをサポートする必要があり、現在は主に mysql、MS SqlServer、oracle、PostGreSQL などのリレーショナルデータベースをサポートしています。

2.2 データプロトタイプ分析

要件に応じて抽出できるエンティティには、ユーザー、ユーザーグループ、データソース、コードモジュール、メニューが含まれ、関係には権限とログが含まれます。エンティティと関係の意味は次のとおりです:

User: DBuilder を使用するユーザーを示します。
データソース: DBuilder に含まれるデータベース構成を表します。データソースの構成には、データベースに接続するために必要な基本パラメーターが含まれます。
Menu: DBuilder の左側のメニュー項目を表します。
Log: 各コードモジュールに対するユーザーの CRUD アクセスログを表します。

図 2-1 ER 図

2.3 原則要件

DBuilder は、高性能で可用性の高い CRUD ジェネレーターのセットとして作成される必要があります。このために、DBuilder の設計は次の原則に準拠する必要があります。

DBuilder はデータベースフィールドごとに正確で構成可能である必要があります。

ユーザーがこれに基づいて完全な WEB バックエンドアプリケーションを迅速に構築できるように、WEB バックエンドアプリケーションのプロトタイプが必要です。

DBuilder は、必要に応じて、キャッシュ、非同期、その他のテクノロジを使用して、リクエスト処理ロジックを削減し、ページの効率を向上させ、ユーザーの待ち時間を短縮する必要があります。

DBuilder には、美しく、簡潔で、直感的なユーザーインターフェイスが必要です。

DBuilder は多数の拡張インターフェイスを残し、ユーザーが二次開発を通じてより複雑な機能を迅速に実装できるようにする必要があります。

第 3 章 DBuilder システム設計
3.1 システムアーキテクチャ
DBuilder には次の 2 つのコアコンポーネントがあります: コア CRUD モジュールと GModule。GModule は MVC コードと CRUD Config で構成され、GModule は DBuilder によって生成されます。コード。コア CRUD モジュールは CRUD 操作を実装し、GModule は拡張機能を実装します。以下の図は、これら 2 つのコンポーネントの構成と関係を示しています

図 3-1 概念とコンポーネント

以下は、図で設計された概念、コンポーネント、モジュールの関係、ビルドおよび CRUD プロセスの詳細な説明です。

3.1.1 コア CRUD モジュール

コア CRUD モジュールは、コア CRUD 操作を実装します。GModule MVC のコントローラーへのすべての CRUD リクエストは、最終的にコア CRUD モジュールに転送されて処理されます。 Core CRUD モジュールは、GModule が実装する前処理および後処理インターフェイスを開きます。これらのインターフェイスは、モデル、コントローラー、およびビューに反映されます。

コアCRUDモジュールには主に以下のファイルが含まれています

app/controllers/admin/AdminController.php

app/models/BaseModel.php

app/config/crud/admin.php app/views/admin/core/list.blade.php

app/views/admin/core/form.blade.php

コア CRUD モジュールは GModule 設定を読み取り、実際の CRUD 操作を実装します。
3.1.2 Gモジュール
GModule (生成されたモジュール) は、コア CRUD モジュールインターフェイス (MVC コード) を実装するだけでなく、独自の構成ファイル (CRUD 構成) も持ちます。
。たとえば、DBuilder によって生成された GModule、メインテーブルがコアデータソースユーザーテーブル、名前が User の場合、ユーザー GModule には次のコードファイルが含まれている必要があります:

コントローラー/UserController.php
models/User.php
views/user/_list.blade.php
views/user/_form.blade.php
views/user/view.blade.php
config/crud/user.php

コードファイルの名前は GModule の名前に依存するため、生成されたコードファイルが競合しないようにするために、GModule の名前 (GModule Key、GModule Name) が、GModule の固有の識別子として使用されます。 Gモジュール。各GModuleの情報はデータベースに保存されます。新しい GModule 操作では、上記のすべてのコードファイルが作成され、関連ファイルが更新され、GModule レコードがデータベースに挿入されます。 GModule の更新操作では、構成ファイルのみが更新されます。

GModule は、以下で説明する MVC コードと CRUD 構成コードで構成されます。

MVC コード: 拡張インターフェイスの実装に使用されます。 CRUD リクエストは、まず GModule MVC のコントローラーにルーティングされる必要があります。また、GModule MVC は、Core CRUD モジュールの MVC コードと継承関係を持つ必要があります。
CRUD 設定コード: GModule メインテーブルのパラメータの追加、削除、変更、クエリの設定を実現します。このファイルは app/config/crud/ ディレクトリに配置され、php 配列の形式で定義されます。これには、すべてのフィールドのフォーム、リスト、ビュー、リレーションシップなどのパラメーターの構成と、グローバルパラメーターの構成が含まれます。

3.1.4 ビルドと CRUD プロセス

DBuilder プロジェクトのソリューションは、実際の CRUD 操作をコア CRUD モジュールに渡して実行します。CRUD パラメーターは GET または POST リクエストパラメーターと GModule 構成で構成されますが、GModule の MVC コードはコア CRUD の前処理またはオープン性のみを実装します。 MVC 後処理インターフェイス。

図 2-3 は、モジュールの生成と CRUD リクエストの処理を含む DBuilder のコアフローチャートです。図 2-4 は、SximoBuilder でのモジュールの生成と CRUD リクエストの処理のフローチャートです。

図 3-3 DBuilder コード生成と CRUD 処理プロセス

図 3-4 SximoBuilder コード生成と CRUD 処理プロセス

2 つを比較すると、2 つの最大の違いは、Sximo のように独立して実行できるモジュールごとに CRUD コードのセットを生成するのではなく、DBuilder が CRUD コードを再利用することであることがわかります。この利点は、モジュール CRUD MVC を介して前処理/後処理インターフェイスを実装することにより、再利用性が向上し、スケーラビリティが実現されることです。

3.2 コアデータソース

コアデータソースは、DBuilder のデフォルトのデータソースです。そのタイプは mysql で、データベース名は dbuilder です。このセクションでは、「データプロトタイプ分析」セクションに従って詳細なデータベース設計を実行します。プログラムのパフォーマンスを向上させるために、データソース情報はコードファイル app/config/datasource.php に保存されます。ファイルの内容は次のとおりです。

'コア' =>

配列 (

'ドライバー' => 'mysql',

'ホスト' => 'ローカルホスト',

'データベース' => 'dbuilder',

'ユーザー名' => 'root',

'パスワード' => 'root',

'charset' => 'utf8',

'照合順序' => 'utf8_unicode_ci',

'プレフィックス' => '',

'編集' => false,

'ポート' => 3306,

)、

// その他のデータソース

);

2) D_module テーブル: モジュール情報を記録します。 d_module テーブルの各レコードは、DBuilder によって生成されたモジュールを表します。

表 3-2 モジュール情報の説明

フィールド	タイプ	デフォルト	情報
ID	int	自動インクリメント	プリ
モジュールID	int
モジュール名	varchar(12)
親ID		ヌル	親メニュー項目
タイトル	varchar(12)	module_title	表示名
_注文	int	0	フィールドの並べ替え

フィールド	タイプ	デフォルト	情報
ID	int	自動インクリメント	プリ
名前	varchar(32)		ういん
タイトル	varchar(32)		モジュールタイトル
メモ	varchar(32)		モジュールの説明
db_source	varchar(16)	コア	データソース名
db_table	varchar(16)		モジュールメインテーブル
db_table_key	varchar(16)		メインテーブルPRI

3) D_user テーブル: バックグラウンドプログラムを使用するユーザーを保存します。

表 3-3 Web バックエンドユーザー

フィールド	タイプ	デフォルト	情報
ID	int	自動インクリメント	プリ
ユーザー名	ヴァルカー(64)		ユーザー名
メール	varchar(64)		メール
パスワード	varchar(64)		ハッシュ
塩	varchar(64)		塩
last_login	タイムスタンプ		最終ログイン時間
remember_token			パスワードを忘れないでください
グループID	int		グループID

4) d_group テーブル: バックグラウンドユーザーのグループ化情報を表します。

表 3-4 ユーザーグループ表

フィールド	タイプ	デフォルト	情報
ID	int	自動インクリメント	プリ
名前	ヴァルカー(64)		グループ名
メモ	varchar(128)		グループの説明
レベル	int		グループレベル

5) D_group_access テーブル: 各 GModule、異なるバックグラウンドユーザーグループ、およびさまざまな操作権限の 3 次元の権限情報を記録します。

表 3-5 モジュールのユーザーグループ権限テーブル

フィールド	タイプ	デフォルト	情報
ID	int	自動インクリメント	プリ
グループID	int		グループID
モジュールID	int		モジュールモジュールID
編集	int	1	編集可能
見る	int	1	閲覧可能
削除	int	1	削除可能
エクスポート	int	1	エクスポート可能

6) D_logテーブル: 各ユーザーの操作ログを記録します。

表3-6 ユーザー操作ログ

フィールド	タイプ	デフォルト	情報
ID	int	自動インクリメント	プリ
ユーザーID	int		ユーザーID
ip_addr	varchar(15)		クライアントIP
モジュールID	int		訪問したモジュールID
module_title	varchar(16)
タスク	varchar(16)		操作
作成場所	タイムスタンプ		エクスポート可能

3.3 データソース管理モジュール

DBuilder は、複数のデータソースと複数の種類のデータベースをサポートする必要があります。データソース情報は d_database テーブルに保存されます。データベース操作が頻繁な操作であることを考慮すると、データソース情報がデータベースに保存されている場合、データベース操作ごとにさらに 1 回のデータソースクエリ操作が必要となり、パフォーマンスが無駄になります。この場合、DBuilder はデータソース情報をデータベースではなくコードファイルに保存する必要があります。データソース管理情報には、データソース名 (データソースの一意の識別子、DBuilder のデフォルトのデータソース名は core)、データベースタイプ、アドレス、ポート、データベース名、ユーザー名、パスワード、その他の情報が含まれます。データソース管理モジュールはテーブルの追加、削除、変更、クエリ操作を実行しないため、データソース管理モジュールは GModule モジュールではありません。このモジュールのコードは完全に手書きです。

3.4 GModule管理モジュール

DBuilder は、GModule を生成するためのユーザーインターフェイスとして「Module」という名前の GModule を使用します。このモジュールは GModule 管理モジュールと呼ばれます。つまり、GModule 管理モジュール自体が GModule に格納されます。コアデータソースの場合、GModule の名前を「Module」に変更します。 GModule 管理モジュールには、GModule を作成、更新、削除するためのすべてのコードファイルとデータベースレコードが含まれています。 GModule の作成と削除には、グローバル GModule ルーティングを更新する必要があります。

コア CRUD モジュールは、CRUD リクエストを処理する DBuilder の実際のプロセッサです次の部分で構成されます。 1) パラメータ解析の初期化

モデルを初期化し、最初のクエリーとしてモジュールのモデルオブジェクトをインスタンス化します。モジュール構成をロードし、未設定の値にデフォルト値を設定し、パラメータを集約します。

2) フォーム

主に新規機能とアップデート機能が含まれます。 GModule メインテーブルの主キー PrimaryKey が設定されているかどうかに基づいて、それが新規操作であるか更新操作であるかを判断します。下の写真はFormモジュールの処理です

図 3-5 フォーム実行プロセス

フォームは 2 つの部分に分かれています。最初の部分では、ユーザーが入力するフォームページが表示されます。 2 番目の部分はフォームとして保存されます。

フォームページをレンダリングするときは、外部キー関係を持つフォームコントロールとフィールドを処理する方法を考慮する必要があります。フォームコントロールは、text、text_date、text_datetime、textarea、select、radio、checkbox、file、hidden、address、custom などの型をサポートする必要があり、カスタムコントロールは FormControl クラスを継承する必要があり、カスタムコントロールのレンダリングは render メソッドによって完了します。コントロールの。フォームのレンダリングでは、補助読み込みに関連するフィールドを決定する必要があります。たとえば、post テーブルを編集する場合、post テーブルには category_id というフィールドがあり、これは記事の列 ID を表し、カテゴリテーブルの id フィールドに対応します。現時点では、ユーザー入力を容易にするために、選択、ラジオ、およびチェックボックスコントロールを使用して category_id をロードする必要があります。たとえば、選択コントロールを使用する場合は、オプションの値として category.id を使用し、オプションのテキストとして category.name を使用する必要があります。これはユーザー入力を容易にするためにも行われます。この手順はリスト内の検索と共通しているため、コードを再利用できます。

フォームの保存では、一部のカスタムコントロールの保存を考慮する必要があります。カスタムコントロールの保存は、カスタムコントロールクラスの onSave メソッドによって完了します。フォームを保存するときは、リレーションシップの保存も考慮する必要があります。デフォルトでは、補助テーブルがカスケードで更新される必要があります。ユーザーが入力を完了して [保存] をクリックすると、フォームフォームには次の手順が表示されます:

モジュール構成内の関係を判断および分析し、必要なカスケード操作を実行する必要があります。
メインテーブルデータは最後に更新または作成する必要があります;
ジャンプ: 更新または新規作成が成功した場合はリストにジャンプし、失敗した場合はフォームにジャンプします。

List は、モジュール構成のフィールド構成に従ってページングデータを表示するページングテーブルです。リストの検索、並べ替え、削除の確認、エクスポートなどの機能をサポートします。

リスト検索: 検索条件としてモジュール構成で定義された検索が false に等しくないフィールドをサポートします。検索関係は論理 AND 関係です。そしてGETパラメータに反映されます。検索入力コントロールは、フィールドのフォームタイプに基づいて決定されます。フォーム内で選択、ラジオ、およびチェックボックスコントロールとして定義されたフィールドは、リスト内の入力コントロールとして選択コントロールを使用します。
;
すべての削除操作には確認が必要です。
List は、モジュール CRUD MVC への前処理/後処理インターフェイスも開く必要があります。

第4章 DBuilder システムの実装

4.1 ディレクトリ構造

コードは、フロントエンドリソース、MVC、構成、ライブラリなどの概念に従って別のディレクトリに保存されます。主要なディレクトリの説明を以下の表に示します:

表 4-2 コードのメインディレクトリ

機能

このディレクトリには、さまざまなフロントエンドリソースが保存されます。ブートストラップ、カスタム CSS ファイルおよび JS ファイルが含まれます。

リッチテキストエディター、ビデオおよびオーディオプラグインなどの特殊なフロントエンドプラグインを保存するディレクトリ。

MVC のコントローラーを格納するディレクトリ。このうち、DBuilder の中核は admin ディレクトリにあります。

MVCでモデルを保存するディレクトリ。データベースのクエリに使用されます。

MVC のビューを保存するディレクトリ。ファイル名の形式は *.blade.php です。

PHP 補助クラスと PHP ライブラリを保存するディレクトリ。

モジュール設定が保存されるディレクトリ。

4.2 GModule設定ファイル

GModule 設定ファイルは、GModule のパラメーターを定義します。このファイルは、GModule Name を蛇の形に分割して得られた文字列に基づいて名前が付けられた php ファイルです。 GModule が OrderItem の場合、GModule 設定ファイルは order_item.php になります)。構成パラメータは配列形式で返されます。

テーブルで表現される PHP 配列の美しさを考慮して、パラメーターは設定では Key=>Value の形式で、またドット形式の Key.Value で表現されます。

表 4-3 ルート構成

設定キー	タイプ	デフォルト値	意味
フィールド	配列	配列()	フィールドリスト
フィールド.フィールド名	配列	配列()	field_nameフィールドの構成
フィールド.フィールド名.ラベル	文字列	UP(フィールド名)	リストテーブルのヘッダーに表示されるコンテンツとフォームコントロールの横のコンテンツ
フィールド.フィールド名.フォーム	配列	配列()	field_nameフィールドのフォーム構成は、を参照してください。 fields.field_name.form 構成
フィールド.フィールド名.リスト	配列	配列()	field_name フィールドリストの設定については、を参照してください。 fields.field_name.list 構成
フィールド.フィールド名.関係	配列	配列()	field_name フィールドの関係

表 4-3 の各フィールドのフォーム構成の説明は、次の表に示すとおりです。

表 4-4 フィールド.フィールド名.フォームの構成

設定キー	値の型	デフォルト	意味
タイプ	文字列	テキスト	フォームコントロールタイプ
ショー	ブール	本当	フォームに表示されるかどうか
非表示	ブール	誤り	フォーム内に隠しスペースを使用するかどうか
ルール	文字列	必須	検証ルール
ajax_validate	ブール	誤り	非同期で検証するかどうか
プレースホルダー	文字列		コントロールのヒント

表 4-3 の各フィールドのリスト構成の説明は、次の表に示すとおりです。

表 4-5 フィールド.フィールド名.リストの構成

設定キー値の型デフォルト意味ショーブール本当フォームに表示されるかどうか並べ替えブール本当フィールドがソート可能かどうか、デフォルトでソート可能です検索ブール、配列配列()検索可能かどうかと検索ルール文字列コントロールのヒント

表 4-3 の各フィールドの関係構成の説明は、次の表に示すとおりです。

表 4-6 フィールド.フィールド名.関係の構成

として文字列テーブルショークエリをエスケープすることで取得した値を表すにはどのフィールドを使用する必要がありますか?これは主にメインテーブルと関連テーブルでのフィールドの重複を防ぐためです

以下は post という名前の GModule の設定ファイルです

 1 return array (
 2 'data_source' => '芯'、
 3 'テーブル' => '役職'、
 4 'フィールド' => 
 5 配列 (
 6 'id' => 
 7 配列 (
 8 'ラベル' => 「ID」、
 9 'フォーム' => 
 10 配列 (
 11 'ショー' => 本当、
 12 '非表示' => 本当、
 13 'タイプ' => '文章'、
 14 'ルール' => '必須'、
 15 'ajax_validate' => 誤り、
 16 'プレースホルダー' => ”、
 17 )、
 18 'リスト' => 
 19 配列 (
 20 'ショー' => 本当、
 21 '並べ替え' => 本当、
 22 '検索' => 「=」、
 23 'ルックアップ' => 誤り、
 24 )、
 25 '関係' => 
 26 配列 (
 27 'タイプ' => ”、
 28 'テーブル' => ”、
 29 'foreign_key' => ”、
 30 'ショー' => ”、
 31 'as' => ”、
 32 )、
 33 )、
 34 'タイトル' => 
 35 配列 (
 36 'ラベル' => 「标题」、
 37 'フォーム' => 
 38 配列 (
 39 'ショー' => 本当、
 40 '非表示' => 誤り、
 41 'タイプ' => '文章'、
 42 'ルール' => '必須'、
 43 'ajax_validate' => 誤り、
 44 'プレースホルダー' => ”、
 45 )、
 46 'リスト' => 
 47 配列 (
 48 'ショー' => 本当、
 49 '並べ替え' => 本当、
 50 '検索' => 「=」、
 51 'ルックアップ' => 誤り、
 52 )、
 53 '関係' => 
 54 配列 (
 55 'タイプ' => ”、
 56 'テーブル' => ”、
 57 'foreign_key' => ”、
 58 'ショー' => ”、
 59 'as' => ”、
 60 )、
 61 )、
 62 '短い' => 
 63 配列 (
 64 'ラベル' => '摘要',
 65 'フォーム' => 
 66 配列 (
 67 'ショー' => 本当、
 68 '非表示' => 誤り、
 69 'タイプ' => 'テキストエリア',
 70 'ルール' => '必須'、
 71 'ajax_validate' => 誤り、
 72 'プレースホルダー' => ”、
 73 )、
 74 'リスト' => 
 75 配列 (
 76 'ショー' => 本当、
 77 '並べ替え' => 本当、
 78 '検索' => 「=」、
 79 'ルックアップ' => 誤り、
 80 )、
 81 '関係' => 
 82 配列 (
 83 'タイプ' => ”、
 84 'テーブル' => 'カテゴリー'、
 85 'foreign_key' => 「ID」、
 86 'ショー' => 「ID」、
 87 'として' => ”、
 88 )、
 89 )、
 90 'コンテンツ' => 
 91 配列 (
 92 'ラベル' => '正文'、
 93 'フォーム' => 
 94 配列 (
 95 'ショー' => 本当、
 96 '非表示' => 誤り、
 97 'タイプ' => 「ウィシウィグ」、
 98 'ルール' => '必須'、
 99 'ajax_validate' => 誤り、
100 'プレースホルダー' => ”、
101 )、
102 'リスト' => 
103 配列 (
104 '表示' => 誤り、
105 '並べ替え' => 本当、
106 '検索' => 「=」、
107 'ルックアップ' => 誤り、
108 )、
109 '関係' => 
110 配列 (
111 'タイプ' => ”、
112 'テーブル' => 'カテゴリー'、
113 'foreign_key' => 「ID」、
114 '表示' => 「ID」、
115 'として' => ”、
116 )、
117 )、
118 'view_ct' => 
119 配列 (
120 'ラベル' => '次数',
121 'フォーム' => 
122 配列 (
123 '表示' => 誤り、
124 '非表示' => 誤り、
125 'タイプ' => '文章'、
126 'ルール' => '必須'、
127 'ajax_validate' => 誤り、
128 'プレースホルダー' => ”、
129 )、
130 'リスト' => 
131 配列 (
132 '表示' => 本当、
133 '並べ替え' => 本当、
134 '検索' => 「=」、
135 'ルックアップ' => 誤り、
136 )、
137 '関係' => 
138 配列 (
139 'タイプ' => ”、
140 'テーブル' => ”、
141 'foreign_key' => ”、
142 '表示' => ”、
143 'as' => ”、
144 )、
145 )、
146 'created_at' => 
147 配列 (
148 'ラベル' => '建立時間',
149 'フォーム' => 
150 配列 (
151 '表示' => 誤り、
152 '非表示' => 誤り、
153 'タイプ' => '文章'、
154 'ルール' => '必須'、
155 'ajax_validate' => 誤り、
156 'プレースホルダー' => ”、
157 )、
158 'リスト' => 
159 配列 (
160 '表示' => 誤り、
161 '並べ替え' => 本当、
162 '検索' => 「=」、
163 'ルックアップ' => 誤り、
164 )、
165 '関係' => 
166 配列 (
167 'タイプ' => ”、
168 'テーブル' => ”、
169 'foreign_key' => ”、
170 '表示' => ”、
171 'として' => ”、
172 )、
173 )、
174 'updated_at' => 
175 配列 (
176 'ラベル' => '更新時間',
177 'フォーム' => 
178 配列 (
179 '表示' => 誤り、
180 '非表示' => 誤り、
181 'タイプ' => '文章'、
182 'ルール' => '必須'、
183 'ajax_validate' => 誤り、
184 'プレースホルダー' => ”、
185 )、
186 'リスト' => 
187 配列 (
188 '表示' => 本当、
189 '並べ替え' => 本当、
190 '検索' => 「=」、
191 'ルックアップ' => 誤り、
192 )、
193 '関係' => 
194 配列 (
195 'タイプ' => ”、
196 'テーブル' => ”、
197 'foreign_key' => ”、
198 '表示' => ”、
199 'as' => ”、
200 )、
201 )、
202 'category_id' => 
203 配列 (
204 'ラベル' => '栏目'、
205 'フォーム' => 
206 配列 (
207 '表示' => 本当、
208 '非表示' => 誤り、
209 'タイプ' => '選択する'、
210 'ルール' => '必須'、
211 'ajax_validate' => 誤り、
212 'プレースホルダー' => ”、
213 )、
214 'リスト' => 
215 配列 (
216 '表示' => 本当、
217 '並べ替え' => 本当、
218 '検索' => 「=」、
219 'ルックアップ' => 誤り、
220 )、
221 '関係' => 
222 配列 (
223 'タイプ' => '属する'、
224'テーブル' => 'カテゴリー'、
225 'foreign_key' => 「ID」、
226 '表示' => 'タイトル'、
227 'as' => 'カテゴリー_タイトル',
228 )、
229 )、
230 )、
231 'list_options' => 
232 配列 (
233 'ページ' => 10、
234 '作成' => 本当、
235 '更新' => 本当、
236 '削除' => 本当、
237 )、
238 'フォームオプション' => 
239 配列 (
240 'レイアウト' => 
241 配列 (
242 'cols' => 12、
243 'label_cols' => 1、
244 'input_cols' => 11、
245 )、
246 )、
247 '関係' => 
248 配列 (
249 'id' => 
250 配列 (
251 'タイプ' => ”、
252 'テーブル' => ”、
253 'foreign_key' => ”、
254 '表示' => ”、
255 'as' => ”、
256 )、
257 'タイトル' => 
258 配列 (
259 'タイプ' => ”、
260 'テーブル' => ”、
261 'foreign_key' => ”、
262 '表示' => ”、
263 'as' => ”、
264 )、
265 '短い' => 
266 配列 (
267 'タイプ' => ”、
268 'テーブル' => ”、
269 'foreign_key' => ”、
270 '表示' => ”、
271 'as' => ”、
272 )、
273 'コンテンツ' => 
274 配列 (
275 'タイプ' => ”、
276 'テーブル' => ”、
277 'foreign_key' => ”、
278 '表示' => ”、
279 'as' => ”、
280 )、
281 'view_ct' => 
282 配列 (
283 'タイプ' => ”、
284 'テーブル' => ”、
285 'foreign_key' => ”、
286 '表示' => ”、

設定キー	値の型	デフォルト	意味
テーブル	文字列		関連付けテーブル
外部キー	文字列	ID	関連テーブルの対応するフィールド
ショー	文字列		関連付けられたテーブルのフィールド。エスケープが必要な場合、このフィールドは field_nae フィールドの代わりに表示に使用されます。