Magic3フレームワークの基本方針

オープンソースCMS?「Magic3」は、独自のフレームワークである「Magic3フレームワーク」を基盤としています。
世の中にフレームワークというものは無数にありますが、フレームワーク上に乗るアプリケーションやミドルウェア等の
ソフトウェアはフレームワークに制約され、動作の型が決定してしまいます。
したがって、斬新なるCMS?を作るには、その土台として、上位が必要とすることが実現できるフレームワークが必要になります。
Webサイトの自由自在なる表現を実現する「Magic3」は、まったく今までにないCMS?です。
その土台を実現するために、既存フレームワークにない斬新なアイデアを「Magic3フレームワーク」として構築しました。
Magic3フレームワークでは、基本思想?に基づいてより具体的な方針を定めています。
Magic3自体が前衛的であり、時代を先取りしたソフトウェアであるため、基本方針自体も今までにないフレームワークの考え方、
これから普及していくあろう概念となっています。

設定ファイルレス

Magic3には、設定ファイルがありません。その代わりにDBを必須とした、DB組み込み型 フレームワークです。
設定はどのような形式の値であれ、すべてDBに格納します。
DBに格納することは、フラットファイルでの管理よりも数倍、管理性が高くなります。
設定ファイルがサイトのどこかにころがったままというのはあまりよい考えではありません。
システムとして、設定(設定ファイル)自体の管理を行うというのがMagic3フレームワークの考え方です。
設定をプログラムから外出しするという考え方は、Webアプリケーションがごく小さかったWebの初期のころには有効でしたが、
規模が大きくなるにつれて設定ファイルが大きくなりすぎる問題として上がってきました。(例えば、struts-config.xmlの問題等)
しかし、それに対する根本的な解決がないまま、ごまかしごまかし対症療法で対処してきました。
それに拍車をかけるのが、はやりの「DIコンテナ」という考えです。
「DIコンテナ」という考え方は、設定の外出しの考え方をオブジェクトの生成まで押し広げた考え方です。
その結果、Webアプリケーションには大量の設定ファイルが必要になりました。
もともと、設定ファイルで自由にカスタマイズできるという目的が、設定ファイルの山の中で「設定の管理」が不能になっています。
「設定」が管理不能であるのに、システム全体の管理ができるわけがありません。
DB化するなど、「設定」自体を管理する機能が必要になっています。
Webサイトが巨大化する一方である以上、いずれはDBによって設定を管理するという考え方が一般化すると思われます。

DB組み込み型

先の理由により、Magic3はDBが必須になります。
ただ単に設定ファイルをなくすだけが目的ではなく、すべてのデータをDBに格納して扱うことにより、
(DBの仕組み上)ある程度データの形式が整い、管理しやすくなるのも利点です。

ビュー生成重視

Webアプリケーションにとって、Webブラウザでの画面表示つまり、ブラウザに表示するデータの作成こそが命です。
したがって、自由度の高い画面(ビュー)生成がもっとも最優先すべき項目です。
ビュー生成に制約があることは、そのまま、構築可能なWebアプリケーションの限界になってしまいます。
Magic3は、画面生成(ビュー生成)に最大限の自由度を持たせ、かつ管理性が高い、相反する条件を実現しています。

Magic3にとってのビューとなる要素は、テンプレートウィジェットの出力です。
テンプレートは、Webサイトの統一的なデザインイメージや、基本的なレイアウトを維持するものです。
テンプレートが全体の大枠のビューを形成するのに対して、ウィジェットは個別の領域ごとの細かいビューを作成します。
個別領域のビューを管理するウィジェットのしくみは、Ajaxなどで動的な動きをする最新のWeb技術に特にマッチした方法です。
(画面の生成方法)

互換性の維持

フレームワークのバージョンが上がると、今まで使用していたコンポーネント部品が使えなくなるというのでは、
何のためのバージョンアップかということになります。
互換性を最大限維持するために、Magic3では、機能コンポーネント部品である「ウィジェット」と土台部分であるフレームワークとの
インターフェイスは、非常にシンプルなインターフェイスで連携する仕組みになっています。(ウィジェット作成基準)