CRUDジェネレーターDBuilderの設計と実装

ソース コードは 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 要件分析

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

1)

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

2)

コード生成

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

3)

データベース

テーブルCRUD

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

4)

メニュー管理

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

5)

ユーザー管理

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

6)

権限管理

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 を使用するユーザーを示します。
ユーザー グループ: ユーザーのタイプ グループを表します。ユーザー タイプには、ゲスト、管理者、スーパー管理者の少なくとも 3 つのタイプが含まれている必要があります。
• データ ソース: DBuilder に含まれるデータベース構成を表します。データ ソースの構成には、データベースに接続するために必要な基本パラメーターが含まれます。
コード モジュール: DBuilder によって生成されたコード モジュールを表し、コード ファイルと構成を記述します。
• Menu: DBuilder の左側のメニュー項目を表します。
権限: 各コードモジュールに対するユーザーグループのさまざまな操作権限を示します。
• Log: 各コードモジュールに対するユーザーの CRUD アクセスログを表します。
エンティティと関係の ER 図は次のとおりです:

図 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 構成) も持ちます。
各 GModule は、メイン テーブルとしてのデータベース テーブルと、CRUD 関数を備えたコード ファイルのコレクション (対応する MVC + 構成コードを含む) を表します
• 。たとえば、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 配列の形式で定義されます。これには、すべてのフィールドのフォーム、リスト、ビュー、リレーションシップなどのパラメーターの構成と、グローバル パラメーターの構成が含まれます。
GModule は特定のモジュールを表すのではなく、DBuilder によって生成されるか、開発者によって手動で作成されるモジュールのタイプを指します。主にコア CRUD モジュールのインターフェースを実装するために使用され、主に次の部分が含まれます
1) コントローラーインターフェイス
GModule モジュールのコントローラーが A、コア CRUD モジュールのコントローラーが B であるとすると、A は B を継承する必要があります。 CRUD リクエストは最初に A にルーティングされ、実際のハンドラーは B になります。 A は、B によって開かれた次のインターフェイスを実装します。
beforeListExcuteQuery(&querier): このインターフェイスは、List クエリがクエリを実行する前に呼び出され、渡されるパラメータはクエリ参照です。クエリを実行する前に特別なクエリ パラメータをバインドするために使用されます。
beforeList(&data): このインターフェイスは、リスト クエリが実行された後、リスト ビューがレンダリングされる前に呼び出されます。渡されるパラメーターはビュー パラメーター参照であり、クエリされたモデル コレクションが含まれます。これは、クエリされたモデル コレクションに対して後処理を実行するか、モジュール固有のパラメーターをリスト ビューにバインドするために使用されます。
beforeEditExcuteQuery(&querier): このインターフェイスは、モデル ククエリーが編集リクエストでクエリを実行する前に呼び出され、クエリー参照を渡します。モデルのクエリに必要な特別なパラメーターをバインドするために使用されます。
beforeEdit(&data): このインターフェイスは、Edit の Model クエリが実行された後、ビューがレンダリングされる前に呼び出され、クエリによってクエリされたモデルを含むビュー パラメーター参照が渡されます。レンダリング前の前処理に使用されます。
afterSave(&model): このインターフェイスは、Edit で編集を保存した後に呼び出されます。渡されるのはデータベースに保存されたモデルであり、最新のデータベース レコードが保持されます。モデルに対して複雑なポストカスケード処理を実行するために使用されます。
beforeView(data): このインターフェイスは、View リクエストで View クエリがクエリされ、ビュー パラメータの参照が渡された後に呼び出されます。ビュー表示の前処理に使用されます。
2) モデルインターフェース
GModule MVC コードのモデルも BaseModel から継承しており、BaseModel クラスによって開かれるいくつかのインターフェイスを実装することで拡張できます。
formatXXXAttribute(): このインターフェースは、特定のフィールドをフォーマットするために使用されます。この製品は Laravel に基づいていますが、Laravel には getXXXXAttribute() という同様のインターフェイスがすでにあります。ただし、このようなインターフェースの優先度はフィールドの優先度よりも高く、特殊なケースでは開発に不都合が生じるため、同様のインターフェースはフィールド自体の優先度よりも低い優先度で設計されます。
3) ビューインターフェイス
ビューの拡張インターフェイスは前の 2 つとは異なり、主にサブビューとビュー ブロックに反映されます。つまり、コア CURD モジュールのビューに基づいて、ビュー コンポーネントが拡張されます。デフォルトでは、Core CRUD MVC ビューは、ページを満たすテーブルまたはフォームを生成します。 View インターフェイスでは、ページ コンポーネントをテーブル上で上下左右に展開する機能が提供されます。
4) 構成
各 GModule は、メイン テーブルの各フィールドの GModule の設定パラメータとレイアウト パラメータを含む設定ファイルに対応します。
3.1.3 モジュール関係
CRUD リクエストは GModule のコントローラーにルーティングされます。GModule コードは Core CRUD MVC のオープン インターフェイスを実装し、Core CRUD モジュールは実際にデータベース上で CRUD 操作を実装します。 GModule に関連するメニュー、制御権限、操作ログの記録などを与えるために、各 GModule の情報をデータベース テーブルに記録する必要があります。いくつかの主要なモジュール間の関係を次の図に示します。



図 3-2 モジュールの関係
図 2-2 からわかるように、GModule 管理モジュールはユーザー設定に基づいて GModule A を生成し、ユーザーの CRUD リクエストが GModule A に到達すると、GModule はリクエストを処理のために Core CRUD に転送し、Core CRUD モジュールに転送します。次に、SQL を使用してデータベースに対して CRUD 操作を実行します。

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,

)、

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

);

コア データ ソースには次のデータ テーブルがあります:
1) d_menu テーブル: 背景の左側にあるツリー メニューを表し、クリックしてジャンプできる各メニュー項目はモジュールに関連付けられている必要があります。
表 3-1 Web バックエンドの左側のメニュー表

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 ルーティングを更新する必要があります。

1) Gモジュールルーティング
GModule ルートは、別のコード ファイルで定義されます。これは、GModule 名をマイナス記号で区切ってキーとしてすべて小文字にした文字列です (例: GModule 名が OrderItem の場合、キー値は order-item です)。モジュール内のコントローラーを使用する クラスのクラス名は値のマップ辞書であり、GModule ルーティングはグローバルです。
2) 新規および更新された GModule
新しい GModule を作成すると、データベースにレコードが生成され、すべてのモジュール ファイルが生成され、ルートが更新されます。更新操作では構成ファイルのみが変更されます。新規作成と更新の両方で、GModule 構成のグラフィカル構成インターフェイスである同じ編集ビューを使用します。
3) Gモジュールの削除
GModule を削除すると、すべての GModule MVC コードが削除され、GModule 設定コードが削除され、データベース テーブル レコードが削除され、GModule ルーティングが更新されます。
3.5コアCRUDモジュール

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

フィールドで構成された検証ルールに従って検証します。
• モジュール構成内の関係を判断および分析し、必要なカスケード操作を実行する必要があります。
そしてカスタム コントロールの onSave メソッドを呼び出します。
• メインテーブルデータは最後に更新または作成する必要があります;
• ジャンプ: 更新または新規作成が成功した場合はリストにジャンプし、失敗した場合はフォームにジャンプします。
フォームは、対応する前処理インターフェイスと後処理インターフェイスを開く必要もあります。
3) リストリスト（表）

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

ページ表示データは、InitQuerierモジュールで取得したモデルをクエリーとして使用し、ページングと組み合わせて、基本データリストをクエリします。ページング タイプはフル ページ リフレッシュ タイプ (非同期ページング) です。
• リスト検索: 検索条件としてモジュール構成で定義された検索が false に等しくないフィールドをサポートします。検索関係は論理 AND 関係です。そしてGETパラメータに反映されます。検索入力コントロールは、フィールドのフォーム タイプに基づいて決定されます。フォーム内で選択、ラジオ、およびチェックボックス コントロールとして定義されたフィールドは、リスト内の入力コントロールとして選択コントロールを使用します。
リストの並べ替え: モジュール設定で定義された form.sort が false に等しくないフィールドは、並べ替え可能なフィールドとして使用されます。並べ替えは 1 つのフィールドによる並べ替えのみをサポートしており、降順には昇順と降順が含まれます
• ;
リストの複数選択操作は、主に複数選択の削除操作と複数選択のコピー操作をサポートします。
• すべての削除操作には確認が必要です。
リスト データ レコードの各行でサポートされる操作は、モジュール構成の構成に従って指定されます。デフォルトでは、編集、削除、表示の 3 つの操作がサポートされます。
• List は、モジュール CRUD MVC への前処理/後処理インターフェイスも開く必要があります。
4) ビュービュー
View は一時的に Form に基づいており、前処理および後処理インターフェイスを提供しますが、編集はできません。

第4章 DBuilder システムの実装

4.1 ディレクトリ構造

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

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

目次資産プラグインアプリ/コントローラー/管理者アプリ/モデルアプリ/ビューアプリ/ライブラリapp/config/crud

機能

このディレクトリには、さまざまなフロントエンド リソースが保存されます。ブートストラップ、カスタム 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 フィールドの代わりに表示に使用されます。

声明：

この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

前の記事：PHP 読書メモ (5) - 構造ステートメント次の記事：PHP 読書メモ (5) - 構造ステートメント

関連記事

続きを見る

• Windows7系统下Netbeans+PHPUnit搭建PHP单元测试开发环境及PHPUn
• 程序猿ProMonkey V2.03
• PHP Navigator
• php返回数组中指定的一列（php5.5.0默认函数array_column()在php
• htmlentities和htmlspecialchars 的区别详解

• ホームページ

• コース

• に質問

• 私の

• ホームページ
• コース
• 記事
• に質問
• 辞書
• マニュアル
• ダウンロード
• 特集

ホームページ

記事

に質問

コース

特集

ダウンロード

ゲーム

辞書

简体中文（ZH-CN）English（EN）繁体中文（ZH-TW）日本語（JA）한국어（KO）Melayu（MS）Français（FR）Deutsch（DE）