Catalystでモバイルサイト開発に挑戦してみることにした。
- Catalyst初心者
- DBIx::Classは多少単独で使ったことがある
- HTML::Templateは使ったことあるけどTemplate::Toolkitは未経験
- Encode::JP::Mobileは大体理解した
- Ruby on Railsはがっつり開発したことはないが概念くらいは知ってる
という条件で、今月中くらいでモバイルサイトを開発してみることになった。果たしてできるのか？！
既存のオリジナルフレームワークはあるんだけど、どこかで一念発起してトレンドを吸収しておかないとね。
この本と、ITproの記事をテキスト代わりに、Catalyst::Manualを傍らにナメていけばそれなりに吸収できるかな。
と、思っていたら、この辺りの記事は古いのね。。
Catalyst::Plugin は、現在では*基本的に*利用/開発が推奨されていません。おりしも、この記事が公開される数日前に
CatalystCon#1 が開催され、Catalyst::Plugin のあり方について周知しようという Perl Mongers の動きがあった中で、
このようなふるい記事がでたこともあって、タイミングが悪かったというところもあります。
＃ Perl がよくわからない人のために解説しておくと、2008年に gets(3) を使うサンプルコードが公開されたようなもの
えええ、じゃーまるで役に立たないの？
そのへんの事情は http://search.cpan.org/dist/Catalyst-Manual/lib/Catalyst/Manual/ExtendingCatalyst.pod#Plugins にのってるよ。
ふむふむ。という訳で該当箇所をよく読んでみよう。
The first thing to say about plugins is that if you're not sure if your module should be a plugin,
it probably shouldn't. It once was common to add features to Catalyst by writing plugins that provide
accessors to said functionality. As Catalyst grew more popular, it became obvious that this qualifies as bad practice.
By designing your module as a Catalyst plugin, every method you implement, import or inherit will be
available via your applications context object. A plugin pollutes the global namespace, and you should be
only doing that when you really need to.
なるほど。プラグインで公開すると、グローバルの名前空間に置かれるんだけど、Catalystがポピュラーになるにつれて衝突する可能性が高いから、本当に必要なときのみ使えってか。
その他にもBEST PRACTICE#Namespacesのあたりにも、
- Catalist::*の名前空間はコア拡張で使用してるから、可能ならCatalystX::*名前空間を使用しなさい
- モジュールのロードの際トラブルの元になるので、MyApp::Controller::Fooみたくモデルやコントローラー・ビューにベースクラスをMyAppディレクトリ以下に直接置かずに、MyApp::Base::Controller::* や MyApp::ControllerBase::* みたいな名前空間を使いなさい
とか書いてあるね。
でも逆を返せばこれらだけ気をつければ前述の本やITproの記事はそこそこ参考になりそうだ。
それにしても・・Ruby on Railsとかもそうだったけど、仕様の陳腐化が早いなぁ・・Railsは本まで出てるのに、今売ってるのじゃ既に古すぎたりするし。
社内でスキルの拙いメンバーに積極的に使わせて開発を進捗していくのはまだまだひと苦労もふた苦労もありそうだなーー。。。
