U2Aインデックスについてのあれこれと、他の機能拡張メモ。
少し落ち着いて、ACLの権限リストやpolicyの評価の仕組みについて考えてみました。結果として、ACLキャッシュという、yb直下に配置されるべきキャッシュクラスが浮かび上がりました。また、ACLキャッシュの機能や、どのタイミングでキャッシュが無効となり、どのように更新されるのかもおおよそ詰めることができました。付随して、グループIDから、そのグループを権限リストに含むACL ID群を取得するG2Aインデックスが新たに追加されます。
YakiBikiメモ/2007-10-31
http://www.glamenv-septzen.net/pukiwiki/index.php?YakiBiki%A5%E1%A5%E2%2F2007-10-31
これの流れでACLのDaoに何点かショートカットメソッドを追加します。あと、それとは別で幾つか機能追加。
ACLのDaoへ追加するショートカットメソッド
権限リストに、{ group | user } id と アクセスレベルのペアを簡単に追加 | 削除できるメソッドが必要になりました。
こんな感じ。
$dao =& new yb_dao_Acl(); $dao->addPermission(TYPE_USER, $user_id, $access_level); $dao->removePermission(TYPE_GROUP, $group_id, $access_level);
幾つか機能追加
- バージョン情報に、コメントを追加。履歴表示で将来、確実に必要になることが既に充分自明です。
- データ本体に対する"メモ"情報。要するに「編集ノート」みたいな扱い。appendオンリーで、ユーザーID, テキスト, 日付で充分でしょう。特にバージョン管理も不要です。data_id.memo みたいなファイル名で。
- 名前検索インデックスに、「完全一致(fullmatch)」検索メソッドを。Wiki形式で、ページ名からリンクを生成する・・・のが必要になるのかは分からないのだけれどもし必要になればこれが無いと不味いし、まぁ、普通に検索のオプションとして合っても不自然じゃないし。
- バージョン情報のコメントや、メモ情報の追加に伴い、複数行文字列を一行にするencode/decode関数をyb_Utilに追加。まぁ・・・pack()/unpack()でも良いのだけれど・・・旧memoriesで使ったタブ・改行記号のencode/decodeロジックをそのまま持ち込んでも構わないといえば構わないだろう・・・。
で、今後の予定。
今週から来週で、ここまでの機能の実装を目指します。ACLキャッシュと、幾つかの拡張・修正。その後ですが、当初は"Service Layerから作る"とかほざいていたんですが・・・。作る画面数をできる限り減らしたい為、Web側の機能を相当、削り落とします。
たとえば、「新規登録はこちらから」リンクや画面。えっと、確認メールの送信と、記載してあるURLアクセスでユーザー登録完了・・・というのが面倒くさい為、この機能は削ります。つまり、利用者が任意でユーザー登録できる機能を削り、管理者だけが管理メニューから手動でユーザーを新規作成するだけに留めます。
次。Web上でのインストーラ機能を削除。まぁ・・・当初から、せいぜい「各種ディレクトリのアクセスチェック」「管理ユーザーの初期登録」位しか考えてなかったんですが、それすら削ります。じゃぁどうするか?
コマンドラインツールから手動。
すごいですね。沢山のレンタルサーバユーザを無視してますよね。傲慢ここに極まれりですよね!!
・・・でも、でも、勘弁して下さい・・・。なるべく早く、動く最初のバージョンを「見せなければ」ならないので、それに不要な機能は削り落としたいのです。要は管理者がそれ相応の技量を有し、自力で色々扱える・・・ええ、そうです。自分が最低限度動かせる程度に留めようというわけです。
また、ユーザーが任意にグループに入会・退会する機能も実装しません。ユーザーとグループの管理は完全に、管理者任せ。
- テーマ機能も実装しません。
- 多言語対応もしません。そうした機能は一切考慮しないディレクトリ構成で進めます。
- Smartyのテンプレートはとりあえず英語で作っておきます。
- 入力項目のチェックを実装しません。全部素通しです。というのも、エラーメッセージなどで多言語対応が絡んだりしてきますし、HTML_QuickFormがどう絡むのかが未知数ですので、省略です。
- エラー処理は一切実装しません。
- ロギング処理も一切実装しません。
0.0.1を使うのは、当面は作った本人である自分しか居ないので、この程度でも大丈夫です。
また、SVNへのコミットポリシーも変更します。今まではテストケースがpassすることを条件にしていましたが、HTML画面やセッションCookieの情報なども絡んでくる為・・・Seleniumを勉強する暇を、今は惜しみます。ということで、そのあたりの作業中は、コードがものすごい不安定になります。まぁ、区切りの良いところでcommitすることは変わりないでしょうし、区切りが良いところはつまり、ある程度動いたということなので・・・すが、いろいろ命名規約とかもばらばら変わったりしていきそうですので、tests/以下もかなり不安定になります。それでも、動くモノが早く出来上がることを最優先します。
・・・すげぇ・・・。ここまで、プログラマとしての美学を捨て去るか・・・。