CMFまたはZend + Doctrineに苦しんでいます。 パート1

独自のシステムを作成する試みはかなり前に始まりました(これは誰もが知っていると思います)。 過去数年にわたって、システムの回路はロールバックされましたが、システム自体は安全にボーズに置かれました。 何らかの形でZendをコンポーネントとして使用しようとする試みがあった場合、最終的には、ホイールを再発明するのではなく、単にZendを基盤として採用することにしました。

Zend-1.8 / Doctrine-1.1執筆時点。



以前のバージョンからシステムに保持することを決定したもの

1)マルチサイト

2)多言語。 国際化はZendとDoctrineを介して行われます。

3)モジュール性。 同時に、yamlスキームを指定し、コントローラーと自動生成フォーム(Zend_Form)を操作するための標準メソッドを取得することにより、システム自体にモジュールを作成できます。

4)作成されたモジュールでは、デフォルトでi18n、バージョン管理可能、タイムスタンプ可能のサポートがあります。

各サイトには、バックエンド、フロントエンドなどの表示モードがあります。 モデルはすべてのものです。 モデルの基礎はDoctrineです。 とても快適に思えた。



したがって、アプリケーション回路は次のようになりました。

/application

--->/backend

------>/helpers

------>/languages

------>/layouts

------>/modules

--->/frontend

--->/installer

/models

/tests

/library

--->/Xms

--->/Xms/Core

--->/Xms/Backend

--->/Xms/Frontend

--->/Zend

--->/Doctrine







アプリケーションが起動すると、どのモードで起動したかが決定され、その後Boostrapが起動します。 デフォルトで/ applicationにあるものを使用できます。 (インストーラーの場合のように)独自に決定できます。

アプリケーションの起動

$application = new Xms_Application ( <br/>

APPLICATION_ENV , <br/>

array ( 'config' => XMS_ROOT . '/config/application.ini' , <br/>

'mode' => 'backend' ) <br/>

) ; <br/>

$application -> setBootstrap ( APPLICATION_PATH . '/Bootstrap.php' ) ; <br/>

$application -> bootstrap ( ) -> run ( ) ;





$application = new Xms_Application ( <br/>

APPLICATION_ENV , <br/>

array ( 'config' => XMS_ROOT . '/config/application.ini' , <br/>

'mode' => 'backend' ) <br/>

) ; <br/>

$application -> setBootstrap ( APPLICATION_PATH . '/Bootstrap.php' ) ; <br/>

$application -> bootstrap ( ) -> run ( ) ;









Xms_Applicationクラスが初期化されます

require_once 'Zend/Loader/Autoloader.php' ; <br/>

require_once ( 'Doctrine.php' ) ; <br/>

Zend_Loader_Autoloader :: getInstance ( ) <br/>

-> pushAutoloader ( array ( 'Doctrine' , 'autoload' ) ) ; <br/>

Zend_Loader_Autoloader :: getInstance ( ) -> registerNamespace ( 'Xms_' ) ; <br/>

Zend_Loader_Autoloader :: getInstance ( ) -> registerNamespace ( 'Scienta_' ) ;





require_once 'Zend/Loader/Autoloader.php' ; <br/>

require_once ( 'Doctrine.php' ) ; <br/>

Zend_Loader_Autoloader :: getInstance ( ) <br/>

-> pushAutoloader ( array ( 'Doctrine' , 'autoload' ) ) ; <br/>

Zend_Loader_Autoloader :: getInstance ( ) -> registerNamespace ( 'Xms_' ) ; <br/>

Zend_Loader_Autoloader :: getInstance ( ) -> registerNamespace ( 'Scienta_' ) ;









BootstrapクラスはXms_Core_Abstractから継承され、Xms_Core_AbstractはZend_Application_Bootstrap_Bootstrapから継承されます。 実行方法:

$this -> _readConfig ( ) ; <br/>

$this -> _setDb ( ) ; <br/>

$this -> _setEnvironment ( ) ; <br/>

$this -> _setLayout ( ) ; <br/>

$this -> _setSystem ( ) ; <br/>

$this -> _setSecurity ( ) ; <br/>

<br/>

Zend_Registry :: set ( 'Xms_Bo' , $this ) ; <br/>

parent :: run ( ) ;





$this -> _readConfig ( ) ; <br/>

$this -> _setDb ( ) ; <br/>

$this -> _setEnvironment ( ) ; <br/>

$this -> _setLayout ( ) ; <br/>

$this -> _setSystem ( ) ; <br/>

$this -> _setSecurity ( ) ; <br/>

<br/>

Zend_Registry :: set ( 'Xms_Bo' , $this ) ; <br/>

parent :: run ( ) ;







メソッド_setEnvironment()、_ setSystem()、_ setSecurity()についてもう少し

_setEnvironment()

protected function _setEnvironment ( ) <br/>

{ <br/>

Doctrine :: loadModels ( array ( <br/>

XMS_ROOT . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: APPLICATION_FOLDER . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: MODELS_FOLDER . DIRECTORY_SEPARATOR . 'core' . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: MODELS_FOLDER_GENERATED , <br/>

XMS_ROOT . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: APPLICATION_FOLDER . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: MODELS_FOLDER . DIRECTORY_SEPARATOR . 'core' <br/>

) <br/>

) ; <br/>

$this -> _defineUri ( ) ; <br/>

$this -> _loadModes ( ) ; <br/>

$this -> _loadSites ( ) ; <br/>

$this -> _loadModules ( ) ; <br/>

$this -> _loadLanguages ( ) ; <br/>

$this -> _loadRouters ( ) ; <br/>

}





protected function _setEnvironment ( ) <br/>

{ <br/>

Doctrine :: loadModels ( array ( <br/>

XMS_ROOT . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: APPLICATION_FOLDER . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: MODELS_FOLDER . DIRECTORY_SEPARATOR . 'core' . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: MODELS_FOLDER_GENERATED , <br/>

XMS_ROOT . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: APPLICATION_FOLDER . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: MODELS_FOLDER . DIRECTORY_SEPARATOR . 'core' <br/>

) <br/>

) ; <br/>

$this -> _defineUri ( ) ; <br/>

$this -> _loadModes ( ) ; <br/>

$this -> _loadSites ( ) ; <br/>

$this -> _loadModules ( ) ; <br/>

$this -> _loadLanguages ( ) ; <br/>

$this -> _loadRouters ( ) ; <br/>

}







ここで、アプリケーションが初期化されます-利用可能なモード、サイト、モジュール、ロケール、ルーターの読み込み。



_setSystem()

foreach ( $this -> _moduleMatrix as $key => $val ) { <br/>

$front -> addControllerDirectory ( XMS_ROOT . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: APPLICATION_FOLDER . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: APPLICATION_EXT . DIRECTORY_SEPARATOR . <br/>

$this -> _mode . DIRECTORY_SEPARATOR . Xms_Application :: MODULES_FOLDER . DIRECTORY_SEPARATOR . $key , $key ) ; <br/>

}





foreach ( $this -> _moduleMatrix as $key => $val ) { <br/>

$front -> addControllerDirectory ( XMS_ROOT . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: APPLICATION_FOLDER . DIRECTORY_SEPARATOR . <br/>

Xms_Application :: APPLICATION_EXT . DIRECTORY_SEPARATOR . <br/>

$this -> _mode . DIRECTORY_SEPARATOR . Xms_Application :: MODULES_FOLDER . DIRECTORY_SEPARATOR . $key , $key ) ; <br/>

}







モジュールのインストールは次のとおりです。 つまり、起動したサイトと接続していないモジュールは使用できません。



_setSecurity()

$this -> _acl = new Xms_Core_Acl ( $this -> _siteId , $this -> _modeId ) ; <br/>

$front -> registerPlugin ( new Xms_Core_Controller_Plugin_auth ( Zend_Auth :: getInstance ( ) , $this -> _acl ) ) ;





$this -> _acl = new Xms_Core_Acl ( $this -> _siteId , $this -> _modeId ) ; <br/>

$front -> registerPlugin ( new Xms_Core_Controller_Plugin_auth ( Zend_Auth :: getInstance ( ) , $this -> _acl ) ) ;









アクセス権の差別化の観点から、最終的なリソースはZend_Actionではなくコントローラー自体であるという事実に焦点を当てることにしました。 さて、コントローラーに新しいアクションが追加される状況(同じAJAXを使用する可能性が高い)と、ロールを変更して新しいアクションにアクセス権を付与する手順を想像してください:)



教義

これが、Doctrine_Templateについて特にDoctrine開発者に感謝する理由です。

タスク:デフォルトで、テーブルはDoctrine_I18n、Versionable、SoftDelete、およびTimestampableのサポートで作成されます。 問題がありました-trac.doctrine-project.org/ticket/1708 。 不要な参照の継承と削除は、これからすぐに逃れることができました。 さらに、各エントリはユーザーとサイトに属していることも特徴です。



私たちが今持っているもの。

1)インストーラーモード。 システムのインストール。

2)バックエンドモード。 モジュールを追加すると、テーブル、コントローラー、およびフォームが作成されます。

3)フロントエンドモードはまだ初期段階です。 Action_Stackを使用して、このページに接続されているモジュールに従ってページを形成すると考えられています。



アクションへのアクセス権を区切るのに加えて、システムはデータに対する権利を区切る必要があります。 コントローラーリソースへのアクセスに加えて、ロールはデータスライスにもアクセスできます。 スライスは、テーブルの各フィールドへのアクセスに基づいて形成されます。



Zend_Projectを使用して新しいモードを生成したい-opensocialモード(code.google.com/intl/en/apis/opensocialをサポートするソーシャルプログラム)、office(スキーマはyamlから生成できるため、テーブルを作成するためのグラフィカルツールを提供しない) 、jquery-gridなど。

プロセスがシステムを起動するようにDoctrine_Eventを検討します。 つまり、誰かが作成した設定-テーブルAにエントリを追加するときに、テーブルBにエントリを追加し、電子メールを送信する必要があります。



ここでは、何が起こったのかを簡単に説明しようとしています。 経験を積んだメモを寄せてくれたhabrausersに感謝します-それは、車輪の再発明に興味があるだけではないことを意味します:)

コードはOpenSourceでレイアウトされる予定であるため、誰かが興味を持っているなら、Wellcomeの見た目になるでしょう。



All Articles