Symfony CMF パート2と最後

疎結合コンポーネントからCMSを構築するためのプラットフォームコンセプトを実装するSymfony CMFを引き続き検討します。 記事の最初の部分では 、ストレージとデータへのアクセスのスキームを詳細に検討しました。2番目の部分では、他のすべてが私たちを待っています。



この記事の続きは、私の怠laz、健康上の問題、インターネットのために大幅に遅れています。 過去2か月間、システムはバージョン1.0.0に成長し、masterブランチでのそれ以降のすべての編集は、文書化されずに何らかの形でシステムの作業を中断します。 誰かがシステムを手に入れたい場合、覚えておいてください-タグでマークされた安定したバージョンに頼ってください。



最もせっかちな人は、スクロールダウンし、インストールされたシステム（VirtualBoxが必要です）で仮想マシンをダウンロードし、自分ですべてを感じることができますが、完全を期すために、最初に記事を読むことをお勧めします。



だから。 データ保存後の計画は何ですか？





デモプロジェクトのメインページのスクリーンショット

テンプレートエンジン

ここではすべてがよく知られています-Twigが使用されます。 柔軟で強力、非常に高速で簡潔。 ブロック分割、継承、およびテンプレートのPHPコードへのコンパイルをサポートします。 メインページテンプレートは次のようになります。

{% extends "SandboxMainBundle::skeleton.html.twig" %} {% block content %} <p><em>We are on the homepage which uses a special template</em></p> {% createphp cmfMainContent as="rdf" %} {{ rdf|raw }} {% endcreatephp %} <hr/> {{ sonata_block_render({ 'name': 'additionalInfoBlock' }, { 'divisible_by': 3, 'divisible_class': 'row', 'child_class': 'span3' }) }} <div class="row"> <div class="span3"> <h2>Some additional links:</h2> <ul> {% for child in cmf_children(cmf_find('/cms/simple')) %} <li> <a href="{{ path(child) }}">{{ child.title|striptags }}</a> </li> {% endfor %} </ul> </div> <div class="span3"> {{ sonata_block_render({ 'name': 'rssBlock' }) }} </div> </div> {% endblock %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CoreBundleには、CMFの操作とPHPCRツリーの走査を簡素化するTwigの拡張機能が含まれています。たとえば、 cmf_prev



、 cmf_next



、 cmf_children



などの関数です。



特にここで注目すべきことはありません、Twig-彼はアフリカのTwigにもいます。

管理パネルに関するいくつかの言葉

管理ページ



有名な管理パネルジェネレーターSonataAdminBundleはSymfony CMFでまったく同じ機能を実行しますが、 SonataDoctrinePhpcrAdminBundleの形式の特別なレイヤーを使用します。 これは、元のバンドルがデータウェアハウスから抽象化できるようにするためです。



ツリー構造を操作するために、jsTreeで実行されるTreeBrowserBundleが設計されています。



以下で説明するadmin部分を持つコンポーネントは、必ずここでパネルを接続します。 したがって、これを詳細に説明するために、理由はないと思います。詳細なスクリーンショットはこれ以上ありません。

静的コンテンツ

CMSの静的コンテンツは、すべての基盤です。 Symfony CMFでは、ContentBundleは静的コンテンツを担当します。静的コンテンツは、多言語とルート通信を含む静的ドキュメントクラスの基本的な実装を提供します。



バンドルの基本はStaticContent



クラスであり、その構成は、 title



、 body



、親ドキュメントへのリンクなど、多くのStaticContent



フィールドに馴染みがあります。 さらに、2つのインターフェイスを実装します。

• RouteReferrersInterface
  
  
  
  は、 RouteReferrersInterface
  
  
  
  のルートを提供します
• PublishWorkflowInterface
  
  
  
  、指定された発行日を使用してコンテンツを表示または非表示にするのに役立ちます

多言語ドキュメントの場合、 MultilangStaticContent



が提供されます-すべて同じですが、フィールドの翻訳とロケールの宣言が追加されます。 翻訳の方法-記事の最初の部分ですでに見ました。



バンドルはコントローラーに依存しています。 ContentController



は単一のindexAction



で構成され、入力時に目的のドキュメントをindexAction



し、目的の言語でレンダリングします（公開パラメーターですべてが問題ない場合）。 オプションで、ページの表示に使用するテンプレートを指定できます。 設定されていない場合、デフォルトで指定されたものが使用されます。

ルーティング

今日の大規模なサイトでは、材料の量を数千単位で簡単に測定できます。 翻訳の数を掛けます。 検索エンジン最適化の名の下に、素材とURLを絶えず編集する必要性を追加します。

同時に、サイト管理者（ウェブマスター、コンテンツマネージャー、SEO）は通常、開発者ではなくそのようなことに関与しています。



この場合のルーティングの要件は何ですか？

• ユーザーが設定したURL
• マルチサイトサポート
• 多言語サポート
• ツリー構造
• コンテンツ、メニュー、ルートを共有する必要があります

標準のSymfony 2ルーターを思い出すと、そのような柔軟性はそこでは達成できないことが明らかになります。 ルートは各コントローラーの構成に明示的に登録されており、ユーザーは単にルートの変更を許可していません。 期待できる最大数は、管理パネルから編集できる何らかの種類/page/{slug}



です。



ベアSF2の操作スキームがどのように見えるかを見てみましょう。







構成オプションの詳細に触れない場合、すべてが非常に原始的です。 要求が到着すると、ルーターが呼び出すコントローラーを決定し、コントローラーが必要なデータを取得してビューを表示し、切望された応答を発行します。



これはかなりよく知られたスキームです。



このオプションはなぜCMSに十分ではないのですか？



ページURLエイリアスを引数として受け取り、データベースに保存されているものと比較してページを表示する特定のPageController



があることを想像してください。404



私の実践では、静的コンテンツの中に、個別のコンポーネントとしてよりもサイトのセクションの一部としてより調和のとれた異なるフォームが存在する場合がありました。 たとえば、ある銀行のウェブサイトのテキストセクション/credits/cash



のURLにクレジット/calculator



追加されたため、人々はローンに関する必要な情報を読んだ後、その場で必要な数字を把握できます。



PageController



がURLの最初の部分を処理すると仮定します。電卓で何をすべきか、これは明らかに、別個のコントローラーとして機能しますか？ pattern: /credits/cash/calculator



追加しpattern: /credits/cash/calculator



設定でpattern: /credits/cash/calculator



と別のコントローラー/アクションを指定しますか？ なんとなくugい。 残りのルートに優先順位を付けたとしても、柔軟性の匂いがしないことは明らかです。データベース内のニックネームが変更された場合、手で設定を編集する必要があります。



他の何かが必要です。



SF2のルーティングを要約します。

• どのコントローラーがリクエストを処理しているかを決定します
• URLパラメーターが解析されます
• 他のすべてが失敗した場合、デフォルトの動作は事前に設定されたルートのセットに基づいています
  
  
  
  
  • アプリケーション構成から
  • バンドルから
  
  
  
• ユーザーはルートを編集できません
• 非常に多数のルートに対応していません
• CMSでは、 ユーザー自身がどのアドレスにあるべきかを決定したいと考えています。

Symfony CMFルーティングコンセプト

Symfony 2は美しく強力なものを放棄しなければなりませんでしたが、CMSルーターの場合は新しいコンセプトを支持して不便です。

• コンテンツツリーをナビゲーションツリーから分離する必要があります
• ナビゲーションツリーは、コンテンツツリー要素へのリンクで構成されています 。 このため、実装は簡単です。
  
  
  
  
  • マルチサイト（デスクトップ、タブレット、モバイルバージョン）
  • 多言語
  
  
  
• ナビゲーションオーバーフローには、ナビゲーションツリーの複製が必要です
• 準備ができたら、結果が戻ります

すぐに解決策が浮かびます：必須パラメーターurl: .*



使用してデフォルトルート（ /{url}



を作成し、すべての要求に対して1つのコントローラーを作成し、コンテンツに応じて、要求を他のコントローラーにリダイレクトします。 しかし同時に、他のルートとの競合をキャンセルする人はいません。

 navigation: pattern: "/{url}" defaults: { _controller: service.controller:indexAction } requirements: url: .*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それはまだあまり良く聞こえません。



（Symfony 2.1の時代から非推奨とマークされるまで） DoctrineRouter



方がより良いソリューションを提供しました。 PHPCR-ODMを介したドキュメントの実装の準備ができていたので、データベース内のURLでルートを探していたため、すでにはるかに柔軟です。独自のものを追加できます。 コントローラーは、明示的にルートを明示的に示しました。それ以外の場合は、 ControllerResolver



使用され、リクエストを処理するコントローラーを決定しようとしました。 組み込みのリゾルバもありました：

• 特定のタイプのノードをコントローラーにバインドする
• 特定のタイプのノードをテンプレートにバインドし、標準（汎用）コントローラーを使用する

ヒープへ-（他のルートまたは絶対URLへの）ルートのリダイレクト。



現在、Symfony CMFは2つのコンポーネントを使用して、ルーティングに関するすべての問題を解決しますChainRouter



およびDynamicRouter



。 最初のものは標準のSF2ルーターを置き換えますが、名前にかかわらず、ルーターは実際には機能しません（要求を処理するコントローラーを定義します）。 代わりに、ルーターをチェーンリストに追加することができます。 チェーンでは、構成されたすべてのルーターが優先度順に順番に要求を処理しようとします。 ルーターサービスはタグによって検索されます。

 cmf_routing: chain: routers_by_id: #  DynamicRouter    #        #         cmf_routing.dynamic_router: 20 #    acme_core.my_router: 50 #       router.default: 100 services: acme_core.my_router: class: %my_namespace.my_router_class% tags: - { name: cmf_routing.router, priority: 300 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、使用可能なルーターの数は無限です。



ここで、データベースとDynamicRouter



内のルートの検索を思い出します。 そのタスクは、 プロバイダーからルートをロードすることです。プロバイダーはデータベースになることができます（通常はそうです）。 標準パッケージには、Doctrine PHPCR-ODM、Doctrine ORMのプロバイダー実装があり、もちろん、 RouteProviderInterfaceを実装することでプロバイダーのリストを補完できます。



プロバイダーは何をしますか？ オンデマンドプロバイダーは、着信要求に適合する可能性のある候補ルートの順序付きサブセットを発行し、 DynamicRouter



が最終決定を行い、要求をタイプRoute



特定のオブジェクトにマップします。







ルートは、特定の要求を処理するコントローラーを決定します。 DynamicRouter



は、優先度の降順でいくつかのメソッドを使用します。

• 明示的に： Route
  
  
  
  ドキュメント自体は、 getDefault('_controller')
  
  
  
  呼び出しから宛先コントローラーが返される場合、宛先コントローラーを明示的に宣言します。
• エイリアスによる：ルートはgetDefault('type')
  
  
  
  返します。これはconfig.yml
  
  
  
  から設定にマップします
  
  
• クラス別： RouteObjectInterface
  
  
  
  ドキュメントはRouteObjectInterface
  
  
  
  を実装し、 getContent()
  
  
  
  オブジェクトを返す必要があります。 返されたクラスタイプは、再び設定にマッピングされます
• デフォルト：指定されている場合、デフォルトのコントローラーが使用されます

同様に（明示的にまたはクラスごとに）、ルートはページのレンダリングに使用するテンプレートを指定できます。



オプションで、前述のRouteObjectInterface



を使用して、関連付けられたモデルインスタンスを返すようにルートを教えることができます。



リダイレクトもサポートされています。 一般に、 RedirectRouteInterface



インターフェースがありRedirectRouteInterface



が、PHPCR-ODMの場合、 RedirectRoute



ドキュメント形式の実装が用意されています。 絶対URIおよびチェーン内の任意のルーターによって生成された名前付きルートにリダイレクトできます。



Symfonyを使用したことがない人にとって興味深いもう1つの重要な機能は、ルーターの双方向性です。 指定されたパラメータに基づいてルートを認識することに加えて、これらのルートはパラメータを引数として渡すことで生成することもできます。 標準のSF2ルーターとは異なり、 path()



関数のパラメーターとして、configで指定されたルート名だけでなく、 RouteObjectInterface



、 RouteReferrersInterface



（つまり、ルートオブジェクト）の実装、またはcontent_idを使用してリポジトリ内のオブジェクトへのリンクを渡すことができます：

 {# myRoute    Symfony\Component\Routing\Route #} <a href="{{ path(myRoute) }}">Read on</a> {#    /    #} <a href="{{ path('/cms/routes') }}">Home</a> {# myContent  RouteReferrersInterface #} <a href="{{ path(myContent) }}">Read on</a> {#    ,   ContentRepositoryInterface #} <a href="{{ path(null, {'content_id': '/cms/content/my-content'}) }}"> Read on </a>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

複数のルートが同じマテリアルに適している場合、ロケールがクエリロケールと一致するルートが好ましいと見なされます。



最後に、ナビゲーションツリーとコンテンツツリーの分離、少し前に書かれたものに戻ります。 図を見て、特定のルールに従って分岐したナビゲーションが必要なコントローラーに制御を移し、その後データを要求します：







ルートの管理パネルで、形式（たとえば、URLが.html



で終わるように）とスラッシュを設定できます。



それに加えて、実験的なRoutingAutoBundleはこれまで 、定義済みのルールに基づいてコンテンツのルートを生成することを提案しています。 自動ルートを生成することにより、柔軟性が実現します。個々のルートについて、エイリアスの変換、サイトマップの生成、およびルートがリンクできるドキュメントのクラスの変更が簡単です。 ただし、ほとんどの場合、単純なCMSの場合、このバンドルは必要ありません。



柔軟なルーティングでこれで終わります。

メニュー

CMSはメニューシステムなしではできません。 メニュー構造は通常、コンテンツの構造に従いますが、コンテンツによって定義されていないか、異なるオプションを持ついくつかのコンテキストに存在する独自のロジックが必要になる場合があります。







Symfony CMFには、独自のメニューを定義できるツールであるMenuBundleが含まれています。 有名なKnpMenuBundleを拡張し、階層的で多言語の要素と、選択したリポジトリに書き込むためのツールで補完します。



メニューが表示されると、MenuBundleはKnpMenuBundleのデフォルトのレンダラーとヘルパーに基づいています。 ドキュメント全体を読むことをお勧めしますが、一般的に、最も単純な場合、出力は次のようになります。

 {{ knp_menu_render('simple') }}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MenuProviderInterface



渡されたメニュー名は、 MenuProviderInterface



実装に渡され、表示するメニューが決定されます。



バンドルは、PHPCRストレージからメニューを動的にロードするMenuProviderInterface



の実装であるMenuProviderInterface



に基づいています。 デフォルトでは、プロバイダーサービスはmenu_basepath



パラメーターで構成されます。このパラメーターは、PHPCRツリーでメニューを探す場所を示します。 メニューがレンダリングされると、 name



パラメーターが渡されます。これは、指定されたベースパスの直接の子孫でなければなりません。 これにより、 PhpcrMenuProvider



、単一のストレージエンジンを使用して複数のメニュー階層を操作できます。 上記の使用例を思い出してください。構成で以下が指定されている場合、 /cms/menu/simple



は/cms/menu/simple



に配置する必要があります。

 cmf_menu: menu_basepath: /cms/menu
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バンドルは、 MenuNode



とMenuNode



2種類のノードをサポートしています。 MenuNode



は、特定のメニュー項目に関する情報が含まれています： label



、 uri



、子供のchildren



リスト、ルートへのリンク、関連するContent要素、および属性attributes



リスト。これにより、メニュー出力をカスタマイズできます。



MenuNode



クラスは、 MenuNode



を拡張して多言語をサポートしlocale



フィールドが追加され、アイテムが属するtranslated=true



と、 translated=true



とマークされたuri



のlabel



を定義しtranslated=true



。 これらは、翻訳間で異なる唯一のフィールドです。







管理パネルと統合するために、SonataDoctrinePhpcrAdminBundle用のパネルとサービスがあります。 パネルはすぐに使用可能になりますが、使用するには、ダッシュボードに明示的に追加する必要があります。







バンドルは通常どおり構成されますが、すべてのパラメーターはオプションです。



ルーティング、メニュー、およびコンテンツ間の接続は次のとおりです。

ブロック

ブロックを操作するためのバンドルも提供されます。 ブロックは、ある種のロジックを実装するか、テンプレートのどこからでも呼び出すことができる静的コンテンツを単に返すことができます。 BlockBundleはSonataBlockBundleに基づいており、必要に応じて、親バンドルのコンポーネントを、PHPCRと互換性のある独自のバンドルに置き換えます。





メインページからの典型的なブロック



バンドル内には、いくつかの典型的なブロックがあります。

• StringBlock
  
  
  
  単一のbody
  
  
  
  フィールドを持つブロック。テンプレートで文字列をレンダリングするだけで、タグで囲むこともありません
• SimpleBlock



title
  
  
  
  追加されbody
  
  
  
  
  
  
• ContainerBlock
  
  
  
  指定されたブロックのリスト（他のコンテナーブロックを含む）をレンダリングします
• ReferenceBlock
  
  
  
  別のブロックのみを参照できます。 呼び出されると、リンクが指すブロックが呼び出されたように動作します。
• ActionBlock
  
  
  
  コントローラーからの特定のアクションの結果をActionBlock
  
  
  
  ます。目的の要求パラメーターを渡すことができます
• RssBlock
  
  
  
  指定されたテンプレートでRSSフィードを表示します
• ImagineBlock
  
  
  
  -PHPCRから直接画像を出力するためにLiipImagineBundleによって使用されます
• SlideshowBlock
  
  
  
  は特別な種類のコンテナブロックであり、マークアップ内の任意のブロックをラップして、スライドショーを整理できます。 このために自分でJSライブラリを選択する必要があることは注目に値します。キットには含まれていません。

独自のブロックを作成できます 。



ブロック出力キャッシングメカニズムはSonataCacheBundleの上で機能しますが、 BlockBundleにはMongoDB、Memcached、およびAPC用のアダプターはありません-VarnishまたはSSIに満足する必要があります。



ブロックはTwig関数sonata_block_render()



を使用してsonata_block_render()



れます。元のバンドルとは異なり、PHPCRのブロックの名前は引数として渡されます。

フロントエンド/インライン編集

オンザフライ編集は、いくつかのコンポーネントを使用して実装されます。



1つ目はRDFaマークアップです。 これはHTMLでメタデータをmicroformatスタイルで記述する方法ですが、属性を使用します。

 <div id="myarticle" typeof="http://rdfs.org/sioc/ns#Post" about="http://example.net/blog/news_item"> <h1 property="dcterms:title">News item title</h1> <div property="sioc:content">News item contents</div> </div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、上記のコードはDOM要素の「ダム」セットではなくなります。これは、属性からの情報をJSコードに簡単に抽出し、 VIE.jsを使用してBackbone.jsのモデルとコレクションにリンクできるためです。



チェーンの3番目はcreate.jsです 。これにより、編集インターフェースを思い付く必要がなくなります。





Create.jsワークフロー



create.jsは、jQueryウィジェットのVIE.jsの上で実行されます。 彼は何ができますか？

• エディター-Aloha、Hallow、Redactor、ckEditorを使用して、RDFでマークされた要素のコンテンツを変更する
• localStorageを使用して、CMSを離れる前に編集を保存および復元するためのサポートを提供します。
• 編集中に表示される通知を管理する
• 適切なツールでツールバーを整理する
• 「削除」、「公開から削除」タイプのカスタムワークフロー関数を呼び出す

すべてのコンテンツはその場で編集され、RDFaにより、一部のCMSのように大量の補助HTMLマークアップを生成する必要がありません。





善の奉仕におけるckEditor



さて、 CreatePHPリストが閉じます 。create.js呼び出しとバックエンド自体をリンクするライブラリ。 彼女は、PHPのモデルプロパティをHTML属性にマッピングし、エンティティをレンダリングする責任があります。 最も注意深い人は、CreatePHPのTwig拡張機能があることをすでに見ており、その呼び出しはこの記事の最初のリストに表示されています。モデルを転送し、出力形式を指定します。 美人



最後の2つのコンポーネントは、CreateBundleで便宜上結合されています。

メディアバンドル

最も最小限の実装のバンドルの1つは、メディアオブジェクトを操作するためのバンドルです。 ドキュメント、バイナリファイル、MP3、ビデオなど、魂が望むものなら何でもかまいません。 現在のバージョンは画像のダウンロードとファイルのダウンロードをサポートしており、残りはあなたの手で書きます。 SonataMediaBundleは、特に統合されているため、役立ちます。



バンドルは以下を提供します：

• 単純なモデルの基本文書。
• 単純なモデルの基本的なFormType
  
  
  
  。
• ファイルをアップロードおよびダウンロードするためのコントローラー。
• サーバーへのダウンロードからの抽象化を提供するヘルパー。
• 画像を表示するコントローラー。

統合用のヘルパーとアダプター：

• メディアブラウザ（elFinder、ckFinder、MceFileManagerなど）;
• 画像操作ライブラリ（Imagine、LiipImagineBundle）。

独自のメディアクラスを作成するための多数のインターフェイスがあります。

• MediaInterface
  
  
  
  ：基本クラス;
• MetadataInterface
  
  
  
  ：メタデータ定義;
• FileInterface
  
  
  
  ：ファイルとして定義されています。
• ImageInterface
  
  
  
  ：画像として定義されています。
• FileSystemInterface
  
  
  
  ：ファイルはファイルシステムに保存され、メディアオブジェクトとしてファイルへのパスが保存されます。
• BinaryInterface
  
  
  
  ：主にファイルがメディアオブジェクト内に保存されるときに使用されます。
• DirectoryInterface
  
  
  
  ：ディレクトリとして定義されています。
• HierarchyInterface
  
  
  
  ：メディアは、メディアに保存されたディレクトリパスをオブジェクト：/path/to/file/filename.ext
  
  
  
  。

ファイルパスへの興味深いアプローチ。バンドルの用語では、たとえばメディアオブジェクトへのパスが理解され、/path/to/my/media.jpg



Windowsシステムと* nixシステムのパスの違いは平準化されます。PHPCRでは、このパスを識別子として使用できます。いくつかの便利な方法が利用可能です：

• getPath
  
  
  
  PHPCR、ORM、またはその他のDoctrineストレージに保存されているオブジェクトへのパスを取得します
• getUrlSafePath
  
  
  
  安全に使用するためにパスをURLに変換します。
• mapPathToId
  
  
  
  Doctrineリポジトリを検索するためにパスを識別子に変換します;
• mapUrlSafePathToId
  
  
  
  URLを変換して識別子に戻します。

自明の機能はTwig拡張で利用可能です：

 <a href="{{ cmf_media_download_url(file) }}" title="Download">Download</a> <img src="{{ cmf_media_display_url(image) }}" alt="" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

提供されたフォームタイプを使用して、ドキュメントに画像を添付できます。

 use Symfony\Component\Form\FormBuilderInterface; protected function configureFormFields(FormBuilderInterface $formBuilder) { $formBuilder ->add('image', 'cmf_media_image', array('required' => false)) ; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実装アダプタメディアブラウザelFinder、ライブラリGaufretteは、ファイルシステムとの上に抽象化層を与え、LiipImagine画像の操作を簡素化し、。







先ほど言ったように、バンドルの実装は最小限です。写真は大量に読み込まれるわけではありませんが、ドキュメントに添付されているファイルを物理的に削除するには、ドキュメント自体も削除する必要があります。あの

見込み

モジュールとの統合が計画されています（一部の場所ではある程度準備ができています）。

• SymfonyCmfSearchBundle（フル検索、LiipSearchBundleを拡張）
• SymfonyCmfSimpleCms（CMFに付属する最も単純なCMS）
• LuneticsLocaleBundle（ロケールの自動検出）
• Sonataの他のバンドル

そしてもちろん、新機能の開発と現在の欠点の除去。

すべてがとても良いですか？

Symfony CMFのすべてが素晴らしいので、ここでは何キロバイトものテキストを十字架につけています。そのため、批判はどこにあるのかを尋ねるのは論理的です。



十分な欠点があります。



Symfony CMFはめったに更新されません-新しいバージョンをリリースするプロセスはSF2リリーススキームに類似していること、つまり6か月ごと（4か月は新しい機能を作成し、2か月はバグを修正してリリースを準備します）にgithubで示されます。もちろん、脆弱性を排除することを目的としたマイナーな修正がありますが、一般的に、新しいものが必要な場合は、かなり待たなければなりません。同時に、これはリリース間で下位互換性を維持する約束を誰も負わないような開発段階です。これは、1.0、1.1で機能していたものが簡単に壊れることがあることを意味します。



ドキュメントが苦しんでいます。 messプロジェクトのwikiでは、多くの記事が既に削除されている必要があります。古いコードはどこかに書かれており、一般にSymfony CMF BookはSF2の同様のコレクションほどフレンドリーでシンプルではありません。



CMFには非常に高いエントリしきい値があります。テストシステムをインストールするには、「webrootですべてを解凍してinstall.phpを実行する」だけでは不十分です。コンポーネント間の接続を理解し、各コンポーネントを処理できる必要があります。コードの改良や実装には、内部を注意深く調査する必要があります。おそらく、SF2を使用している開発者は恐れていません。しかし、ユーザーにはまったくドキュメントがありません...



スクリーンショットだけで明らかな結論は、システムが粗雑であり、まだプレゼンテーションからはほど遠いということです。管理者の使いやすさには疑問があります。それはきちんとしたブートストラップのようですが、デザイナーの手はここでは何も触れていないようです。クールなフロントエンドエディターにもかかわらず、body



管理パネルの-elementsには、2行の高さの悲惨なテキストエリアのみが提供されます。通常の操作では、ナビゲーションの概念が不適切であるため、ジェスチャを多くしなければなりません。







ドキュメンテーションは、しばしばXまたはYを後で作成することを約束します。誰かがプロジェクトを宣伝したい場合、使用の妥当性を説得することは難しいと思います。Symfony CMFをインストールした後、あなたの人生がどれほど簡単で楽しいものになるかを約束するおしゃれな見た目シートはありません。一般的に、魅力的な作業システムを得るための「ボックス」はありません。 そしておそらくしない



それとは別に、Symfony CMFの産業上の使用例はまだないことに注意してください。負荷がかかった状態でシステムがどのように動作するか、急に拡張する必要がある場合（バックエンドを含む）にどうするかは不明です。これらの問題は、キャッシュバンドルとAPCのインストールを除き、ドキュメントには記載されていません。

ビジネスに取り掛かろう

VirtualBox用に準備した仮想マシンイメージをすぐにダウンロードできます。VirtualBoxには、さまざまなバックエンドを含め、すべてがインストールおよび構成されています。便宜上、hostsファイルに登録してip_ cmf-sandbox



ブラウザからログインできますが、通常はIPアドレスで入力できます。IPアドレスを入力すると、ログイン後すぐにプロンプ​​トが表示されます（デフォルトのユーザー名とパスワード:) symfony



。



ミラー（.ovaファイル、≈1Gb）：

• Yandex.Disk
• mega.co.nz

何らかの理由でこれをいじりたくない場合は、オンラインサンドボックスへのリンクを提供しますが、急いで見ることでも機能しますが、内部で掘り下げることはできません。



少し退屈な作業を手動でインストールするため、詳細な手順で説明されている各手順については詳しく説明しません。主要なポイントを少し歩くだけです。



マシンがCMFを実行するための要件は少し標準的ではありませんが、犯罪はありません。



まず、Symfony 2の標準的なニーズを満たす必要があります（これはすでに大丈夫である可能性が非常に高い）：

• PHP 5.3.3以降をインストール
• JSONを有効にする
• ctypeサポートを有効にする
• するためにphp.ini
  
  
  
  正常にインストールdate.timezone
  
  
  
  
  
  
• DoctrineのPDOドライバーを置く

他のすべて（APCなど）はオプションです。



次はSymfony CMFの要件です。デフォルトでは、SQLiteはデータの保存に使用されるため、拡張機能がインストールされていることを確認してくださいpdo_sqlite



。



他のバックエンドを使用するには、次をインストールします。

• Apache Jackrabbitと、それに応じたJava（ディストリビューションごとに、独自のインストール方法）。インストールされたCMFのルートは、jack
  
  
  
  不要なジェスチャーなしでJackrabbitをダウンロードして起動するのに役立つスクリプトでなければなりません。使用できますが、Javaは引き続き個別に設定されます。
• Midgard2 PHPCR PHP. , : , ( sid Debian), , , . , , RPM, deb-. , — Midgard2 CMF .

また、サンドボックスのあるフォルダーにはswitch_backends.py



、私が書いたスクリプトがあり、それ自体が構成を必要なものに置き換え（元のファイルはで修正されますapp/config/phpcr/



）、実稼働キャッシュを消去してすべてが起動します。明らかな理由で、私はこれまでmidgardのオプションについてコメントしました-それでも動作しません。



コンソールに入力する誘惑に警告するgit pull



かcomposer update



、記事の冒頭で述べたように、masterブランチの変更はシステムのパフォーマンスに違反するため、次の安定版リリースを待ちます。

まとめ

したがって、多数の「しかし」にも関わらず、プロジェクトは面白そうです。驚いたことに、コンテンツ管理のいくつかの基本的な問題は正常に解決されました（たとえば、多言語とルーティング/メニュー）。開発は、すでに仕事をしている非常に限られた人々のグループによってゆっくりと行われているので、ドキュメントの編集やバグの修正に関係なく、githubのフォークと便利なプルリクエストが最善の助けになります。CMFの普及はすぐに進んでいます（ネットワークで資料を検索してみてください。実際にはありません）。すべての希望はオープンソースとコミュニティのみです。



現在、本番環境でCMFを使用するのは危険な場合がありますが、すべて同じように注意する必要があります。おそらく、これらの数百万ユーロから何かがここに落ちて、数年後には素晴らしい製品が見つかるでしょうか？



以上です。 便利なリンクの小さなリスト：

• CMF
• Roadmap