私のGeeklogのMVC的使い方（WebAPI化）
この記事は次のブログに引っ越しました。
GeeklogをWEBサービス的にAPI化する 2013/09/11 追記：5年半前の記事ですっかり放置していたのですが、なんと恐れ多くもGeeklogのivyweさんからコメントをいただきました。m(_ _;)m ガクガクブルブル（記事下部）すっかりKEINOSはGeeklog離れしていたのですが、その後もGeeklogの活動は続けられており、昨今のWordPressのセキュリティ問題も多いことから、Geeklogを再考するのもアリかも。記事にある重かったのって単純にロリポップのSQLサーバがダメダメだっただけで、5年前と比べてデザイナ（兼HTMLコーダーさん）もテンプレートの役割もわかって来ているし。もう一度見直してみよう。 Geeklogってテンプレートのメンテナンスというかカスタマイズというか、全体的に改修しづらい。 しかもロリポップのMySQLのサーバで外れを引いてしまったのか、遅い。いやー重い。それでも、そのセキュリティに対するこだわり方が気に入ったので、トレードオフと割り切って、とある環境で使ってみることにしたんです。 Geeklogの情報もIvyさんたちが精力的に発信してくれて情報も多いのですが、記事のタイトルにすべてサイト名が頭に付いているため検索しづらかったり、サイトが崩れて見れなかったり、説明がデザイナさんではわかりづらかったりで、その都度「どういうことか」と聞かれそうなのも大変でさ。かといって情報を見つけてもらったところで、結局GeeklogではPHPができる人でないとデザインに柔軟性がないことを実感したんです。でも、その管理機能としてはプラグイン好きなワタシとしては満足していたりします。ただね、実は毎月デザインを変えないといけない環境で利用しているんです。(T_T)/~~~ 自分が言いだしっぺなんだけども。でも、やっぱり流行というかMVCモデル的に管理したいじゃない？クールにさ。そこで、Geeklogはフロントエンドとしてではなく、コンテンツの管理用だけに利用しています。そして表示は別システムで行っています。これは、コンテンツ管理のシステムをGeeklogから他のCMSに（XOOPSでもMTでもなんでもいいんだけど）移管したとしても、フロントエンドを変えなくてもいいようにという意味もあるんです。 Geeklogのデザインを完全に独立させる 実は、上記の「別システム」がフロントエンドとして機能（デザインに特化）していて、やっている仕組みは簡単。View（表示）
フロントエンドにSmartyを使って、デザイナさんが管理しやすい環境を作る。Controller（管理）
Modelに表示したい記事のIDをリクエストして、返ってきたデータをViewerに渡す。Model（データ）
GeeklogをWEBサービス的にAPI化させて、リクエストされた記事IDの記事データを返す。ほら、結局、記事に必要な最低限のデータって、タイトル 概要(description) 本文(contents) 更新日 作成日 程度じゃない？それを基準に上記のように機能をわけたんです。トラックバックとか、記事に記載された画像とかリンクとかの処理も必要だけど、URLも決まってるから置換でなんとかなるし。Smartyも、ロリポップで標準で使えるテンプレートエンジンだし、何より昔から使いまわしているクラスを利用したくて。 もぅチト、詳しく説明すると WEBサービスにおけるAPIの基本としては、POSTなりGETなりでリクエストを受けると、その結果を特定フォーマットで返す（表示する）というシンプルなもの。そこで、Geeklog側のstory.phpをカスタムして、storyのID（記事ID）をPOSTでリクエストを受けると、記事の表示に必要なデータだけを配列に入れてserializeしたものを返しているだけです。参考文献：Yahoo曰く、XMLじゃなくてPHPの変数をそのままシリアライズして返せばいいじゃん file_get_contentsでPOSTデータ送信 でも、せっかくのセキュリティに強いというGeeklogなので、ここで穴を作っちゃうのもナニだから、このカスタムしたGeeklogのstory.phpにベーシック認証をかまして、データもPEARのCriptを使って暗号化しています。なんとなくその方がカッコイイかなと思って。リクエストする側（Controller)は、file_get_contents()関数でstoryIDを上記のなんちゃってAPIに投げて、その返って来たデータをDecriptして、unserializeして配列に戻します。 これをテンプレートに流す。これだけ。もう気分はWEBサービスのAPIっすよ。えぇ。でも、これでView（Smarty）側でキャッシュをONにして劇的に表示が軽くなりました。都度GeeklogがMySQLをほじりに行かなくなるので。また、デザインの管理もしやすくなったし。ControlerはAPI経由でデータを受け取るので、GeeklogからオリジナルのCMSに移管しても大丈夫な準備もできた。最後に けど、最初からこの仕組みを考えてた訳ではなくて、Geeklog導入後、運営上「チーッとやばいかもかも…」という懸念が出てきたからなんです。気付いたらMVCモデル的な仕組みになって、「お、MVCモデルになってんじゃん」と棚ボタ的に記事を書いてみました。この記事が保守のための情報になれば、これ幸いです。
フロントエンドにSmartyを使って、デザイナさんが管理しやすい環境を作る。Controller（管理）
Modelに表示したい記事のIDをリクエストして、返ってきたデータをViewerに渡す。Model（データ）
GeeklogをWEBサービス的にAPI化させて、リクエストされた記事IDの記事データを返す。ほら、結局、記事に必要な最低限のデータって、タイトル 概要(description) 本文(contents) 更新日 作成日 程度じゃない？それを基準に上記のように機能をわけたんです。トラックバックとか、記事に記載された画像とかリンクとかの処理も必要だけど、URLも決まってるから置換でなんとかなるし。Smartyも、ロリポップで標準で使えるテンプレートエンジンだし、何より昔から使いまわしているクラスを利用したくて。 もぅチト、詳しく説明すると WEBサービスにおけるAPIの基本としては、POSTなりGETなりでリクエストを受けると、その結果を特定フォーマットで返す（表示する）というシンプルなもの。そこで、Geeklog側のstory.phpをカスタムして、storyのID（記事ID）をPOSTでリクエストを受けると、記事の表示に必要なデータだけを配列に入れてserializeしたものを返しているだけです。参考文献：Yahoo曰く、XMLじゃなくてPHPの変数をそのままシリアライズして返せばいいじゃん file_get_contentsでPOSTデータ送信 でも、せっかくのセキュリティに強いというGeeklogなので、ここで穴を作っちゃうのもナニだから、このカスタムしたGeeklogのstory.phpにベーシック認証をかまして、データもPEARのCriptを使って暗号化しています。なんとなくその方がカッコイイかなと思って。リクエストする側（Controller)は、file_get_contents()関数でstoryIDを上記のなんちゃってAPIに投げて、その返って来たデータをDecriptして、unserializeして配列に戻します。 これをテンプレートに流す。これだけ。もう気分はWEBサービスのAPIっすよ。えぇ。でも、これでView（Smarty）側でキャッシュをONにして劇的に表示が軽くなりました。都度GeeklogがMySQLをほじりに行かなくなるので。また、デザインの管理もしやすくなったし。ControlerはAPI経由でデータを受け取るので、GeeklogからオリジナルのCMSに移管しても大丈夫な準備もできた。最後に けど、最初からこの仕組みを考えてた訳ではなくて、Geeklog導入後、運営上「チーッとやばいかもかも…」という懸念が出てきたからなんです。気付いたらMVCモデル的な仕組みになって、「お、MVCモデルになってんじゃん」と棚ボタ的に記事を書いてみました。この記事が保守のための情報になれば、これ幸いです。
