Pyhaの大体の仕組み

※pyhaはlokkaに名前が変わりました。公式サイトのURL、リポジトリの場所もかわりました。貧弱一般プロジェクト(@ブロントさん)であるpyhaですが、もし興味があるという方ががいれば分り易いようにコードが大体どんな感じなのか書いておこうと思います。(pyhaは名前を見たら殆どの人はpython製だと思うということに大分後になって気付きました・・・) 基本、sinatra, datamapper, hamlです。あとは動かすためのbundlerです。

ファイルレイアウト

ファイルレイアウトはいわゆるsinatraの"Moduler"スタイルで、sinatraやったことがある人だったら、﹁ああ、コレか・・・﹂ってなもんです。

Gemfile      --- bundlerが読む必要なgemの一覧
config.ru    --- rackサーバーが最初に見るファイル
lib/
 pyha.rb     --- 今のところ特に何もしない
 pyha/       --- 基本全部この中。将来的にはgemの中に入るハズ
  app.rb     --- 中心部分。ここ見りゃ大体わかる
  helpers.rb --- rails風のヘルパー以外にapp内でのユーティリティも含む
  before.rb  --- リクエストされたときの前処理
  entry.rb   --- DataMapperのモデル。他にもいくつかある。
public/      --- ドキュメントルート
 admin/      --- 管理画面
 system/     --- エラーとかシステムで使うテンプレ
 theme/      --- テーマ。現状テーマ名=この下のディレクトリ名
  default/   --- デフォルトテーマ。erbでWordPress経験者のデザイナーに優しくをモットーに。
  p0t/       --- docs.komagata.orgのテーマ。hamlでなるべくDRYに書く。プログラマー向け。
plugin/      --- プラグインはsinatra extensionのサブセット
 hello       --- plugin以下のディレクトリ名=プラグイン名
  lib/       --- 各プラグインディレクトリ以下はgem化を見越してgemのレイアウト準拠
   pyha/     --- 一応、pyhaネームスペース以下にする
    hello.rb --- Pyha::プラグイン名というclass or moduleが読み込まれるという決まり

普通のModulerスタイルにhelpersとbeforeを別ファイルにしたってだけです。

テーマレイアウト

テーマ(テンプレートの集合)はWordPressでテーマを作ってるようなデザイナーを想定していて、そういう人がWordPressより一貫した分り易いsyntaxで簡単に書けるように注意しています。

entries.erb(必須) --- 複数のエントリを表示するテンプレート
entry.erb(必須)   --- 1個のエントリを表示するテンプレート
layout.erb        --- 外枠を表示するテンプレート
index.erb         --- トップページを表示するテンプレート
search.erb        --- 検索結果を表示するテンプレート
category.erb      --- カテゴリー別エントリ一覧を表示するテンプレート
tag.erb           --- タグ別エントリー一覧を表示するテンプレート
yearly.erb        --- 年別エントリー一覧を表示するテンプレート
monthly.erb       --- 月別エントリー一覧を表示するテンプレート
style.css         --- CSS(読み込める場所にあればどこでもいい)
screenshot.png    --- テーマ選択画面に表示される画像

必須のモノ以外はそのファイルが存在する場合はそちらを優先するようになっています。例えばentries.erbとindex.erbが両方あったらトップページにアクセスした場合、index.erbが表示されます。また、テンプレ無いでのpartialは好きに出来るのでheader.erbとかfooter.erbとか好きに作れます。また、erb, haml, erubisの3種類のテンプレートが使え、拡張子で判断されます。erb, haml, erubisの順に優先度があり、entry.erbがあるとentry.hamlは使われません。

モデル

モデルはDataMapperのをそのまま使っています。自動的にテーマデザイナー向けAPIに一貫性が出来ます。

entry    --- エントリー。サブクラスは増える可能性あり
 post    --- 投稿。pageとの違いは各種テンプレにデフォルトでassignされてるかどうかだけ(例:@posts)
 page    --- ページ。CMS的に好きなページを作る場合に使う
site     --- このサイト/ブログ自体の情報
user     --- ユーザー。そんなに使わない
category --- ツリー構造を持つ。エントリが持つcategoryはひとつだけという制約があるのはパンくずリストを生成するため
tag      --- categoryの制約が無い。パンくずリストが無ければtagだけでも問題無いんだが・・・
comment  --- いわゆるコメント。どうせdisqusとか使うだろうと思って軽視していた

プラグイン機構

プラグインはSinatra Extensionのサブセット(ココ参照)なので楽です。プラグインの決まりは上記のコードレイアウト通りですが、まだplugin以下に置いてあるものを自動で読み込む処理を書いてません。(すぐ書けるけど貧弱なcoreの改良に忙しいだけです・・・)

クラウド対応ツールとしての注意点

●ファイルのWriteが出来ない環境(GAE, Herokuの殆ど)を考慮する(具体的にはローカルに画像をアップできない) ●RDBだけでなく、KVS, ドキュメント指向DBも考慮する(具体的にはSQL使えない) ●海外に人にも使ってもらうために、publicなところには全て英語を用意する。(commitログ、BTSなど)

その他

WordPressに比べてApache, MySQLが要らないので何気にRubyはWindows環境に向いている。

開発への参加方法

とにかく誰でもwelcomeです。﹁インストールした﹂ってブログに書いていただけるだけでもありがたいです。 ●MLで改善案を言う ●BTSにバグ登録する ●インストールしたとブログに書く。Twitterでつぶやく。 ●githubでforkし、pull requestする ●MLやgithubにpatchを送る ●公式サイト(http://pyha.cc/)のドキュメントを書く(言ってもらえれば公式サイトのpyhaユーザーのアカウントを発行します) ●公式サイトの英語ドキュメントを書く(マジで助かります…) ●テーマを作る ●プラグインを作る基本、コード書いてやってもいいという方にはgithubのコラボレーター権限をホイホイ渡しますのでチマチマpull requestが面倒な方はMLやtwitterでおっしゃってください。

komagataのブログ

ファイルレイアウト

テーマレイアウト

モデル

プラグイン機構

クラウド対応ツールとしての注意点

その他

開発への参加方法

Comments