TransFreeBSDの日記 このページをアンテナに追加 RSSフィード

2006-10-13

[]fswikiでのページのタイトルやタグ、コメント等の(付随|サブ|属性値)データをどう管理/実装するかって話 fswikiでのページのタイトルやタグ、コメント等の(付随|サブ|属性値)データをどう管理/実装するかって話 - TransFreeBSDの日記 を含むブックマーク

色々と考えてみたんだが...:Diary/2006-10-12 - KG.Diaryを読んでのコメントの補足というか続きというか……

なので、このエントリだけ読んでも意味不明だが、リンク先をよんでもfswiki及びそこでのKGさんのプラグインを知らなければ意味不明って事は注意書きとして書いておきます。では本題...

「farmの仕組みを流用して」というのはデータ保存(投稿されたコメント自体)や管理者の編集管理機能(コメント削除など)を行なうためにfarmの(dataディレクトリにサブディレクトリを掘る)機構を用いるという意味です。

ただ、今のfarmとの違い、変更しなければならない所として、

  • 管理者としてログインしなければ不可視(無いもの)として扱われる
  • 管理者としてログインすればfarm的に見える様にする

というのがあります。

ちなみにunixユーザ的には不可視farmの命名則は「.」ではじまるfarm名が良いかと思ってます。

以上はコアから見た視点ですが、次にプラグイン/APIから見た視点を書くと、

という所でしょうか。

この時の「フラット」ってのは、

  • コメントやトラックパック、ページタイトル等をページに付随するサブデータと位置付けて統一して扱う
  • その管理機構はfarmという今ある管理機構統に統合・一般化してあつかう
    • 実際のデータ保存は永続化レイヤ(DefaultStrage等)を経由する
    • 管理者のサブデータ編集は従来の編集機構(UI/code)を利用する
  • プラグインプラグインに特化した/不足した機能を実装する
    • メインの処理
    • フックによるページ改名時の処理
    • 管理ページによる操作
    • 等々

という所でしょうか...

などど書くと大げさに聞こえるんですが、実際はpdfプラグインなどがdataディレクトリとは別ディレクトリを掘るという形で行なっている事を応用しつつ、

  • attachやpdfの様に別ディレクトリをばんばん掘るのはやだな
  • テキストデータなら今のページ編集機構を使いたいな

という発想でfarmってありじゃ?となったわけす。

ま、今の所、机上の空論なわけですけど。

KGKG2006/10/13 23:58あ~なるほど、その考えは賛同できます。ついでに画像も farm へ追いやったら album などの管理に使えそうですね。
最終的には、ほったらかし(笑)の DBIストレージを使おうかと考えてたんで、別のDBファイルにしようかと思ってたんです。.farm を付随データ管理に使えば同様な機能をさらに管理しやすくなりますね。
その内、やってみますかねぇ。

KGKG2006/10/14 00:00そういえば、sandbox に保存したままの例のやつは公開しないのですか?拙作の Image プラグインでもこっそり共有利用しようかと思ってるんですが・・・(笑)

TransFreeBSDTransFreeBSD2006/10/16 12:54返事が遅くなりまして。
例のやつ、公開しようとは思ってますけど、まだ、キャッシュを削除する機構が不完全なもので、それを実装してからと思ってます。
あとは文章と←それが一番不得手だったりする

トラックバック - http://freebsd.g.hatena.ne.jp/TransFreeBSD/20061013