👈 🐾 🚧 Symfony CMF パート1、データストレージ 💃🏼 🎰 🚨

序文の代わりに

私は2年間Yiiでプログラミングをしており、最近Symfonyフレームワーク2を見つめ始めました。一部、よく考え抜かれたアーキテクチャ、コンポーネントの弱い接続性、ビルドされたアプリケーションの柔軟性に魅了されています。新しいフレームワークのメインデバイスを見つけた直後、その上にCMSを構築することは可能か、完成したものを使用することさえ可能だろうかと考えました。

ボックスソリューションはまだ発明されていませんが、どういうわけか私はSymfony CMFプロジェクトのWebサイトをさまようと、Drupalの設計を引き出すために組立ラインで作業していたときに遭遇した問題を解決するための体系的なアプローチにその場でぶつかりました。 Habréには、CMFに関する出版物はなく、プロジェクト自体はまだ非常に粗雑ですが、将来はすべてがおもしろそうに見えますが、場所によっては不満があります。

symfony cmf

Symfony CMFプロジェクトは、Symfony Framework 2を使用するすべての人のCMSに固有の機能の開発を簡素化するように設計されています。

プロジェクトの主な機能：

コンポーネントの接続性が悪い
拡張性
便利さ
テスタビリティ

CMFという言葉に注目する価値があります-プロジェクト自体はCMSではなく、 フレームワークです。すべてのコンポーネントが互いに密接に結び付けられているCMSとは異なり、Symfony CMFでは次のことができます。

好きなものを使う
気に入らないものを置き換える
不要なものを無視する

つまり、ターンキーターンキーアプリケーションではなく、一連のモジュール式開発ツールが提供されていますが、CMS機能を提供する基本的なバンドルはすでに開発されています。

なぜ別のCMFなのか？

有料（1C-Bitrix、UMI）と無料（Drupal、MODx、Wordpress、Joomla）の両方の既製品が市場に出回っているのは秘密ではありません。したがって、 CMS / CMFの碑文を見ると、疑問が生じるのは当然です。なぜ別のCMSを作成する必要があるのですか？ 彼らはすでにとてもいっぱいです。

そして、私は絶対に同意します。ユーザーとして。

CMSは本当に1ダースです。しかし、開発者として、私はしばしば汗、血、涙を流し、それらからもっと何かを得ようとしました。それは基本システムとサードパーティの拡張機能の作者によって定められたものではありませんでした。

十分に考えられていないアーキテクチャのため、既成のソリューションを使用する場合、次のことに対処する必要があります。

ロジック、構成、コンテンツ、およびプレゼンテーションの明確な分離の欠如。 Drupalモジュールを思い出すのに十分です-ファイルの束、理解できないグローバル関数のハッシュ、フックなど。ところで、この問題を議論する良い記事
古いバージョンからの多くのレガシーコードが残っています。開発者は時々これを修正しようと試み、カーネルやその他の喜びを書き直すことを約束しますが、新しい（書き直された）バージョンが「使用可能」段階に達するまで、多くの時間が経過します。
多くの場合、システムには開発、テストなどの概念はなく、展開用のツールもありません
キャッシングの問題。どこかにない、どこかにあるが、十分な柔軟性を提供していない、障害に問題がある、または単に保存しないなど
大規模（この場合は相対的な用語）データボリュームでの低パフォーマンス
独自のコンポーネントの作成や既存のコンポーネントのオーバーライドが困難
事前定義されたデータ型から選択する必要があります。リレーショナルDBMSの上にEAVリポジトリがあるか、さらに悪い
CMSの作者が発明した不快なテンプレートバイク...
...そしてこれはすべてNIH症候群の結果として。

これらのシステムの開発者は欠点を認識しており、申し立てを拒否しませんが、現時点ではこれらすべての問題を解決することは不可能です。しかし、私たちはまったく誓いません。ユーザーの利便性のためにCMSが解決すべき多くの問題を定式化し、Symfony CMFでこれらの問題がどのように解決されるかを確認します。問題は次のとおりです。

データストレージ
テンプレートシステム
ルーティング、CNC、およびユーザーがこれをすべて制御する方法
メニュー設定
コンテンツ管理（ページ上の編集可能なブロック、ライブサイトでのフロントエンド編集、ファイルのアップロード）
国際化
良い管理者

問題から始めましょう。

データストレージの問題

CMSの概念の実際の解釈に基づいて、CMSの最も重要なコンポーネントはデータストレージであることが明らかになります。さらに-CMSは、異なるプロパティを持つデータストレージを提供する必要があります 。たとえば、BlogPostやNewsItemなどの資料の場合、共通のtitle

フィールドとbody

フィールドを作成できます。そうすると、違いが生じます。ニュースに写真を添付する必要がある場合があります。

オンラインストアを想像してください。データベースには何が保存されていますか？少なくとも、製品の説明と注文履歴。 1つ目とは異なり、2つ目のストレージスキームを設計する方がはるかに簡単ですが、両者なしでは両方が存在できないことは明らかです。したがって、次の要件： CMSは、CMS内とシステムの他の部分の両方のコンテンツにリンクできる必要があります 。

サイト上のコンテンツ自体は、ほとんどの場合、ファイルシステムを幾分繰り返すツリー構造の形式で編成されています。サイトの作成者は同時に、ニーズに応じてさまざまな方法でコンテンツを整理し、メニューや資料のアドレスを柔軟に構成したいと考えています。したがって、 CMSはデータをツリー構造で提示 し、同時に複数の独立したツリーに対応できる必要があります。

ユーザーがCMSで詰まらせる情報が、理想的な構造になっていることはほとんどありません。場合によっては、1つ、別の、3番目、10番目のフィールドを追加する必要がある場合があります。CMSは、コンテンツに対して単一のスキームの使用を強制するべきではありません 。

大規模な組織では、ワンクリックで公開するのではなく、サイトに表示される前にいくつかの検証段階を経ることが珍しくありません。CMS はツリー間のコンテンツの移動とエクスポートをサポートする必要があります。そして、物語のために、いつでも復元できるコンテンツのバージョンを保持しておくといいでしょう。

他の国や地域のユーザーについて覚えておく価値があります。通常、Webサイト全体を別の言語に翻訳する必要はありませんが、 CMSは、異なる言語でコンテンツを表示する機能を提供し、指定されたルールに従ってオプションのフォールバックを提供する必要があります 。

コンテンツが多すぎる場合は、 全文検索 、 サブツリーへのアクセスを制御するためのルールを決定する機能、および複数の作成者によるドキュメントの公開プロセスの支援が必要になります（ワークフローはすべてのユーザーで異なります）。

コンテンツリポジトリ

1つの「筋肉」を取り除くことができないことが明らかになります。リレーショナルデータベースは単純にそのようなタスクに対処できませんが、グラフ構造をフラットデータベースに格納できるマテリアライズドパスやネストセットなどのアルゴリズムがあります。しかし、単一の実装が機能する場合でも、特定のエンジンに厳密に結び付けられている可能性が高く、これはすでに私たちの自由と柔軟性を奪っているので、すでに悪いことです。 RDBMSを非難する必要はありません-それらは完全に異なるタスクのために設計されており、弱く構造化された要素で構成されるツリーではなく、明確に記述されたデータが必要です。

ただし、動揺することはありません。結局、ブルジョア語を音訳すると、コンテンツリポジトリ、またはコンテンツリポジトリを長い間考えてきました。リポジトリは、データを必要とするアプリケーションに関係なく、データの読み取り、書き込み、および取得にアクセスできるように設計されています。実際、これは主にデータ処理の論理的な側面に重点を置いたデータウェアハウスです。

JCR-170

ドキュメント指向システムのデータストレージの問題は何年も前に発生したため、2000年代前半に、Day Software（つまりDavidNüscheler）の人々がJava Community Processを介してJavaのContent Repository API（JCR）仕様を受け入れる要求を提出しました。その後、仕様は番号JSR-283（2.0）、JSR-333（2.1、最終ドラフトは8月31日に完成）で行われましたが、これまでは最初のオプションへのリンクがより一般的でした。

仕様によれば、リポジトリは、階層データの保存、検索、検索を提供するオブジェクトデータベースです。さらに、提供されているAPIを使用すると、データのバージョン管理、トランザクション、変更の追跡、XMLでのインポート/エクスポート、およびバイナリとメタデータの保存を使用できます。

このようなリポジトリは、プロパティを持つノードのツリーとして編成されます。データはそれらに直接格納され、数値、文字列、または任意の長さのバイナリデータにすることができます。ノードは、タイプに細分化され、子ノード、特定の動作特性、または単純に隣接ノードを参照できます（特別なプロパティと各ノードが持つ一意の識別子を使用）。

仕様の2番目のバージョンから、リポジトリはSQLクエリに応答できるようになります。これは、最初のエディションのXPathの対応よりも便利です。

そのような幸福の実現の鮮やかな例として、Javaで書かれたオープンソースのリポジトリであるApache Jackrabbitプロジェクトを選び出すことができます。上記のすべての利点に加えて、このプロジェクト（2004年にJCR APIの初期実装として始まった）は、コンテンツへのアクセスを柔軟に制御できます。クラスタリング、ロックメカニズムなどもありますが、今はあまり面白くないのでスキップしてください。

PHPCR

しかし、誰もがJavaで書くわけではありません！（このテーマに関するジョークを省略します）

私たちのような人のために、PHPのコンテンツリポジトリが作成されました-上記のJCR APIは、PHPのスタイルに適合しています。 APIが同じで適切に指定されているという事実に基づいて、次のようになります。アプリケーションを1回作成してから、バックエンドを変更するだけです（もちろん、理論的には）。

重要なプラス-私たちは自転車を発明しません（覚えているように、CMSのデータストレージの問題は既に解決されているため）。

もちろん、そのようなイニシアチブは見過ごされることはありませんでした-デビッドは、 JCR 2.1でのPHPCRの採用のリクエストを送信しました。とてもいい。

APIをJavaからPHPに移植して移植することはできないため、実装にはまだ違いがあります。要するに、これはPHPの型指定が弱く、メソッドのオーバーロードをサポートしていないという事実によるものです。そのため、一部のインターフェイスと関数は単純に不要なものとして破棄され、オーバーロードが発生した場合、メソッドはオプションの引数を追加しました。違いはここで詳細に説明されていますが、そこにひどいものは何もありません。

現在、PHPCRは次の機能をサポートしています。

ツリーアクセス
UUIDによるノードへのアクセス
ノードで検索
バージョニング
機会の特定
XMLへのインポートとエクスポート
ロック
トランザクション*
許可
アクセス制御*
変更追跡

（*）-Jackalope-Jackrabbitではまだ実装されていません（詳細は以下を参照）。ただし、情報は少し古くなっている可能性があります。

PHPCRの主要な概念 ：

すべてのコンテンツはノードツリーに格納されます
ノードには名前とタイプがあります
ノードには、値を保存するドーターノードとプロパティがあります
プロパティ値には、数値、文字列、バイナリオブジェクト、および他のノードへのリンクを格納できます

どこかですでに聞いたことがありますよね？

そのようなリポジトリがどのように見えるか見てみましょう（もちろん、概略的に）：

 <root> <cms> <pages> <home title="Hello"> <block title="News" content="Today: PHPCR presentation"></block> </home> <contact title="Contact" content="phpcr-users@groups.google.com"></contact> </pages> </cms> </root>

今のところ超自然的なものはありません。

作業に必要なものについてもう少し詳しく考えてみましょう。

結び目

ノードは常に親を持つ名前付きコンテナです
XML要素を思い出させる
ノードを作成、削除、変更、コピーできます
ノードパスは、親ノードのパスと現在のノードの名前で構成されます。
パス：/ cms / pages / home
親パス：/ cms / pages
ホスト名：ホーム

ノードのプロパティ

ノードには値を保存する名前付きプロパティがあります
XML属性を連想させる
データ型：STRING、URI、BOOLEAN、LONG、DOUBLE、DECIMAL、BINARY、DATE、NAME、PATH、WEAKREFERENCE、REFERENCE
参照タイプ（弱）は、他のノードへのリンクを作成します
ノードとプロパティは名前空間を持つことができます： jcr:created

、 jcr:mimeType

、 phpcr:class

ノードの主なタイプ

使用が許可される名前、およびプロパティと子ノードのタイプを定義します
各ノードには基本タイプが設定されている必要があります
nt:unstructured

、何でもストレージに使用されます
他の組み込みタイプには、nt：アドレス、nt：フォルダー、nt：ファイルなどがあります。
独自のスキームを作成するには、新しいタイプのノードを定義できます

ミックスインノードタイプ

基本型には多重継承がありません
ただし、ノードに特性のような機能を追加するミックスインタイプがあります
ミックスインタイプは、その存続期間中にノードに割り当てることができます

例：一意の識別子を格納するjcr:uuid

プロパティがあるとします。 uuidを知って、 mix:referenceable

mix:versionable

作成し、それに基づいてmix:versionable

を作成できます（ただし、プロパティjcr:versionHistory

、 jcr:predecessors

、 jcr:baseVersion

、 jcr:isCheckedOut

、 jcr:mergeFailed

などがjcr:mergeFailed

です。）

ワークスペース

複数のワークスペースがあり、それぞれにノードのツリーがあります
Unixファイルシステムに似ており、Git / SVNのブランチで、それぞれクローンとマージが可能
単独で使用できます

そして今、これらすべてを扱う方法のいくつかの例：

セッション作成

 use PHPCR\SimpleCredentials; // ,      use Jackalope\RepositoryFactoryJackrabbit as Factory; $parameters = array( 'jackalope.jackrabbit_uri' => 'http://localhost:8080/server', ); $repository = Factory::getRepository($parameters); //         $creds = new SimpleCredentials('admin','admin'); $session = $repository->login($creds, 'default');

CRUD操作

 $root = $session->getRootNode(); //        $node = $root->addNode('test', 'nt:unstructured'); //        $node = $session->getNode('/test'); // /  $node->setProperty('prop', 'value'); //       $session->save(); //       $node->remove(); //  ,   -     $session->save();

木の散歩

 $node = $session->getNode('/site/content'); foreach ($node->getNodes() as $child) { var_dump($child->getName()); } //   foreach ($node as $child) { var_dump($child->getName()); } //    foreach ($node->getNodes('di*') as $child) { var_dump($child->getName()); }

バージョニング

 //   $node = $session->getNode('/site/content/about'); $node->addMixin('mix:versionable'); $session->save(); //    $node->setProperty('title', 'About'); $session->save(); // - ( ) //  - (   ) //         $session->save() $vm = $session->getWorkspace()->getVersionManager(); $vm->checkpoint($node->getPath()); //   $node->setProperty('title', 'Ups'); $session->save(); //    ,    «  » $vm->checkin($node->getPath()); $base = $vm->getBaseVersion($node->getPath()); $current = $base->getLinearPredecessor(); $previous = $current->getLinearPredecessor(); //     $frozenNode = $previous->getFrozenNode(); echo $frozenNode->getProperty('title'); // About //       $vm->restore(true, $previous); $node = $session->getNode('/site/content/about'); echo $node->getProperty('title'); // About

検索する

 $qm = $workspace->getQueryManager(); //  SQL2   "*"     //         // (. http://docs.jboss.org/exojcr/1.12.13-GA/developer/en-US/html/ch-jcr-query-usecases.html#d0e3332) $sql = "SELECT * FROM [nt:unstructured] WHERE [nt:unstructured].type = 'nav' AND ISDESCENDANTNODE('/some/path') ORDER BY score, [nt:unstructured].title"; $query = $qm->createQuery($sql, 'JCR-SQL2'); $query->setLimit($limit); $query->setOffset($offset); $queryResult = $query->execute(); foreach ($queryResult->getNodes() as $node) { var_dump($node->getPath()); }

他のコード例は、このプレゼンテーションで見つけることができます。

ただし、さまざまなバックエンドの魅力的な考えに戻ります。

現在、多くの実装はありませんが、それらはすでに興味深いものです。

Midgard2 PHPCR
ジャッカロープ
ジャックラビットをサポート
Doctrine DBAL（リレーショナルデータベース上のデータストレージ）をサポートします
MongoDBをサポートします（実際はそうではありません）

Midgard2 PHPCR

Midgard2は、C、Python、およびPHPのバインダーを備えたオープンソースのコンテンツリポジトリです。

JCRとは少し異なる用語であるMidgard2は、 php5-midgard2拡張を使用してMidgard2 PHPCRを介してコンテンツにアクセスするための同じ機能を提供します。 libgda GNOMEライブラリの上に構築されたMidgard2は、リポジトリをホストできるリレーショナルデータベースの印象的なリストを保持しています。

私はすぐに軟膏のフライについて言います-PHP拡張はかなり少数のオペレーティングシステム用に構築されています：

Debian 7 Wheezyの下では、パッケージはまだ不安定なブランチにあります（当然、PHP-FPMをセグメンテーション違反に静かに落とします）。
CentOSの場合、パッケージはすべてのアーキテクチャで古くなっているか、すべてではありません（ただし、その場合、動作する可能性が非常に高く、手が届きませんでした）
Windows上のビルドは自然には存在しません（おそらく、「gnomes」はMidgard2自体のルートですが、4年前のリポジトリ内のファイルはPHP4でも表示されます）
Mac OSが不足しているため、Mac OSでテストすることはできませんでした（ただし、サイトによると、すべてはbrewで設定されています）。

一般的に、すべてがUbuntu Server 12.04に正常にインストールされ、パッケージはそこに新しく、何もクラッシュしません。

しかし、IRCでSymfony CMF開発者と話をしたところ、このバックエンドプロバイダーが数か月間壊れており、テストも無効になっていることが明らかになりました。その理由は、Midgard2チームのどこかにありますが、Bergieは修正することを約束しました。

IRC

Midgard2 PHPCRをSymfony CMFで動作させることができませんでした。たぶん他の誰かが成功するでしょう。今ではなく、その後。

ジャッカロープ

名前でウサギのテーマ（ Jackrabbit 、 Jackalope ）を破り続けることで、Jackalopeは3種類のデータウェアハウスへのアクセスを提供します。

これはすでに私たちに知られていますApache Jackrabbit
Doctrine Database Abstraction Layer。これにより、サポートされているDBALエンジンを使用できます。これは理論上、実際には、MySQL、PostreSQL、およびSQLiteのみがテストされています（他の何かを使用していますか？）。
MongoD （2年間更新されていない、破損または無関係である可能性が高い）

Jackalope（特にjackalope-jackrabbit）は非常に安定しており、機能の面で最も完全なPHPCR API実装としての使用が推奨されます。彼女と一緒に働きます。ただし、PHPCR APIの可用性と機能を確認するphpcr-api-testsもjackalope-doctine-dbalに含まれており、時間が経つにつれて追いつく可能性があります。

PHPCRの概要

そのため、JCR API標準に準拠したコンテンツリポジトリにアクセスするための（PHPに適合した）APIがあります。このAPIのために、データウェアハウスからアプリケーションコードを抽象化するいくつかのライブラリが開発されました。

これまでのところ、2つの主要な質問が発生するはずであり、両方とも回答されます。

PHPCRを使用する場合

階層ナビゲーション構造を使用する場合
相互に関連するデータがある場合
データのバージョン管理が必要な場合

PHPCRを使用しない場合

厳密に構造化されたコンテンツと集約クエリの使用には、リレーショナルデータベースを使用することをお勧めします。たとえば、オンラインストアでは、製品の説明をPHPCRに保存し、注文をRDBMSに保存できます。

PHPCR ODM

仕様は優れていますが、APIは抽象的であり、日常的に使用するには不便です（結局、ほとんどは何らかのORMシステムに使用されています）。そして、PHPCRとObject Document Mapperの束であるPHPCR ODMプロジェクトがあります。

SF2（SF2だけでなく）を使用する開発者に馴染みのあるDoctrine ORMは、データマッパーパターンを実装してRDMBSに保存されたデータにアクセスします。

ODMは、Doctrine ORMと同様に、データマッパーを使用して、ビジネスロジックをデータストレージ層（この場合はコンテンツリポジトリ）から完全に分離します。著者は、ODMがHibernateのアイデアに触発されていることを正直に認めています。

ODMはオブジェクトをPHPCRノードとして保存し、ドキュメントと呼びます。同時に、PHPCRはすでに実装に依存していないため、新しいデータベース抽象化層（DBAL）を記述する必要はありません。

PHPCR ODM用語文書とは何ですか？

このドキュメントは、インターフェイスを実装しない簡潔なPHPクラスであり（または、いつでも実装できますが、ライブラリ自体はそれを必要としません）、いくつかの基本的な抽象クラスから継承されません。このようなエンティティには、 final

キーワードをwakeup()

メソッド、 clone()

およびwakeup()

メソッドの実装、または実装はすべきではありませんが、 慎重に行う必要があります。エンティティ自体は、ストレージにコミットされるプロパティで構成されます。 ODMは基本機能（クラスのアノテーション、キャッシング、およびオートロード）を実装するDoctrine Commonライブラリの上で実行されるため、クラスのプロパティへのデータウェアハウスのプロパティのマッピングは、PHPコメントまたはYAML / XMLコンフィグレーションのアノテーションを通じて、よく知られた方法で行われます。各ドキュメントにはタイトルとタイトルがあります。すべてのドキュメントはツリーで編成され、他のドキュメントを参照できます。サンプルドキュメントをご覧ください。

 namespace Demo; use Doctrine\ODM\PHPCR\Mapping\Annotations as PHPCRODM; /** * @PHPCRODM\Document */ class MyDocument { /** * @PHPCRODM\Id */ private $id; /** * @PHPCRODM\ParentDocument */ private $parent; /** * @PHPCRODM\Nodename */ private $name; /** * @PHPCRODM\Children */ private $children; /** * @PHPCRODM\String */ private $title; /** * @PHPCRODM\String */ private $content; //            }

注釈は、通常のデータ型（たとえば、String）に加えて、子ドキュメントまたは親ドキュメントへのリンクのタイプも指定できることに注意してください。

データマッパーパターンに慣れていない人にとっては、そのようなクラスはアクティブレコード（hi、rails、Yii-shniki）に少し似ているように見えるかもしれませんが、いずれにしても同じではありません。

そのようなドキュメントをどのように使用しますか？

 require_once '../bootstrap.php'; //     $rootDocument = $documentManager->find(null, '/'); //    $doc = new \Demo\Document(); $doc->setParent($rootDocument); $doc->setName('doc'); $doc->setTitle('My first document'); $doc->setContent('The document content'); //  ,    $childDocument = new \Demo\Document(); $childDocument->setParent($doc); $childDocument->setName('child'); $childDocument->setTitle('My child document'); $childDocument->setContent('The child document content'); //     ,        $documentManager->persist($doc); $documentManager->persist($childDocument); //   ,   ..   $documentManager->flush();

 require_once '../bootstrap.php'; $doc = $documentManager->find(null, "/doc"); echo 'Found '.$doc->getId() ."\n"; echo 'Title: '.$doc->getTitle()."\n"; echo 'Content: '.$doc->getContent()."\n"; foreach($doc->getChildren() as $child) { if ($child instanceof \Demo\Document) { echo 'Has child '.$child->getId() . "\n"; } else { echo 'Unexpected child '.get_class($child)."\n"; } } //   $documentManager->remove($doc); $documentManager->flush();

小さなメモ-ORMでは、クエリを使用してデータを受信するのが一般的です。 ODMでは、これに階層を使用する必要があります。ただし、本当に必要な場合はリクエストを行うことができます。

PHPCR ODMは、バージョン管理と多言語主義という2つの非常に重要な機能を既に実装しています。最初のものから始めましょう。

PHPCRには、simpleVersionableとversionableの2種類のバージョン管理があります。単純なバージョン管理のために、チェックイン/チェックアウトの方法と変更の線形履歴が提供されます。 Chekinはノードの新しいバージョンを作成し、読み取り専用にします。何かを書き込むには、チェックアウトする必要があります。

これに加えて、完全なバージョン管理は、非線形バージョン履歴（PHPCR-ODMにはまだヘルパーメソッドがありません）およびラベル（Jackalopeがサポートを開始するとすぐに追加される予定です）をサポートします。各ノードについて、バージョンにラベルを追加できますが、各ノードの履歴全体にわたってラベルを2回繰り返すことはできません（つまり、別のバージョンをマークする場合は、まず古いバージョンから削除する必要があります）。

完全なバージョン管理はmix:versionable

、PHPCR の型と一致し、分岐を許可します。残念ながら、PHPCRバージョンAPIはPHPCR ODMで完全にサポートされていません;完全な操作のためにPHPCR\VersionManager

は、PHPCRセッションを直接操作する必要があります。これについての詳細はこちらとこちら。

バージョン名はPHPCRによって生成され、アプリケーションによって制御されません。コミットメッセージングの概念はありません（まだ必要ありません）。いずれにせよ、ドキュメントにこのケース用のフィールドを作成することを誰も気にしません。

古いバージョンは、変更および変更の保存に使用できません（例外はrestoreVersion()

およびメソッドを使用する場合removeVersion()

です。

一部のドキュメントのバージョン管理サポートを有効にするには、アノテーションで明示的に指定する必要があります。

 /** * @Document(versionable="simple") */ class MyPersistentClass { /** @VersionName */ private $versionName; /** @VersionCreated */ private $versionCreated; }

バージョンの操作方法に関するドキュメントはほとんどありません。著者は、ソースコードのPhpdocコメントに連絡することをお勧めします。したがって、私たちはそのような高い問題に長い間留まらないで、小さな例を見て先に進みましょう。

 $article = new Article(); $article->id = '/test'; $article->topic = 'Test'; $dm->persist($article); $dm->flush(); //         $dm->checkpoint($article); $article->topic = 'Newvalue'; $dm->flush(); //     $versioninfos = $dm->getAllLinearVersions($article); $firstVersion = reset($versioninfos); //        $oldVersion = $dm->findVersionByName(null, $article->id, $firstVersion['name']); echo $oldVersion->topic; // "Test" //    $article = $dm->find('/test'); echo $article->topic; // "Newvalue" //       $dm->restoreVersion($oldVersion); //   echo $article->topic; // "Test" //    ,    $article->topic = 'Newvalue'; $dm->flush(); $dm->checkpoint($article); //      (     ) $dm->removeVersion($oldVersion);

多言語主義について。ドキュメントのプロパティはすべて、翻訳可能としてマークできます。翻訳中に文書全体が複製されるという事実にもかかわらず、翻訳を必要としないフィールドは無駄にコピーされません。毎回作業用の言語を指定する必要がないことは明らかです。必要な言語を一度DocumentManagerに伝えるだけで、すべてのタイプの呼び出しfind()

と新しいドキュメントの作成に使用されます。便利：

 /** * @PHPCRODM\Document(translator="attribute") */ class MyPersistentClass { /** *    * @Locale */ private $locale; /** *   * @Date */ private $publishDate; /** *   * @String(translated=true) */ private $topic; /** *     * @Binary(translated=true) */ private $image; }

そして、フィールドを翻訳する作業は次のとおりです。

 //   DocumentManager (   ) $localePrefs = array( 'en' => array('fr'), 'fr' => array('en'), ); $dm = new \Doctrine\ODM\PHPCR\DocumentManager($session, $config); $dm->setLocaleChooserStrategy(new LocaleChooser($localePrefs, 'en')); //   : $doc = new Article(); $doc->id = '/my_test_node'; $doc->author = 'John Doe'; $doc->topic = 'An interesting subject'; $doc->text = 'Lorem ipsum...'; //     $dm->persist($doc); $dm->bindTranslation($doc, 'en'); //          $doc->topic = 'Un sujet intéressant'; $dm->bindTranslation($doc, 'fr'); //    echo $doc->locale; // fr //    PHPCR $dm->flush(); //       // (   ) $doc = $dm->find(null, '/my_test_node'); //     $doc = $dm->findTranslation(null, '/my_test_node', 'fr'); $doc->title = 'nouveau'; $dm->flush(); //    ,

現在、親リンクと子リンクを含むすべてのリンクについて、セッション中に追跡できるドキュメントは1つだけなので、デフォルト言語へのフォールバックがあります。作者はまだ何をすればいいのかわからず、不完全なドキュメントを処理する問題は未解決のままです（ドキュメントに記載されているフィールドが実際に存在しない場合）。ただし、これらの問題がどのように解決されるかは時間が経てばわかります。

さらに、将来、ロギング、結果のキャッシングを改善し、ドキュメントの更新を開始します（まだ非常に少ないです）。DoctrineDBALと組み合わせてSolr / ElasticSearchサポートを強化し、MongoDBの実装を完了しようとします。現在、開発者はJackrabbitの次のメジャーバージョン（コードネームOak）に目を向け、互換性テストさえ実施していますが、主なタスクはPHPCRとその実際のアプリケーションへの組み込みを促進することです。

まとめると。ODMを使用する場合、スタックは次のようになります。

JackalopeまたはMidgard2の形式のバックエンドを持つPHPコンテンツリポジトリ（データはJackrabbitまたはRDBMSに保存されます）
バックエンドに関係なく便利な作業のためのDoctrine Commonの上部にあるPHPCR-ODM
直接アプリケーションコード。

記事の第2部に続きます。

Symfony CMF パート1、データストレージ