私はすでにCleverStyle CMSについて2回（1年前の前回）書いたことがあり、2回、膨大な範囲の批判とさまざまな種類のコメントの束を受け取りました-すべてのおかげで、エラーを考慮して修正するために時間をかけました。
この記事は再び開発者向けです。サイト開発にこの特定のエンジンを使用する利点をわかりやすい言葉で伝えようとします。最も重要で機能的なコンポーネントの1つであるモジュールについて説明します。
ちょっとした歴史
エンジンが1年に1人の空き時間に作成されたという事実について読んだとき、行われた作業に驚きと敬意があります。 3年前のシステムを開発するとき、これが作業の巨大な層であるかを理解しますが、さらに多くが来る可能性があります。 ほとんどの場合、独自の機能を備えたサイトの開発に出くわしました。タイトルのCMSにも関わらず、エンジンは主に開発者を支援するカーネルとして書かれていました。
モジュールの哲学
モジュールは、ページのコンテンツのレンダリングやAPIへのリクエストの処理を行うコンポーネントです。 モジュールにはすべてが含まれており、ファイルをシステムの隅に広げることはありません（したがって、記事内のパスは常にモジュールフォルダーのルートに対して示されます）。同じものを配置する必要がある場合、モジュールを削除すると、何も残さないようにすべてが削除されます。 これにより、長期間にわたってシステムパフォーマンスを適切なレベルに維持できます。
モジュールは、非常に単純（ index.htmlまたはindex.phpファイルが1 つあるフォルダー）でも、必要に応じて複雑なものでもかまいません：複数のデータベース、ファイルボルト、依存関係、外部API、多言語対応、さまざまなリソースをサポートします。 このすべてで、必要なものだけを使用し、それ以上は使用しません（最小限のテンプレートコード）。
ページ階層
モジュールには、管理、API、エンドユーザー向けのページという3つの主要な「パーツ」（任意の組み合わせ）があります。 3つの部分はすべて、1つのindex.phpファイル（または、ユーザーのページの場合はオプションでindex.html ）、またはadmin / index.json 、 api / index.jsonおよびindex.jsonで説明されているページの階層で構成できます。 第1レベルと第2レベルのページがサポートされ、残りは必要に応じて開発者によって実装されます。 次のようになります（システムモジュールの例、管理）：
{ "components" : [ "modules", "plugins", "blocks", "databases", "storages" ], "general" : [ "site_info", "system", "optimization", "appearance", "languages", "about_server" ], "users" : [ "general", "users", "groups", "permissions", "security", "mail" ] }
したがって、ページは次のようになります。
- admin / System （ admin./System/components/modulesと同様に、 index.jsonの各ネストレベルの最初の要素が選択されます ）
- 管理者/システム/一般/ about_server
- admin （システムモジュールが選択されます）
パスを処理するために、同じ名前のファイルが使用され、次の論理的な順序で実行されます。
- admin / index.php （利用可能な場合は常に実行されます）
- admin / components.php （利用可能な場合）
- admin / components / modules.php
APIがRESTを使用すると便利です。この点で、論理的で便利な方法でのAPI要求の処理は異なります。
- api / index.php
- api / index。{method} .php
- api / posts.php
- api / posts。{method} .php
したがって、異なるHTTPメソッドを使用して、異なるファイルにリクエストを送信できます。 メソッドに適切なファイルがなく、別のメソッドのファイルがある場合、論理405 Method Not Allowedが応答で到着し、 Allowヘッダーに使用可能なメソッドがリストされます。
また、リクエストを処理するとき、ページ構造を解析するときにパスの数値部分が無視されることにも注意してください（これは論理的です。数値は通常、いくつかの要素のIDまたはページ番号です）。
手動操作の場合、次のような簡単な方法で、 adminまたはapiプレフィックスなしでページパスを取得できます。
$Config = \cs\Config::instance(); $route = $Config->route; // ['components', 'modules'] , ['posts', 10] API
必要に応じて、 index.phpのみを残して、自分でルートを処理できます。
リソース（スクリプト、スタイル、画像、フォント、Webコンポーネント）
システムは、サポートされているリソースの3つの主要なタイプ、スクリプト、スタイル、Webコンポーネントを区別します。 他のすべては、ほとんどの場合、言及したものに結びついています。 それらは適切なフォルダーにあります。
- 含む/ css
- 含む/ js
- / htmlを含みます （Apache2の場合、 *。htmlファイルへのアクセスを開く.htaccessの上またはそれ以上に配置する必要があります）
対応する拡張子を持つフォルダ内のすべてのファイルは、アルファベット順でシステムによって自動的に選択されます。ファイルはサブフォルダにネストできます-これは問題ではありません。 カーネルによるフォルダーの処理を除外する場合は、 ！という名前の空のファイルを目的の場所に含めるだけで十分です（ 接続しない方法をお読みください）。
すべてがシンプルで、最も重要なのは効果的です。 事実、リソースを接続すると、カーネルはコンポーネントの依存関係を解決できます。つまり、このコンポーネントに必要なものはすべて自動的に取得されます。 さらに、管理パネルでオプションを設定すると、スクリプト、スタイル、およびWebコンポーネントが縮小され、組み合わされ（必要に応じて、Webコンポーネントに対していわゆる加硫を追加で有効にできます）、gzipで圧縮され、すべての操作がアトミックに実行されます個別のファイルにそれぞれ独立したリソースのセットがあり、圧縮された圧縮バージョンを接続するとき、依存関係のアカウンティングは保持され、ファイルは一意のプレフィックスを受け取るため、特定のリソースファイルを更新するときに圧縮バージョンの名前が変更されます それらは更新され、ブラウザのキャッシュでハングせず、問題を引き起こしませんでした。 また、画像、フォント、ネストされたスタイルのインポートへのすべての相対リンクが結果のcssファイルに埋め込まれ、HTTPリクエストの数を最小限に抑える（ユビキタスHTTP2が到着するか、最終的に決定するまで）ことは、使用されるスタイルにも当てはまりますWebコンポーネント。
特定のページのリソースを接続するために、 includes / map.jsonファイルが使用されます。これは、どのページでどのリソースが必要かを示します。 リソースがそこに示されていない場合、サイトのすべてのページで接続されます（現在のモジュールだけでなく、そのとおりです）。 次に例を示します。
{ "admin/Blogs" : [ "admin.css" ], "Blogs" : [ "general.css", "general.js" ] }
include / cssおよび同様のプレフィックスを指定する必要はありません。ファイル拡張子から、それがどこにあるかは明らかです。
Webコンポーネント
実際、それらは少し個別に言及する価値があります。 システムの中核には、 Polymer Platform （Webコンポーネントのポリファイル）とPolymer自体が付属しています。 それらをjQueryや他のいくつかのライブラリで動作させることは決して簡単なことではありませんでしたが、開発者は修正が施されたパッチをすぐに受け入れました。そのため、キットに付属しているPolymerとjQueryは、まだリリースされていないため、修正パッチを適用した後のgitバージョンです。 また、エンジンコアはjQuery.ready（）にパッチを適用して、すべてのWebコンポーネントの初期化後に実行できるようにします。
簡単に言えば、現時点で本番環境でWebコンポーネントを使用できるようにするパッチの組み合わせが他にどこにあるかはわかりません（少しうるさいですが、実際のプロジェクトでjQueryを使用してWebコンポーネントを使用しようとした場合、意味がわかります） ）
CleverStyle CMSを使用しない場合
コードはかなりモノリシックですが、特定の機能をプロジェクトで単独で使用するのは非常に簡単です（MITライセンスでこれが許可されます）。例として- スタイルとWebコンポーネントの組み合わせと縮小 （加硫のサポート）。
依存関係
モジュールは互いに依存し、プラグイン（別の種類のコンポーネント、表示用の独自のページを持たない）に依存することができます。
各モジュールは名前を持つだけでなく、特定の機能を提供することもでき、依存関係はほとんどの場合機能を正確に示します。これにより、目的の機能を提供する複数のモジュールのいずれかを選択できます（エンジンは同じ機能を提供する2番目のモジュールをインストールできません）。 また、特定のモジュール（たとえば、エンジンコアに関連付けられているシステム）の場合、目的のバージョンを制限できます。
結論として、オプションの依存関係（機能を拡張しますが、必須ではありません）を指定することができます。また、現在のモジュールに更新できるモジュールのバージョンを指定することもできます（互換性の問題があり、更新を徐々に行う必要があるか、単に古いものからアップグレードする必要があります）廃止された更新スクリプトを削除するためにバージョンが終了します）。
モジュールの詳細とその依存関係を説明するmeta.jsonメタファイルの例：
{ "package" : "Blogs", "category" : "modules", "version" : "0.097.0+build-107", "description" : "Adds blogging functionality. Comments module is required for comments functionality, Plupload or similar module is required for files uploading functionality.", "author" : "Nazar Mokrynskyi", "website" : "cleverstyle.org/cms", "license" : "MIT License", "db_support" : [ "MySQLi" ], "provide" : "blogs", "require" : "System=>0.574", "optional" : [ "Comments", "Plupload", "TinyMCE", "file_upload", "editor", "simple_editor", "inline_editor" ], "multilingual" : [ "interface", "content" ], "languages" : [ "English", "", "ї" ] }
しかし、コードはどうですか？
すべてのクラス、特性、および類似のものは、 cs名前空間にあるか、ネストされています。
クラスオートローダーは、 cs \ modules \ Blog \ PostクラスがBlogモジュールのPost.phpファイルで-単純かつ論理的に検索されるように設計されています。
システム内のイベントにサブスクライブするために（たとえば、モジュールデータが削除されたときにクリーニングする）、 トリガーが使用され、その宣言はほとんどの場合、表示されたモジュールに関係なく各ページで呼び出され、これらの目的のために特に使用されるtrigger.phpファイルにあります。
私はコード例を書いているわけではありません。多くのスペースを必要としますが、この記事では具体的な例よりもアーキテクチャと作業の原理について詳しく説明しています。
まとめ
これは、モジュールが何であるか、どのように設計されているか、そしてなぜ正確であるかについて簡潔に説明しています。 書かれていることから、システムが多くの明白で有用なことを行うことは明らかであることを願っていますが、同時に開発者が動作を変更できるようにします（例として、ページアドレスを手動で処理し、リソースを接続する機能について言及しました）。 これは網羅的な情報ではなく、より狭い使用シナリオをカバーするため、単純なものは省略されていますが、興味がある場合は、より具体的な詳細を説明し続けます。
計画
最近、エンジンは大幅にリファクタリングされ、3年ぶりのリリースであるバージョン1.0がリリースされます。
これに関して、私はより多くのフィードバックを得たいと思います。
現時点では、テストの欠如について最も懸念しています（いくつかの既存のテストは考慮されていません）。 最近の変更では、コードのテスト容易性を改善するための手段が講じられていますが、テストに関する問題はまだ追加されていません。この分野で私は非常に喜んでいます（DIを提供する必要はありません）。
それだけです。このライブを見ることへの興味をかき立てることができたらいいのですが。 コードはほとんどすべての場所でPhpDocコメントで覆われていますが、これはIDEで非常によく取り上げられており、エンジンリポジトリで既製のモジュールを見ることができる例と同じです。
GitHubのプロジェクトページには、ドキュメント付きのWikiもあります（主にバックエンドにあります）。
デモ
彼らはデモを求めたコメントで、ここにあります（Nginx + HHVM）：
http://demo.cscms.org
管理者：1111