表の基本構成を作るまでなら、このプラグインは結構便利だと思います。
表の縦横構成・セル結合状態まで、のイメージ。
だけど、表の「中身」に凝った修飾をするのは、現実的には結構厳しいです。

案外パターンが多いんですよ、pukiwiki で扱っている書式って。
もちろんそれにあわせて一生懸命解析→コンバート処理を作ることも、ある程度は可能なんですが。 それに加えてプラグインによって生成される部分もあるわけで、そこまでいくとかなり厳しい。

なので、最初の通り：
このプラグインで、まず表としての体裁までは作りましょう。
その後の細々した装飾は、pukiwiki機能で普通に作りましょう。

・・・そんな感じですかね。

ご意見などがあれば。

外部仕様的観点。†

基本的な動きは、先日の日記にも書いたとおりですが。
いろんな兼ね合いで「編集は別window」の実装としました。

• 表データそのものは「別ページ」として設置。
  
  • プラグインの「表示」処理の際には「表データページをインポート」し、加えて「編集開始」ボタンを表示する。
  • 編集開始ボタンは事実上その「表データページの編集」の開始操作になる。
• 編集は「別のWIndowをポップアップ」してそちらで実施する。
  • 当初普通の編集同様に「当該pukiwiki画面を表編集状態に遷移」するようにするつもりだったのですが。
    pukiwiki （＋スキン）とa-tableとがそれぞれ期待するスタイルシートが干渉してしまって、うまくいかなかった。
  • ポップアップする画面は、a-tableのサンプルページとほぼ同じ構造。ちがいは・・・
    • 編集した表に対するデータプレビュー。
      サンプルでは「html」と「テキスト表的」なものでしたが、それらの代わりに「pukiwiki書式」を表示します。
      なくてもいいといえばいいのですが、まあ気分がいいので。
    • 「編集完了」ボタンを新設。これを押すと、以下のように動作します。
  • 編集中だった画面が「編集完了」表示に遷移。
    ここには次のものが表示されます。
    • 「編集完了」メッセージ。
    • 「編集された表データページ」を、実際に表示。
    • 「ボタンを押して元のページに戻れ」メッセージ＆「元ページへ」ボタン。
  • 「元ページへ」ボタンを押すと、今のポップアップをクローズ＆元ページリロード。
    

ざっくり、こんな感じ。

a-tableの友瀬改造部分†

「pukiwiki書式」の出力部分を改造追加しています。
基本的には「テキスト表」ベースですが、以下のような点を追加・小細工しています。

• マージセル
• ヘッダ行セル
• 背景色

現状わかっている問題点†

• a-table と pukiwiki （＋スキン）との間の「表HTML」解釈の差に起因するいろいろ。
  • a-table は「HTMLの書式」を取り込むメカニズムを持っていますが、これは上記「前提となる書式」があって。
    当然、想定とは異なる指定方法をされると、うまく取り込めません。
  • 例えば「セルの背景色」指定。
    a-table ではこれを「セルのクラス名」として指定される想定。
    対してpukiwikiは「スタイル指定」になっている。
    • そのため、pukiwikiで「背景：赤」と指定しても、a-table はそれを取り込めない。
      
    • 逆に、a-table がどういう形で「背景：赤」を認識しているかは友瀬調査の結果わかっていて。
      前述の「pukiwiki書式を出力する改造」にはそれを組み込んでいます。
      そのため、a-tableで背景色指定→出力されるpukiwiki書式には背景指定が入ります。
    • 結果的に「再編集」ができない、という問題を引き起こしています。
      「a-table使用して表編集、背景色つける」操作までは、うまくいくのですが。
      同じページを再編集しようとすると、その（再）編集画面では「背景色が消えている」状態になってしまいます。
  • 同じような問題が「セル内の改行（br）」「レイアウト（右寄せ・センター置き）」である。
    つまりこれらも再編集でアウト。

というわけで、最初に挙げた課題。†

問題点の１つ目に挙げた、「a-table と pukiwiki との間の表HTML解釈の差」をどうするか。
正直、これで迷っています。

アプローチとしては２つ考えられます：
「atableを改造して、pukiwiki HTMLを読み取れるようにするか」
「pukiwikiプラグイン側で編集画面用に a-tableが読み取れるHTMLを吐き出させるか」。

でもどっちも、それなりにハードル高いんですね。
前者は、a-tableを解析しなければならず面倒だし。
後者は、サーバサイドで2重書加工することになり格好悪いし、スキンとの相性問題も起きそう。

ご意見などがあれば。

むにゃむにゃと調べた感じだと、多少の工夫はいりそうですが、いけそうな感じはしました。

利用者（Wiki編集者）側からみたイメージ。†

ブロックプラグイン、以下のような書式。

#a-table(テーブル名<,fix>)

「テーブル名」で指定された別ページから表データを読み込んで表示するのが基本。

ついでに「表編集」ボタンも備える。
これを押すと、「表データのページ」を a-table を使った「編集可能」状態で表示する。

「,fix」オプションを置いた場合、編集ボタンを出さない。これによってうっかり編集は避けられる。

編集画面では「編集完了」ボタンがあって、これを押すと表データが書き換えられる。

プラグイン設計的なところ。†

• 編集可能画面自体は、ものすごくかんたんにできそう。
  • a-tableを使うためのヘッダ記述が必要。
    これはpukiwiki でサポートされている機能で実現できる。
  • 上記を準備しておけば、pukiwikiの機能で作った html をそのままa-table に食わせることができる。
    というか、普通にhtml として表示させればよい。
    • ただし、pukiwikiでの /h(ヘッダ行)指定は、うまく採用されていない。
      
    • a-table とうまく連携するには、セルごとの「~」指定で thタグにしないとならない。
  • その画面に独自に「完了」ボタンを準備して、a-tableプラグインのアクションで拾えばいい。

• 肝になるのが、表形式をpukiwiki書式にするメカニズム。
  ここは新規に作らなければならない。
  • a-table自体の機能としてa-table.js 内に「getTable」「getMarkdown」というメソッドがある。
    これに類似した「getPKWKmark」みたいなメソッドを作るのがよさそう。
    a-table自体に手をいれることになるのが難点ではあるが・・・
    • ちなみに上記「getMarkdown」自体、わりとpukiwiki書式に近い。
      ただし、色やセルマージなどがうまくサポートされていないので、そのままでは使用できない。

ご意見などがあれば。

ものすごく単純にいうと、対応HTMLのバージョンの話。

regionプラグインでは、折りたたみのところに[+] というようなイメージがあります。
これ、HTML的には tableタグを使って描いています。
このレイアウトのために、ピクセル数で幅指定をしています。

で、pukiwiki 1.5系は、HTML5準拠になっています。
HTML1.5系では、この「table での幅指定」がNGなのです。

ブラウザはそんなところ厳密には見ないので、普通に表示できてますけどね。

幸か不幸か、友瀬は divregion というプラグインを作っているので。

近いうちに、こっちに全面的に移行しようかな、とか思ってます。
すでに少し試しているので、あとで問題がないか微調整。

ご意見などがあれば。

ちなみにちょっとgoogleってみたところ、チョコレートの数でいくつかの版があるようです。
友瀬が入手したのは「20ピース」版で、鉄道４、権利書8色ｘ2ずつのセットでした。
他の版だと、これにチャンスカード系のものがつくみたいです。

というわけで、翻訳したルールを。

上記、読めばわかりますが、ゲームのルール自体はかなり運要素が高いものです。
一生懸命駆け引き・取引するゲームってよりは、パーティ的に食べる遊び用、ですかね。

以下、ゲーム観点での分析・・・するほどのことでもないけどさ（笑）

プレイヤーの選択肢が発生するのは「？マークを出したとき」だけなので。
ここが唯一の駆け引きの場所と言える。

？マークは無条件にチョコレート１つを獲得できるので、その時点で有利で。
加えて「他の色/鉄道でのチョコレート獲得」の威力を減らす効果があるので、出せば出すだけ有利・先行逃げ切りしやすくなる。
そしてやっぱり鉄道の「最大4枚」というのがこのゲームの脅威なので。
セオリーは、鉄道から取る、ですかね。

ご意見などがあれば。

PCを使っている方なら実感あると思うのですが、キーボードのキートップは結構消耗・汚れます。
その消耗・汚れ具合は『指の当たり具合』に大きく影響されています。
よく触る部分は磨耗が激しく「てかてか」で、ほとんど触らない部分は「ざらざら」のモールドが残っていて。
で、もっと触らないところは「べたべた」・・・というほどではないですが、まあ手垢汚れもついている。
Enterやスペースといった『大きな』キーだと、てかてか＆ざらざら＆べたべたが混在して、境界部分がくっきり見えたりする。

で、友瀬のキーボード、正確な購入時期は忘れましたが、少なくとも10年以上は使ってきた代物です。
キートップは磨耗しまくりで、文字が読めないキーも結構あります。
ブラインドタッチを正式に訓練したことなんかない身ですが、これで困った記憶もないので。
俺流なりにブラインドタッチできてるんだな〜、と改めて思ったり。

ただ『やっぱり俺流だよなあ』と思うのが、ホームポジションの話。
本来のスジから言えば「F」と「J」がホームなので、ここは相応に「触れられて」いるべきなのですが。
実際には、さすがに手垢はついていないですが、わりと「ざらざら」で。
その代わり「D」と「K」がてかっている。
友瀬はいわゆる「WSADのFPS的ゲーム」はやっていないですし、ローマ字入力だと「D」の頻度は低い。
ですから、「D」の「てかてか」はまず間違いなく「ホームポジション」ゆえなんですね。
「K」はローマ字入力ではそれなり多用されるのでそっちの原因もあるでしょうが。

面白いものです。

ご意見などがあれば。

• よく考えたら、Dは「だ行」でそれなりに使うわ（笑）
  でもまあ、テカリ具合からみてもちょっとそれだけでは説明できないレベル。 -- ともせ＠管理人。 2018-03-15 (木) 06:34:37

tweetcard プラグインは、Twitterが提供している「当該ページURLをTweetすると、カード状になる」機能を実現するもの。

例えば友瀬の2/6の日記にはこのカードが設定されている。
なので2/6のページを表示して、そこで「Tweetボタン」を押してつぶやくと、こんな感じになる。

tweet

ここまでは問題ない。

問題なのは、友瀬の「過去日記」のような「複数のページをまとめて表示」するケース。
例えば「2018/02」分の日記を表示すると、「2月分」のページURLに対して「2/6のカード」が追加されてしまう。
これが美しくない。

スジから言えば、こういう「複数記事を一覧」する際には、カードは「一覧ページのカードだけ」が設定されるべきなんだよね。
別の言い方をすると、「まとめている親」のカードが設定され、「まとめられている子たち」のカードは設定されるべきではない。
でも、個々の日記ページは「自分が親なのか子なのか」を知る術がないんだよね・・・
そのため、子ページに書かれたプラグインはカード情報を吐き出してしまう。

逆に言えば、「自分が子だ」ということがわかればいいのだから。
回避手段としては、例えば、こんな実装はできる。

• tweetcardプラグインに、自分自身が「何回呼び出されたか」を数えるようにする。
  これは多くのプラグインで実施している内容なので、技術的課題なし。
• そのうえで、tweetcard自身が「最初の1回以外はカードを作成しない」ようにする。
• 上記を前提に、「複数のページをまとめる親ページでは、まず tweetcardを呼ぶ」運用にする。
  • これによって「親が1回目」を呼び出すので、子はカードを作らなくなる。
• 「親」にカードを置きたくないケースもあるので、「NULLのカード」を指定する仕組みを作る必要はある。
• pageinfo プラグインにも修正必要かな。
  上記方式だと親ページの先頭のほうにtweetcardがおかれるので、 pageinfoの「先頭ｘｘ文字をdescriptionにする」仕組みから、親ページのdescription に 「#tweetcard」とか書かれてしまう。

・・・運用任せだけど、このあたりが無難かなぁ。
もうちょっと抜け道がないか、考えなきゃだめっぽいけど。

ご意見などがあれば。