そもそもハッシュテーブルとはなんぞやと

開発

一応、基本情報秘術者の資格持ちなんだが改めて調べてみる

http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB

これがないとファイルが読み込むことが出来ないというか不具合起こすのは理解した。
問題は、adminからpcに実行ファイルを移行させた際、どうやってこの関数を読み込ませるかということである。
adminではlibに外部クラスで置いとくと読み込んでくれる（hash_admin.php）っぽいが、何故かpcだと認識してくれないんだよなぁ。

新たなバグはっけん

開発

ためしにフリーページをたくさん、管理側から２０以上になるように追加すると表示がおかしくなるのを発見。

これは

({$pager.total_num}) 件中 ({$pager.start_num}) - ({$pager.end_num})件目を表示しています
</p>
<p class="listMove">
({if $pager.prev_page})
<a href="?m=({$module_name})&amp;a=page_({$hash_tbl->hash('list_c_free_page')})&amp;page=({$pager.prev_page})&amp;page_size=({$pager.page_size})({$cond})">前へ</a>&nbsp;

の部分の{$hash_tbl->hash('list_c_free_page')}が影響しているとおもわれる

やっぱりネックはhash（）関数かぁ・・・
list_c_free_pageに内在するようにソース書き換えるのが一番なんだろうけど（他のadmin関連の関数はそうやって動作させてます）、一度それやってみたが上手く動いてくれなかったんだよねぇ。

いや、まてよ？

開発

hash()参照先データが
update_c_free_pageになってるてーことわだ。

update_c_free_page.phpが何らかのバグ起こしてる可能性大ですわね

とりあえず帰ったらそのあたりを調べて見やう。

・・・で、リビジョンの件どうしよう。

wikiの構造とか色々調べべてるけどいまいちわからんちん。
CVSとか差分法とかが参考になりそうですが・・・

発想を変えてだな

開発

hash()関数をどうこうするより、別の関数でデータ保存を検討した方が早いような気がしてきた。
wiki風にするならリビジョン（履歴）機能も必要だろうし

・・・が、ちょっと待て。
そうなると元データが管理側の「フリーページ管理」で削除修正できなくなるじゃないか。

うーむ・・・