Drupal は元々 コンテンツをHTML で返すことを前提にしていましたが、時代は変わり、HTML 以外でコンテンツを返すニーズが増えました。例えばスマートフォンのアプリその他の Web Services プラットフォームとしてなどです。そのようなニーズに対しては Web Service モジュールなどを利用することで対応してきましたが、高い需要を考慮しコアで対応する必要性に応じSymfony2 の リクエストオブジェクトの利用によりこれを実現することになりました。
Masa Nishio and dokumori さん
和約、要約とてもわかりやすくありがとうございました。
技術の細部は知識がなくわからないんですが、大きな流れはすっきり理解できました。
drupal8は大きな変化を生みそうですね。
dokumoriさん、日本語版ドキュメント作成もどうなんでしょうかね、良い意味で暗礁に乗り上げられそうですね。
Comments
8.xのコードに入っていますね
まとまった情報は見当たりませんでしたが、8.xのgit treeにはSymfonyのコードが入っていますね。
http://drupal.org/project/drupal/git-instructions
blauerbergさん、はい確認しています^^ フレーム
blauerbergさん、はい確認しています^^
フレームワークを使うことにより何を目指しているのかとかロードマップだとか、その辺のコンテキスト情報を少し知りたいところです。
drupal-8-meets-symfony2 のkeynote
http://denver2012.drupal.org/program/sessions/drupal-8-meets-symfony2 の
最初の10分間で少し説明がありますね。
Symfonyを採用する事で、CMS特有の機能への開発リソース集中や他のアプリケーションとのIntegration性の向上を目指しているようです。
Developer側としては、最初の学習コストが高くなりますが、長期的に見るとメリットがありそうです。
Symfony2
Symfony2 のページに記載はありますね。もうご存知でしたらごめんなさい。
http://symfony.com/blog/symfony2-meets-drupal-8
あと、そこからリンクのある Dries のブログにも。
http://buytaert.net/the-future-is-a-restful-drupal
僕は PHP 自体がまだよくわかっていないので、「PHP フレームワーク」というものも全然わかりません。
PHP でなにかを設計する上での『まとまった部品』みたいなものですかね^^;
Symphony じゃないんだ（汗
未来は RESTful Drupal
Shin-gdo_J さんが紹介してくださった Buytaert 氏のブログ記事を翻訳しました。長いのでスマホでも読みやすいように前半と後半に分けてあります。よかったらご覧ください。
Masa Nishio
Masa Nishio さん、翻訳ありがとうございました。
Dries のブログの内容と、このイニシアティブを片目で追ってきた僕の理解を元に要約してみます：
元々、 Larry Garfield が Drupal 8 の WSCCI (Web Services and Context Core Initiative - http://groups.drupal.org/wscci ) を提唱した際に Symfony2 の採用を提案しました。Dries のブログにある通り、このイニシアティヴは対象が大きすぎるので二つに分割されました。
Web Services
Drupal は元々 コンテンツをHTML で返すことを前提にしていましたが、時代は変わり、HTML 以外でコンテンツを返すニーズが増えました。例えばスマートフォンのアプリその他の Web Services プラットフォームとしてなどです。そのようなニーズに対しては Web Service モジュールなどを利用することで対応してきましたが、高い需要を考慮しコアで対応する必要性に応じSymfony2 の リクエストオブジェクトの利用によりこれを実現することになりました。
Context
Panels の context, また Context モジュールのように、特定の条件（またはコンテキスト）において振る舞いを変える仕組みの有用性が理解されると同時に、この仕組みの統一化が求められました。
コンテキストを統一化するためにはこの機能をコアに組み込むことが望ましく、また Drupal が現時点で利用していない HTTP header フィールドをコンテキストとして利用する必要性が挙げられました。Symfony2 ではそれが既に可能であることから、同フレームワークの利用は、その機能を自前で開発するよりも効率が良いというメリットがありました。
また、Drupal はブロック、ページコールバック、メニューなどそれぞれが API レベルで異なる扱いになることで、無駄に敷居を高くしているという問題がありました。すべてをブロックとして扱い、アウトプットの方法を統一することでこの問題を解決する方法が提案されました。
最終的にこのイニシアティヴは Blocks & Layouts Everywhere Initiative (http://groups.drupal.org/scotch )というかたちで独立しました。
また、既に広範に利用されているフレームワークを採用することで、新たな Drupal 開発層を広げることができる、という利点についても Dries は彼の Drupalcon Denver のKeyノートで触れています。
蛇足ですが、Larry がイニシアティヴを WSSCI （ウィスキー）と命名したので、Blocks & Layout Initiative のグループ URL が 'scotch' となっています。
皆さんありがとう
Shin-gdo_Jさん
僕もphpは勉強中で、仕事ではＩＴ関連がないため、フレームワークは興味事項でした。
drupal7を少しをハック（フック）したいのと、他のXOOPS等OSSを弄ってきたのでphpの技術は今一なのにそこそこフレームワークというものを知っています。
簡単にいうと、フレームワークは同じコードを何度も書かないようにべたコードをクラスライブラリ化したり、ＭＶＣにしたりということだと思います。
XOOPS3はzend frameworkで開発しているのは知っていましたが、Symfony2はphpbb4、openPNEがすでに採用し、ezpublishも新バージョンで採用するみたいで、drupal8も採用するとしったとき、Symfony2にとても大きな興味がわきました。
僕は、drupalの掲示板モジュールは今一だと思っているのですが、同じMVCを採用するphpbbと連携なんかができるんじゃないかなと想像します。
openPNEはmixiっぽいSNSですけど、オーガニックグループとは別のSNS選択しでも使える気もします。
そんな意味でもSymfony2を勉強したほうが良いかなと思ったところです。
Masa Nishio and dokumori さん
和約、要約とてもわかりやすくありがとうございました。
技術の細部は知識がなくわからないんですが、大きな流れはすっきり理解できました。
drupal8は大きな変化を生みそうですね。
dokumoriさん、日本語版ドキュメント作成もどうなんでしょうかね、良い意味で暗礁に乗り上げられそうですね。
Pluginシステム
Masa Nishioさん、dokumori さん、ためになる情報ありがとうございます。
Drupal8は期待通り大幅に変化しそうですね。
非常に楽しみですが、コードフリーズが予定通りに行われたら逆におどろきですね。(^^)
どなたか興味がある方がいればお聞きしたいことがあります。
最近D8にPluginシステムが提案されているとか。
どのような概念でその意義ってどんなところにあるんでしょう？
Drupal 8 Plugin architecture | drupal.org
Introduce Plugin System to Core | drupal.org