の作業記録
メモツールを作る火曜日
- 作業記録の共有
- Textbox+メモツール開発
8:00
おはようございます。本日はTextbox上のメモツールを作成してみます。
Textbox:
メモツールのモックアップは現状こんな感じ（機能はまだ無し）。
中央にエディタというかメモ記録領域があり、下部にメモ入力欄がある。ここに入力したものが上部に追加されていく、という流れ。これはもしかしたら配置が逆の方がいいかもしれない。つまり、Twitterのように上部に入力欄があり、下部に追加されていく、という形。どちらがいいのかは要検討。
で、右側には「カテゴリー」リストがある。これはハッシュタグをベースに自動的に生成されたらいいなと思う。トップダウンで作るのではなく、ハッシュタグの動向を見て生成される、という感じ。Twitterのトレンド的な感じだろうか。
で、今考えているのは左側。このまま空けておいてもいいが、何かしら表示させたい気持ちもある。で、表示させるとしたら何がいいか。
＊ ＊ ＊
たとえば何かしらの「ウィジェット」を表示させる手はあるだろう。名言を一つ表示させるとか、勉強した英文を表示させるとか、本を一冊表示させるとか。今日の予定みたいなものでもいい。日付と時刻、あるいはタイマー機能といったこと。そういうのを適宜配置できる、というような。
この状態だと一番下のスペースが空白になるので、そこに何かしらの情報を表示させてもいいかもしれない。エディタのように。
とりあえず、モックアップで表示領域だけ作ってみよう。
＊ ＊ ＊
配置のバランスはよくなりましたね。
＊ ＊ ＊
org-agendaは何を表示するか。
- スケジュール・予定・〆切り
- todo
よくあるwidgetは何をするか。
- 計算機
- ニュースリーダー
- スケジュール管理
- 天気予報
- ウェブカメラ映像の表示
- 簡単なゲーム
- 株価チェック
- iTunesのコントロール
＊ ＊ ＊
動作の設計。
ボタンをクリックするか、command + enter。
その後、
- Textareaの中身を取得して、保存されているデータに送信する
- 単純にHTMLに追加する
前者の場合は、常にデータが本体側にあり、その操作をページ側で行うことになる。一方後者の場合は、保存する際に、HTMLのデータを変換して保存することになる。データそのものをまるっと上書きする。その意味で、表示されているそのものがデータで、ファイルへの保存は一時的な保存（次に参照するときに取り出せるようにする装置）、くらいの意味合いになる。
話しとしてややこしくないのは後者。特に、他の端末で編集するつもりがないならそれで十分ということもある。最悪、HTMLをそのまま保存しておいてもいい。テキストを並べてあるだけなのだから、簡単と言えば簡単。
ページの中に読み込んで、あとはイベントなどを付与すればいい。
＊ ＊ ＊
当初は、JSONで保存することをイメージしていた。そうすることで、他のファイルなどでも参照できるようになる。しかし、その動作はどれだけ必要だろうか。
単純にテキストファイルにしておく、というのも一つの方策ではないか。
その場合、たとえばハッシュタグからカテゴリを生成する、というのはどうなるか。json方式だと各行に対してメタデータが与えられるか、新しいものの重みづけを増やす、ということは可能になるが、普通にテキストを並べているだけではそうはいかない。
そうすると、単純な出現率、項目のどこに位置しているかだけがパラメータとして使える。項目の登場順は操作がなければ作成日順に合致するが、移動できるようにするとそれも崩れてしまう。
ただ、ボタンを押したときに、ハッシュタグのデータだけ別に取っておく、ということは一応できる。ふむ。
＊ ＊ ＊
bike oulinerは、テキストファイルのデータからアウトライナーを立ち上げている。dynamic documentもテキストベースに、機能を付与するという考え方だった。
その精神を継承してみようか。
＊ ＊ ＊
HTML要素として追加する機能は実装できました。
で、mdファイルをテキストファイルとして、マークダウン変換するのではなく、そのまま読み込む機能もつけました。
ただし、現状は各行をli要素にして、ページにあるUlにappendしている形です。こうするとHTMLで行単位で扱いやすくなります。その代わり、編集もろもろがややこしくなりますね。
普通にdivの中に、そのまま挿入してもいいでしょう。その方が、自由度はあがります。ただし、操作はかなり面倒になると予想。行を一つ上にあげる、ということすらたぶん厄介です（div内でbrタグで改行されているだけの一つの塊なので）。
ここは考えどころですね。
ポイントは、行単位の操作とブロック単位の操作です。上記のようにまとめて入れると行単位の操作が難しくなります。あと、単にliをフラットに並べているだけでは「ブロック」が作れません。そのためには子要素にする必要があり、それがまた面倒です。再帰的な探索が必要になる。
その行の行頭にスペースないしタブが入っていたら、その行を上の行のブロック内として扱う、というやり方。それをどうにか取り入れたいところ。
＊ ＊ ＊
子要素にせずに、単にbr 付きのtextContentにする？
子要素にしてインデントしない？
brつきだと、ブロック単位の移動はできても、その行だけの操作はきわめて難しくなる。
子要素にせずに、インデント用のclassを付ける？
＊ ＊ ＊
子要素にせず、タブやスペースの個数分を示すclass（たとえば level1,level2など）を付け、それでインデントを制御する方法でやってみましょう。
＊ ＊ ＊
データを取得するときに、行番号を割り振っておき（idにでもする）、その行の変更だけを追いかけられるようにする？ しかし、移動するとどうなるか。いや、行番号方式なら行単位の変更も追従はできるか。ただ、ファイルへの反映が面倒か。やっぱり、全体として保存したほうがいい。
保存は、どのタイミングで行うか？ 明示的？それとも何かしらの処理がトリガーで自動的に？
保存するときには、対象のULの子要素をすべて取り出して、そのtextcontentを保存する。class名から挿入するタブを判断する。もともと半角スペースだったものがタブ（ないし全角スペース）に変換されてしまうが、これは仕方がない。行データからliに変換するときに、含まれていたのがタブだったという情報もセットで保存しておけば一応再現も可能ではある。