Categories
open all | close allTags
パソコン | Aptana | ドキュメント | 認証 | Migration | rake | フォーム | OpenID | 国際化 | 名称 | タグ | スキンエンジン | デュアル・コア | モデル | CSRF | RESTful | アクセス制御 | テスト | Flash | SubversionSearch
«Prev || 1 || Next»
思いつきメモ（アイテムやカテゴリーとスキンの紐付け）
アイテム単位でスキンを指定できるとちょっとうれしいかなと思いました。きっかけは卑近なところですが，メインのブログの方で毎月のトップアクセスの記事をまとめているときのことでした。毎月上位に来る記事というのは割と決まっているので，そこが一種のポータル的な役割になるようにページを変えられないかと思ったのです。GoogleのAdSenseなど，内容で広告を動的に変えるものはありますが，全部が自動的に最適になってくれるわけではないし，NP_Relatedみたいなブログ内の関連記事を自動的に探すのもちょっと限界があります。そこでアイテム単位でスキンを変えられると，もっと柔軟な対応ができるかなと思ったわけです。
Twitterでつぶやいてみたところ，カテゴリーもほしいという声も。確かにスキン中のifで制御できるとはいえ，大きく変えたい場合は別スキンに書けるとすっきりしそうです。
実装は二つ考えられます。一つはアイテムやカテゴリーにスキンIDのフィールドを作ること。モデル実装上はこれがきれいで，Nucleus互換エンジン以外にも対応できますが，アイテムごとにまるまる新しいスキンを置くのはかなりおおげさな感じがします。メインと同じスキンの上でできた方が作りやすい。
そこで考えたもう一つの実装はスペシャルスキンパーツを使うもの。例えばitem_333というスペシャルスキンパーツがあったら333というアイテムの表示のときにそれを使います。使い回しはちょっとやりにくくなりますが，それほど多用するものでなければ，これがよさそう。同様にcategory_17などとするとID17のカテゴリー表示にそれを使います。タグも同じようにできると思います。この実装はNucleus互換エンジンだけの機能になってしまいますが，今はこれで実装するつもりです。
思いつきメモ
スキンについての思いつき。Google Groupsに書いたら思い切り文字化けしたのでこっちに転載します。Foodynのスキンにはデータセットという概念があります。例えば
<%dataset(5)%>
とすると，そのページにはアイテムを五つ表示するということになり，ブログやページスイッチでは指定が不要になります。
<%blog(template)%>
<%pageswitch(template)%>
で済んでしまうわけです（templateも省略できますが）。
名前を付けることもでき
<%dataset(name,10,blogname)%>
みたいなことができます（今のところブログ名部分は未実装ですが）。
こうすると，先ほどの指定も
<%blog(template,name)%>
<%pageswitch(template,name)%>
となり，名前付きでないページスイッチと同一ページに共存できます。
データセットの機能は，暗黙的にも使われており
<%blog(template,10)%>
と書くのと
<%dataset(10)%><%blog(template)%>
と書くのは内部的には同じことです。
というわけで実は<%otherblog%>というのはもはや不要だったりするのですが，それはそれとして今日書くのは別の話。
ブログの表示を2段組にしたいとか，トップ二つの記事は要約を付けて，後はタイトルだけにしたいとか（ニュースサイトのように），そういう希望にも応えられるようにしたいと考えています。そのためには同じデータセットの中で表示するアイテムを分割指定できるようにする必要があります。
と，ここまで考えたのですが，どういう指定法にしたら柔軟，かつ簡単に使えるかというところでちょっと思考がストップ中。アイディアをお待ちしております。
サイドバーのウィジェッツ化実装の考察
管理画面のロジックとデザインをできるだけ切り離そうと作業中なのですが，案外難航しています。忙しくて一週間ほど全くプログラムできなかったのもあるのですが，もうちょっとかかりそうです。それはそれとして，アイディアレベルの話ですが，サイドバーをウィジェッツ化できるようにしたいと思ってます。実装としては，
①スキンの中に<%sidebar%>というスキン変数を置くことで，そこがウィジェッツ対応になる。ただし，これはインクルードファイルではなくスキンパーツ（レイアウト含む）の中にないといけない
②<%sidebar(left)%>みたいに名前も付けられる。複数置くときは名前が必須（一つは空でもいい）
③このスキン変数の自体はスペシャルスキンパーツで名前がsidebar(名前付きの場合はsidebar_leftのようにアンダースコアでつなげる)
④標準スキン変数でサイドバー対応のものはパーサのクラスで sidebar :categorylist のように宣言する
⑤これらのスキン変数のために call_categorylist のようにメソッドを用意（なくても動く）。このメソッドはサイドバーで使う名前を返す。メソッドがない場合はcategorylistを言語ファイルで変換
⑥プラグインの場合は event_sidebar を実装することでサイドバー対応になる
⑦event_sidebar はウィジェッツの名前を返す
⑧スキンパーツの編集画面からそのスキンパーツ内のサイドバーを編集する画面を呼び出す
⑨ドラグアンドドロップで編集できる
⑩ウィジェッツの実体は
<div class="sidebar"><h3><%text(プラグイン名)%></h3><div class="プラグイン名"><%プラグイン名%></div></div>
つまり，ウィジェッツ対応のスキンはCSSでクラスsidebarを実装する必要がある。
このほか，対話的にパラメータを変える仕組みを入れたいと思っていますが，そこはまだ詰めていません。
ページスイッチ部分の仕様
Foodynの公開をしてから，そういえばカテゴリー部分のクエリーを実装していなかったことに気付き，作業中です。それだけならたいした手間ではないのですが，以前から頭のどこかにあったページスイッチ部分を実装しようかと思い，遠回り中です。ページスイッチは，NucleusだとShowBlogsが生成するものをそのまま使っている人が多いと思いますが，ここのページにあるようないろいろなデザインができないのが残念なところ。また，配置もアイテム表示の直前か直後に固定されてしまいます。
ページスイッチを表示するスキン変数を別途用意すればいいのですが，表示内容の指定などをblog変数に合わせないといけません。そこで，Foodynではデータセットという概念を導入して，二重指定を不要にしようと思っています。ページスイッチのスキン変数かblog変数かどちらか先に指定したものの表示内容（1ページに表示するアイテムの数など）をデータセットとして，他方はデータの指示なしに表示できるようにします。表示機能なしで，データセットの指定だけするスキン変数も用意します。
頭の中では，この機能を応用して，1ページ内に複数のページスイッチを別の用途で置けるようにする実装もできているのですが，ちょっと面倒な点がいくつかあるので，後でやることになると思います。
なお，テンプレートのデフォルト値やインライン・テンプレートのアイディアはページスイッチのスキン変数を考える際に思いついたもの。脈絡ないようですが，実はあるのです。
テンプレート機能を使いやすくする
Nucleusの柔軟性を高めているのと同時に分かりにくいと言われる原因でもあるのがテンプレートのところだと思います。一つのテンプレートの中にも，アイテム表示に関連する部分，カテゴリーリストに関連する部分，コメントに関連する部分，画像表示に関連する部分など，いろいろな部分があることがさらに分かりにくさに拍車をかけています。Foodynでは二つの新しい機能を使ってこの部分を少し使いやすいものにしようと考えています。一つはデフォルト機能。「conifg/default_template.yml」というYAMLのファイルを用意し，それに各テンプレート・パーツのデフォルト値を置けるようにします。これによって，テンプレート指定なしでも，全く表示がないといったことがなくなります。
もう一つはインライン・テンプレートの機能。どちらかというとプラグインなどからの利用を想定していますが，YAMLの表記ルール（あるいはJSON）を使って，ユーザーが利用できるようにすることもあり得るでしょう。これはデータベースにテンプレートを入れなくてもテンプレート機能を使えるようにするもの。例えばプラグインからパラメータによって，テンプレートを変えて出力するといった使い方が簡単にできるようになります。ユーザーレベルではスキンにこれを記述できるようにすると，テンプレートなしで書けるようになります。そちらは実装するかどうか未定。
管理画面設計中
とはいっても，まだやっているのはフリーの管理画面デザインをRailsのヴューに当てはめているだけ。中身はまだ空です。それとは関係ないけど一つメモ。Foodyn CMSは複数ユーザーで安全に運用できることを目指していますが，スキンの扱いで一つ考えなければいけないところがありました。例えば，あるユーザーがスキンを選んでカスタマイズする場合，それは他のユーザーには波及しないようにしないといけません。つまり，ブログごとにスキンの複製を作ってからカスタマイズすることになります。また，こういったスキンはブログを消去した際に一緒に削除しないといけません。
Foodynでは，スキン･エンジンごとにduplicateを使うかどうかを設定できるようにしようと思っています。まだその辺の処理は組み込んでいませんが，一応覚書として。
スキン・エンジンの仕様・実装メモ
現在のスキン・モデルはNucleusのDBベースのものしか取り扱えない。これをファイルベースのスキンなどにも利用できるようにする必要がある。ユーザーからするとスキンは名前で指定するだけだから，今のスキン・クラスとは別に統合的にスキンを管理するためのモデル・クラスが必要になる。そのクラスではスキン名とエンジン名のマッチングだけを行う。実際にスキンを読み込むところなどはスキン・エンジンの責任になる。今の実装ではスキン・データを読み込むところがコア側にあるので，責任範囲を変えないといけない。つまり，スキン・エンジンはスキン名を与えられたら，描画内容を返すこと，である。またスキン・エンジンは実際の描画を他のエンジンに任せることができる。すなわち，高級言語からアセンブラに変換するようなもので，結果を他のエンジンに引き渡して描画できる。
このようにするには，スキン・エンジンをモデルとして登録する際に，下位のエンジンが何かというフィールドを用意しておけばよい。
スキン・エンジン自体もRailsのプラグインとして登録可能であり，プラグインと同様にスキン・エンジン用のスタブ・クラスを用意する。後の実装はほとんど自由にできるはずだ。
«Prev || 1 || Next»