編集中に「テキスト整形のルールを表示」しても、メッセージがクリアされないようにする†
- ページ: BugTrack
- 投稿者: ぃぉぃぉ
- 優先順位: 低
- 状態: 完了
- カテゴリー: 本体新機能
- 投稿日: 2007-08-04 (土) 10:35:44
- バージョン: 1.4.7
- リリース予定バージョン: 1.5.2
編集フォームの「テキスト整形のルールを表示する」をPOSTメソッドにして、編集中のメッセージが引き継がれるようにする。†
使い始めた頃、編集し始めてから「表はどう記載するんだっけな?」と、整形ルールを表示したら、「あ゛～、今まで入力した内容が消えた ＞＜」なんてことがよくあったのですが、そうならないようにする方法です。
周り(パソコンに不慣れな人たち)に自分のPukiWikiを紹介して使ってもらったら、この苦情がでてきたもので、対応してみました。
フォーム生成部改造†
- html.php
- function edit_form()
- L.166あたり
- global $_btn_preview, $_btn_repreview, $_btn_update, $_btn_cancel, $_msg_help;
+ global $_btn_preview, $_btn_repreview, $_btn_update, $_btn_cancel, $_msg_help, $_msg_help_off;
- L.240あたり
$vars['helpoff']を使用しない様に修正。代わりに$vars['help_on']を使用。(2007-09-03 (月) 02:29:34 ぃぉぃぉ)
+ // Is help shown?
+ $help_on = isset($vars['help_on']) ? $vars['help_on'] : FALSE;
+ // If help button is clicked, change help showing state.
+ $help_on = ($help_on xor isset($vars['help']));
+ // Show help if (help showing and help button is not pressed) or (help not showing and help button is pressed)
+ if ($help_on) {
+ $help_button = "<input type=\"submit\" name=\"help\" value=\"$_msg_help_off\" />";
+ } else {
+ $help_button = "<input type=\"submit\" name=\"help\" value=\"$_msg_help\" />";
+ }
+
$body = <<<EOD
<div class="edit_form">
<form action="$script" method="post" style="margin-bottom:0px;">
$template
$addtag
<input type="hidden" name="cmd" value="edit" />
<input type="hidden" name="page" value="$s_page" />
<input type="hidden" name="digest" value="$s_digest" />
<textarea name="msg" rows="$rows" cols="$cols">$s_postdata</textarea>
<br />
<div style="float:left;">
<input type="submit" name="preview" value="$btn_preview" accesskey="p" />
<input type="submit" name="write" value="$_btn_update" accesskey="s" />
$add_top
$add_notimestamp
- </div>
<textarea name="original" rows="1" cols="1" style="display:none">$s_original</textarea>
- </form>
- <form action="$script" method="post" style="margin-top:0px;">
- <input type="hidden" name="cmd" value="edit" />
- <input type="hidden" name="page" value="$s_page" />
<input type="submit" name="cancel" value="$_btn_cancel" accesskey="c" />
+ </div>
+ <br />
+ <div style="clear:left;">
+ $help_button
+ <input type="hidden" name="help_on" value="$help_on" />
+ </div>
</form>
</div>
EOD;
- if (isset($vars['help'])) {
- $body .= $hr . catrule();
- } else {
- $body .= '<ul><li><a href="' .
- $script . '?cmd=edit&help=true&page=' . $r_page .
- '">' . $_msg_help . '</a></li></ul>';
- }
-
- return $body;
+ if ($help_on) {
+ $body .= $hr . catrule();
+ }
return $body;
edit.inc.php呼び出し時に表示するtextareaの中身決定。†
- global
- global $vars, $_title_edit, $load_template_func;
+ global $post, $vars, $_title_edit, $load_template_func;
ボタン表示切り替えに、消すときのメッセージ作成†
- ja.lng.php l.57あたり
$_msg_help = 'テキスト整形のルールを表示する';
+$_msg_help_off = 'テキスト整形のルールを隠す';
$_msg_week = array('日','月','火','水','木','金','土');
- en.lng.php l.54あたり
$_msg_help = 'View Text Formatting Rules';
+$_msg_help_off = 'Hide Text Formatting Rules';
$_msg_week = array('Sun','Mon','Tue','Wed','Thu','Fri','Sat');
コメント†
- こんにちは :) 確かに私もついクリックしてしまい、「戻る」機能の世話になることがあります。問題が何かという件ですが、この件については「ハイパーリンクは非常にクリックしやすい。またついクリックしてしまう場所にリンクがある。」というUIの特徴とレイアウトに関する問題ではないでしょうか。勘違いでなければ、他の回避策ないし解決策として、レイアウトや表示デザイン上の修正というのが入ってくると思います。(1)マウスアローが通過する操作コースとの兼ね合い(例えば、ボタンの直下におかずに、もう一～二行分下にずらせば抑えられるかもしれない) (2)周辺の強調度合いの少なさ(例えば、周囲が色付け/強調されていればある程度抑えられるかもしれない)等、どんな要素(無要素)でソレが誘発されたのか、どの用に感じられたのかについて、その方にお話を聞いてみたくなりますね。準備時間がそこそこあるなら、そうしたデザイン上の変化を絵で何パターンかを用意して、それらを見せながら意見を得たりとか。 -- henoheno
- 失礼しました (^^; クリックするまでの話ではなく、クリックしてから後の話なのですね。 -- henoheno
- 挙動的にはプレビューの亜種なのだなあ。 -- henoheno
- そうですね。送るデータはsubmitがpreviewかhelp関係かという以外同じです。 -- ぃぉぃぉ
- 自分の場合はついついクリックしたのではなく、Formatting Ruleを調べるために故意に押していました。ブラウザによるようですが、IE6の場合は、「戻る」で戻ったら、編集内容は保存されておらず、編集モードに入った時点の状態に戻ってしまいます。 -- ぃぉぃぉ
- 最近は消えることが分かっていますから、shift+クリックで別画面に表示したりしますが、これでは編集画面+フォーマットのヘルプという構成になっている意味がありません。 -- ぃぉぃぉ
- これならツールバー(? 最上部のメニュー)や下部のアイコンのヘルプで十分ですよね。 -- ぃぉぃぉ
- つまり、現状では編集モードに入った直後に「テキスト整形のルールを表示する」をクリックした場合のみ意味があります。 -- ぃぉぃぉ
- 一度プレビュー表示をした後なら、プレビュー表示に「戻る」＋「更新」で編集内容を送りなおす（復活させる）、とできなくはない（IE6の場合）ですけど... --
- プレビューの後でも、プレビューの直後しかだめですよね。その後編集していたものは残りませんT_T
この改造を適用すれば大丈夫v(^_^) -- ぃぉぃぉ
- ということで、このBugTrackのように、「テキスト整形のルールを表示する」をクリックした場合にも編集状態が保持されるようにするのがよいと思います。 -- ぃぉぃぉ
- アイデアだけな関連 : BugTrack/570の注釈
- 今までの実装が $vars['help'] を見ているということは、cmd=edit&help=on&page=<ページ名> といった GET method でも意図通りの状態になるということです。そのへんと上手く合わせられないでしょうか -- henoheno
- 今でもL.240あたりの「+ if (isset($vars['helpoff']) || !isset($vars['help'])) {」でvars['help']を見てますのでGETでもいけますよ～。
この条件文のelseの時、つまり$vars['help']がある時にヘルプが表示されます。 -- ぃぉぃぉ
- なんだかシングルクォートがエスケープされてました。spamか何かで引っかかって、復活してもらったときに入ってたのかな。修正しました。失礼しました。 -- ぃぉぃぉ
- とりあえず、こちらにデモページを
用意しました設置してました。henohenoさん、よろしかったらご覧下さい。id/passはguest/guestです。 -- ぃぉぃぉ
- 助かります。ページの先頭に、外見と動作が理解できるような絵を貼り付けました。(ファイル添付は我々にしかできませんが、こうした物を用意いただければこちらで対応します) -- henoheno
- 動作確認ありがとうございました。
画像作成、添付ありがとうございます。デモページは閉鎖しました。 -- ぃぉぃぉ
- edit.inc.php の部分ですが、msgを POSTのみから得ることを強制して安心したいシチュエーションでは $vars['msg'] でなく $post['msg'] にされるのがいいでしょう。・・・でも既存コードがそうしてるな・・・今まとめて見直します。上のパッチも直しておきます-- henoheno
- この機能は本体に組み込まれる可能性はありそうでしょうか? -- ぃぉぃぉ
- ぃぉぃぉさんが話されたアイデアやその発想はすぐに理解できたのですが、コードの言ってる事がまとまってない様に見える(聞こえる?)ので、整理しながら練らせていただいている、というのがこれまでの経過かな :) --
- 了解です。私が提案したまんまの仕様では組み込まれる可能性は低いけれど、helpボタンのPOST化は可能性がある、ということですね? -- ぃぉぃぉ
- 随分細かいやり取りが続いていますが、こうした部分がクリアされないと、このコードの主張しているだろう(けどまだ明確に書かれていない)データ構造の話題ができないような気がしていますです (^^; 練る話題としては、最近の cvs:plugin/tracker.inc.php の差分が該当すると思います。何段階練っていただいても歓迎します-- henoheno
- どこに書けばいいかわからなかったので、必要に応じて移動してください。私としては「戻る」を押したときに必ずリロードされるのが気に入らない、と思うこともあります。初心者向けだと、古いバージョンが履歴に残らないほうがよいという考え方なのでしょうか。ちなみにOperaではリロードされなかったかも知れません。 -- pai
- 「整形ルールを表示する」ボタンの挙動とは直接関係がなさそうなので、雑談に移動します。 -- ぃぉぃぉ
- これがうまくいけば、追加で整形ルールを表示すると編集になるの件が解決…してくれないかな。 --
- addもedit_form()を使用しているので「ヘルプを呼び出すと、それまでの編集内容が消える」に関しては解決します。(解決することを確認しました。) -- ぃぉぃぉ
- シンプルに、「テキスト整形のルール」ページを別ウィンドウ/別タブ で開くようにしました commit:8dc8b36fe2 -- umorigu
コメント: 資源の消費量 (理解するコストを減らし、結果的に柔軟なコードにするためのスリム化)†
コメント: ユーザーインターフェース同士の関係性†
- 「プレビューのボタン」と、「プレビューの亜種であるところのこのボタン」は、「一つのボタンと、二つのチェックボックス」で表現できないでしょうか。ボタン名が悩ましいですが例えば「リロード」とか。 -- henoheno
コメント: 抽象化による展開例: 衝突検知など†
- 「プレビューのボタン」と、「プレビューの亜種であるところのこのボタン」は、「一つのボタンと、二つのチェックボックス」で表現できないでしょうか。ボタン名が悩ましいですが例えば「リロード」とか。そんな方向に持って行くと、すぐには実現できないでしょうが、編集中に他人が同じページを更新してしまったかどうかをチェックする機構や、それを解決させる機構に収斂することができるのではないかナーと、ちょっと思いますがいかがでしょう -- henoheno
- なるほど、編集の衝突のチェックですか。衝突対策の良い案があるといいですね。 -- ぃぉぃぉ
- 衝突検知は今でもできる*1けど、衝突解消をユーザーに促すためにはデータを保管するバックエンドや、内部関数や、編集フォームの部分をその視点で見直さないといけないでしょう。見本になるのは例えばCVSのconflictですが、Wikiの更新とソースコード管理システムのコミットは求められる更新頻度やスピードが大きく異なるものですから、乱雑にハックしたものが本当の意味で実用(万人向け)になるとは思っていないです。 -- henoheno
- 衝突検知に関しては、確かに実用的なものというのは難しいと思います。
ですので、現状ではレイアウトやデザインにそのことを絡めて考える必要はなさそうですね。現状に近づけた、上の添付画像のもので十分実用になると思います。(自分のサイトでは、デモしていたようにこの状態で運用しています。) -- ぃぉぃぉ
メタコメント: 既存実装とのバッティング (cancel時のpayload)†
- lib/html.php の edit_form() で、cancelが本文をPOSTしないようになった BugTrack2/160 の工夫が殺されてしまっておるようです -- henoheno
- 動作的にはplugin/edit.inc.phpで対応済みの様です。$vars['cancel']が存在するとリロードするようになっています。(BugTrack2/160の工夫とはこのことでよろしいのでしょうか?) -- ぃぉぃぉ
- お疲れ様です。BugTrack2/160 の工夫 というのは、"「キャンセル」ボタンを別formに。" とある部分の事を差しています。別formでなくなってしまっているので、cancelボタンをクリックした時のペイロードが大きくなります(不要なデータを沢山送りつけてしまいます)。 -- henoheno
- なるほど。cancel時はPOSTデータのほとんどが不要ということですね。この不要なPOSTデータをやめるには、
- 「テキスト整形のルールを表示する」ボタンをCANCELボタンより上に持ってくる
- CANCELをボタンではなくリロードと同じリンクとする
という方法が考えられますね。自分としてはCANCELボタンの使用頻度は低いので、CANCEL時の冗長なデータは気にしませんが^^; -- ぃぉぃぉ
- ふむふむ、考え方が理解できました。edit_form の payload はそもそも無駄なものを抱えている節がある *2ため、別のいいアイデアやデザインの都合があって、どうしてもformを一つにしなければならないなら、それは仕方ないと思っています。また、cancelのformが分けてあるかどうかは確かに死活問題ではないので、とりあえず cancel のために form が分けてあるかどうかという件は無視して、パッチを理解する方に戻りたいと思います -- henoheno
- こちらの件、上に画像で提示したレイアウトから考えるに、バッティングしていない(BugTrack2/160のアイデアを打ち消す必然性がない)様に見えてきました。本当でしょうか。バッティングしていないのに破壊しているとしたら、上のコードの主張は結構乱暴なので、大人しい状態に直す事ができるでしょう。 -- henoheno
- 少し上のa.「テキスト整形のルールを表示する」ボタンを(ソース上で)CANCELボタンより上に持ってくる が可能であれば、その通りだと思います。
css(よく分かってません^^;)で頑張れば出来そうな気もします。skinに影響が出るかな? -- ぃぉぃぉ
- ? (^^; あ、そうか・・・ちょっと適当言ってたみたいです。申し訳ありません。 -- henoheno
- 了解っす^^; -- ぃぉぃぉ
メタコメント: パッチ(差分)に関して†
- 見た目を含めて検討したかったのですが、上記のパッチはそれぞれどのリビジョンに対するものでしょう。 html.php で言えば $help_on といった変数は無いので、何か部分的なパッチのようにも思えます。 -- henoheno
- 元になっているのはPukiWiki Ver.1.4.7_notbです。
$help_onはローカル変数で上記パッチで新設したものです。getメソッドでの&help=onの場合の挙動は変更ありません。(上記パッチを当ててもヘルプありの編集画面となります。) -- ぃぉぃぉ
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
BugTrack2-266_ioio_01_buttonB.png
BugTrack2-266_ioio_01_buttonA.png
