BugTrack/2266
の編集
Top
/
BugTrack
/
2266
[
トップ
] [
編集
|
差分
|
履歴
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
* 編集中に「テキスト整形のルールを表示」しても、メッセージがクリアされないようにする [#f1df1243] - ページ: [[BugTrack]] - 投稿者: [[ぃぉぃぉ]] - 優先順位: 低 - 状態: 完了 - カテゴリー: 本体新機能 - 投稿日: 2007-08-04 (土) 10:35:44 - バージョン: 1.4.7 - リリース予定バージョン: 1.5.2 ---- #contents ---- **編集フォームの「テキスト整形のルールを表示する」をPOSTメソッドにして、編集中のメッセージが引き継がれるようにする。 [#pb64d14c] 使い始めた頃、編集し始めてから「表はどう記載するんだっけな?」と、整形ルールを表示したら、「あ゛～、今まで入力した内容が消えた ＞＜」なんてことがよくあったのですが、そうならないようにする方法です。&br; 周り(パソコンに不慣れな人たち)に自分のPukiWikiを紹介して使ってもらったら、この苦情がでてきたもので、対応してみました。 #ref(BugTrack2-266_ioio_01_buttonA.png,nolink) #br #ref(BugTrack2-266_ioio_01_buttonB.png,nolink) ***フォーム生成部改造 [#zf9d8829] -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あたり&br; //value=$_msg_help(_off)を""でくくり忘れていたので修正。(2007-08-09 (木) 00:09:29) $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の中身決定。 [#dafc40a8] -global - global $vars, $_title_edit, $load_template_func; + global $post, $vars, $_title_edit, $load_template_func; -L.30あたり&br; プレビューかフォーマットルール表示の場合には引数から渡された(=ポストされた)msgを使用。 + if (!isset($post['msg'])) { $postdata = @join('', get_source($page)); if ($postdata == '') $postdata = auto_template($page); + } else { + $postdata = $post['msg']; + } ***ボタン表示切り替えに、消すときのメッセージ作成 [#gd8ebceb] -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'); -------- **コメント [#kf831b9b] - こんにちは :) 確かに私もついクリックしてしまい、「戻る」機能の世話になることがあります。問題が何かという件ですが、この件については「ハイパーリンクは非常にクリックしやすい。またついクリックしてしまう場所にリンクがある。」というUIの特徴とレイアウトに関する問題ではないでしょうか。勘違いでなければ、他の回避策ないし解決策として、レイアウトや表示デザイン上の修正というのが入ってくると思います。(1)マウスアローが通過する操作コースとの兼ね合い(例えば、ボタンの直下におかずに、もう一～二行分下にずらせば抑えられるかもしれない) (2)周辺の強調度合いの少なさ(例えば、周囲が色付け/強調されていればある程度抑えられるかもしれない)等、どんな要素(無要素)でソレが誘発されたのか、どの用に感じられたのかについて、その方にお話を聞いてみたくなりますね。準備時間がそこそこあるなら、そうしたデザイン上の変化を絵で何パターンかを用意して、それらを見せながら意見を得たりとか。 -- [[henoheno]] &new{2007-08-04 (土) 10:43:45}; -- 失礼しました (^^; クリックするまでの話ではなく、クリックしてから後の話なのですね。 -- [[henoheno]] &new{2007-08-04 (土) 18:27:40}; -- 挙動的にはプレビューの亜種なのだなあ。 -- [[henoheno]] &new{2007-08-04 (土) 18:23:55}; -- そうですね。送るデータはsubmitがpreviewかhelp関係かという以外同じです。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 23:18:00}; - 自分の場合はついついクリックしたのではなく、Formatting Ruleを調べるために故意に押していました。ブラウザによるようですが、IE6の場合は、「戻る」で戻ったら、編集内容は保存されておらず、編集モードに入った時点の状態に戻ってしまいます。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:20:56}; -- 最近は消えることが分かっていますから、shift+クリックで別画面に表示したりしますが、これでは編集画面+フォーマットのヘルプという構成になっている意味がありません。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:18:08}; --- これならツールバー(? 最上部のメニュー)や下部のアイコンのヘルプで十分ですよね。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:22:10}; -- つまり、現状では編集モードに入った''直後''に「テキスト整形のルールを表示する」をクリックした場合のみ意味があります。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:21:37}; --- 一度プレビュー表示をした後なら、プレビュー表示に「戻る」＋「更新」で編集内容を送りなおす（復活させる）、とできなくはない（IE6の場合）ですけど... -- &new{2007-08-04 (土) 12:32:27}; --- プレビューの後でも、プレビューの''直後''しかだめですよね。その後編集していたものは残りませんT_T&br;この改造を適用すれば大丈夫v(^_^) -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 23:24:32}; -- ということで、このBugTrackのように、「テキスト整形のルールを表示する」をクリックした場合にも編集状態が保持されるようにするのがよいと思います。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:22:52}; - アイデアだけな関連 : [[BugTrack/570]]の注釈 - 今までの実装が $vars['help'] を見ているということは、cmd=edit&help=on&page=<ページ名> といった GET method でも意図通りの状態になるということです。そのへんと上手く合わせられないでしょうか -- [[henoheno]] &new{2007-08-05 (日) 17:34:09}; -- 今でもL.240あたりの「+ if (isset($vars['helpoff']) || !isset($vars['help'])) {」でvars['help']を見てますのでGETでもいけますよ～。&br;この条件文のelseの時、つまり$vars['help']がある時にヘルプが表示されます。 -- [[ぃぉぃぉ]] &new{2007-08-07 (火) 01:29:16}; - なんだかシングルクォートがエスケープされてました。spamか何かで引っかかって、復活してもらったときに入ってたのかな。修正しました。失礼しました。 -- [[ぃぉぃぉ]] &new{2007-08-07 (火) 12:34:04}; - とりあえず、こちらにデモページを%%用意しました%%設置してました。henohenoさん、よろしかったらご覧下さい。id/passはguest/guestです。 -- [[ぃぉぃぉ]] &new{2007-08-19 (日) 02:18:30}; -- 助かります。ページの先頭に、外見と動作が理解できるような絵を貼り付けました。(ファイル添付は我々にしかできませんが、こうした物を用意いただければこちらで対応します) -- [[henoheno]] &new{2007-08-19 (日) 21:11:46}; --- 動作確認ありがとうございました。&br;画像作成、添付ありがとうございます。デモページは閉鎖しました。 -- [[ぃぉぃぉ]] &new{2007-08-22 (水) 01:20:46}; - edit.inc.php の部分ですが、msgを POSTのみから得ることを強制して安心したいシチュエーションでは $vars['msg'] でなく $post['msg'] にされるのがいいでしょう。・・・でも既存コードがそうしてるな・・・今まとめて見直します。上のパッチも直しておきます-- [[henoheno]] &new{2007-08-19 (日) 21:27:29}; -- [[cvs:plugin/edit.inc.php]] (r1.42) - この機能は本体に組み込まれる可能性はありそうでしょうか? -- [[ぃぉぃぉ]] &new{2007-08-23 (木) 01:08:08}; -- [[ぃぉぃぉ]]さんが話されたアイデアやその発想はすぐに理解できたのですが、コードの言ってる事がまとまってない様に見える(聞こえる?)ので、整理しながら練らせていただいている、というのがこれまでの経過かな :) -- &new{2007-08-27 (月) 23:56:06}; -- 了解です。私が提案したまんまの仕様では組み込まれる可能性は低いけれど、helpボタンのPOST化は可能性がある、ということですね? -- [[ぃぉぃぉ]] &new{2007-08-28 (火) 03:17:52}; - 随分細かいやり取りが続いていますが、こうした部分がクリアされないと、このコードの主張しているだろう(けどまだ明確に書かれていない)データ構造の話題ができないような気がしていますです (^^; 練る話題としては、最近の [[cvs:plugin/tracker.inc.php]] の差分が該当すると思います。何段階練っていただいても歓迎します-- [[henoheno]] &new{2007-09-12 (水) 00:39:20}; - どこに書けばいいかわからなかったので、必要に応じて移動してください。私としては「戻る」を押したときに必ずリロードされるのが気に入らない、と思うこともあります。初心者向けだと、古いバージョンが履歴に残らないほうがよいという考え方なのでしょうか。ちなみにOperaではリロードされなかったかも知れません。 -- [[pai]] &new{2007-09-12 (水) 01:25:09}; -- 「整形ルールを表示する」ボタンの挙動とは直接関係がなさそうなので、雑談に移動します。 -- [[ぃぉぃぉ]] &new{2007-09-13 (木) 02:22:32}; - これがうまくいけば、[[追加で整形ルールを表示すると編集になる>BugTrack/570]]の件が解決…してくれないかな。 -- &new{2007-09-12 (水) 19:48:27}; -- addもedit_form()を使用しているので「ヘルプを呼び出すと、それまでの編集内容が消える」に関しては解決します。(解決することを確認しました。) -- [[ぃぉぃぉ]] &new{2007-09-13 (木) 02:27:49}; - シンプルに、「テキスト整形のルール」ページを別ウィンドウ/別タブ で開くようにしました commit:8dc8b36fe2 -- [[umorigu]] &new{2017-06-20 (火) 00:47:42}; #comment ** コメント: 資源の消費量 (理解するコストを減らし、結果的に柔軟なコードにするためのスリム化) [#j721b139] - html.phpの差分は、$vars['helpoff'] の無い、よりシンプルな状態にできると思うので、もしよろしければ見ていただけないでしょうか。気になっていたのですが、うまく説明する自信が無かったので、最終的にテストコードを作りました。(HTMLを手で書いたのは久しぶりなので、かなり苦しみました)動作確認は FirefoxとIE6でしました。シンプルでないと後が困るというのがポイントで、必ずしもこの通りにして欲しいというものではありません。 -- [[henoheno]] &new{2007-08-27 (月) 23:57:37}; -- [[cvs:../devel/followup_html]] (1.1) -- デモ作成お疲れ様です。拝見致しました。なるほど、すっきりしますね。$showhelpの型をbooleanにしたりstringにしたりしているのが気になりますけど、phpでは気にしなくて良いのでしょうか? -- [[ぃぉぃぉ]] &new{2007-08-28 (火) 03:40:47}; -- PHPマニュアルの変数の項を参照下さい。初期化さえしっかりしてれば問題にはなりません。submitの初期状態を明確にし、またtoggleしている部分を完結に表現するために前段をbooleanに揃えてみたただけです。 -- [[henoheno]] &new{2007-08-29 (水) 01:41:36}; -- マニュアル見てみました。とりあえずNoticeも何も出ていないので問題はなさそうですね。本題から離れるので雑談にちょっと記載します。 -- [[ぃぉぃぉ]] &new{2007-08-30 (木) 01:51:47}; - こちらの(というか、そちらのお手元の)ソース、$vars['helpoff'] の無い状態に整理しておいて下さい :) -- [[henoheno]] &new{2007-09-03 (月) 00:13:26}; - $vars['help_on']を使うようにしました。$vars['showhelp']でも良かったのですが、なんとなく^^; -- [[ぃぉぃぉ]] &new{2007-09-03 (月) 02:34:41}; - お疲れ様です。こちらの件、もう少し簡素にできないでしょうか: -- [[henoheno]] &new{2007-09-12 (水) 00:32:51}; $help_on = isset($vars['help_on']) ? $vars['help_on'] : FALSE; $help_on = $help_on ^ isset($vars['help']); -- 一行目でstringかbool(FALSE)が変数に入っていますから、FALSEには何か特別な意味があるのだろうと思ったのですが、二行目でboolとのビット演算(XOR)をされています。bool型は強制的に1ビットの整数に変換され、文字列は強制的に1ビット以上の整数になるでしょうから、二行目では1ビットと1ビット、ないしNビット(string由来)と1ビットのXORが行われています。ビット数の異なる値のXORが起こる部分や、複数ビット同士のビット演算のために使うだろう ^ 演算子が使われている部分は多分意図されていなくて、実際に表現されたいのは1ビット同士のXORのはずです。どうしてもXORにこだわるなら、こんな感じに変形できると思います: $help_on = isset($vars['help_on']) ? (bool)$vars['help_on'] : FALSE; // bool world $help_on = (isset($vars['help']) xor $help_on); // bool world: 優先順位が低いので、カッコ必須 -- 論理演算子とbit演算子を区別していませんでした。失礼しました。xorに修正しました。&br;$vars['help_on']はboolを渡しています。$help_on、$vars['help_on']はboolで統一していますので、^をxorに修正するだけで良いと思います。 -- [[ぃぉぃぉ]] &new{2007-09-12 (水) 12:28:46}; -- どうして [[cvs:../devel/followup_html/form_submit.php]] でこの手のstatusを "on" "off" として出力しているのかといえば、それは「いつかデバッグがしやすくなる様に」です。HTMLとして出力される $help_on がどうなっているか、また $vars['help_on'] の型が何であって中身がどうなっているかを確認しておいて下さい。 -- [[henoheno]] &new{2007-09-13 (木) 23:13:02}; -- boolの値を収めた変数をechoしたとしてもユーザーに届く値はstringです。また、ユーザーから得られる値は通常必ず任意の(binary)stringです。 -- [[henoheno]] &new{2007-09-27 (木) 00:31:41}; #comment ** コメント: ユーザーインターフェース同士の関係性 [#v16bd7c3] - 「プレビューのボタン」と、「プレビューの亜種であるところのこのボタン」は、「一つのボタンと、二つのチェックボックス」で表現できないでしょうか。ボタン名が悩ましいですが例えば「リロード」とか。 -- [[henoheno]] &new{2007-08-20 (月) 00:21:15}; -- 「一つのボタンと二つのチェックボックス」で表現は簡単そうな気がしますが、良いレイアウトが浮かびません。現状の「整形ルール表示」や「プレビュー」ボタンは1クリックでその動作をしてくれますので直感的に操作できますが、チェックボックスのチェックをしてからボタンクリック、という1アクション増えると、パソコンに不慣れな人には辛くなるかな、と。&br;おじいちゃんおばあちゃんに使わせようと頑張っているのでｗ -- [[ぃぉぃぉ]] &new{2007-08-22 (水) 01:36:56}; -- 機能ごとにボタンが一つあるというのは確かにそこだけ見ると解り易いでしょう。しかしその発想だけでは逆の(コストを減らす)発想が無いのでバランスが悪く、新しいアイデアが生まれる度に編集画面にボタンが増えてしまう様な方向に繋がりかねません。もし結果的に得られるのであれば、ニーズと経済性が上手に折り合った、エレガントな回答が欲しいです。(シェイプアップさせる事で、新しい価値がそこから見出されるならなお良し) -- [[henoheno]] &new{2007-08-23 (木) 01:05:36}; -- レイアウトについてはこんなイメージでいました。集約させるボタンの名前、もっといいのがあるといいのですが。 -- [[henoheno]] &new{2007-08-23 (木) 01:06:14}; [ リロード ] □プレビュー □整形ルール [ ページの更新 ] □タイムスタンプを維持 [ キャンセル ] -- 「整形ルールを表示する」というのをわかりやすく省略するのが難しいなあ、と考えています。上のhenohenoさんの案の整形ルールだと、「整形ルールに従って整形してくれるのかな?」みたいな感じがしませんか?我々のようにPukiWiki使用経験がある程度以上あるものならすぐに分かりますけど。これなら現状の方がわかりやすいな、と自分は思います。henohenoさんの案に似ていますが □タイムスタンプを維持[ ページの更新 ] □プレビューON □整形ルール表示 [ 実行 ] [ キャンセル ] というのは考えてみましたが、この長さなら現状の方がよいな、と。衝突検知等、他の機能が増えてボタンが増えそうなときにレイアウトを検討した方がよいのではないでしょうか。 -- [[ぃぉぃぉ]] &new{2007-08-23 (木) 01:17:54}; #comment ** コメント: 抽象化による展開例: 衝突検知など [#l911d7bf] - 「プレビューのボタン」と、「プレビューの亜種であるところのこのボタン」は、「一つのボタンと、二つのチェックボックス」で表現できないでしょうか。ボタン名が悩ましいですが例えば「リロード」とか。そんな方向に持って行くと、すぐには実現できないでしょうが、編集中に他人が同じページを更新してしまったかどうかをチェックする機構や、それを解決させる機構に収斂することができるのではないかナーと、ちょっと思いますがいかがでしょう -- [[henoheno]] &new{2007-08-20 (月) 00:21:15}; -- なるほど、編集の衝突のチェックですか。衝突対策の良い案があるといいですね。 -- [[ぃぉぃぉ]] &new{2007-08-22 (水) 01:36:56}; -- 衝突検知は今でもできる((だから衝突した事を知らせる事だけなら今すぐできる))けど、衝突解消をユーザーに促すためにはデータを保管するバックエンドや、内部関数や、編集フォームの部分をその視点で見直さないといけないでしょう。見本になるのは例えばCVSのconflictですが、Wikiの更新とソースコード管理システムのコミットは求められる更新頻度やスピードが大きく異なるものですから、乱雑にハックしたものが本当の意味で実用(万人向け)になるとは思っていないです。 -- [[henoheno]] &new{2007-08-23 (木) 00:50:50}; -- 衝突検知に関しては、確かに実用的なものというのは難しいと思います。&br;ですので、現状ではレイアウトやデザインにそのことを絡めて考える必要はなさそうですね。現状に近づけた、上の添付画像のもので十分実用になると思います。(自分のサイトでは、デモしていたようにこの状態で運用しています。) -- [[ぃぉぃぉ]] &new{2007-08-23 (木) 01:08:08}; #comment ** メタコメント: 既存実装とのバッティング (cancel時のpayload) [#g276085f] - lib/html.php の edit_form() で、cancelが本文をPOSTしないようになった [[BugTrack2/160]] の工夫が殺されてしまっておるようです -- [[henoheno]] &new{2007-08-12 (日) 23:34:02}; -- 動作的にはplugin/edit.inc.phpで対応済みの様です。$vars['cancel']が存在するとリロードするようになっています。([[BugTrack2/160]]の工夫とはこのことでよろしいのでしょうか?) -- [[ぃぉぃぉ]] &new{2007-08-14 (火) 20:27:14}; -- お疲れ様です。BugTrack2/160 の工夫 というのは、"「キャンセル」ボタンを別formに。" とある部分の事を差しています。別formでなくなってしまっているので、cancelボタンをクリックした時のペイロードが大きくなります(不要なデータを沢山送りつけてしまいます)。 -- [[henoheno]] &new{2007-08-16 (木) 00:06:46}; -- なるほど。cancel時はPOSTデータのほとんどが不要ということですね。この不要なPOSTデータをやめるには、 +++「テキスト整形のルールを表示する」ボタンをCANCELボタンより上に持ってくる +++CANCELをボタンではなくリロードと同じリンクとする&br; という方法が考えられますね。自分としてはCANCELボタンの使用頻度は低いので、CANCEL時の冗長なデータは気にしませんが^^; -- [[ぃぉぃぉ]] &new{2007-08-16 (木) 04:11:22}; - ふむふむ、考え方が理解できました。edit_form の payload はそもそも無駄なものを抱えている節がある (('original'の件。設計上の、またはアーキテクチャの問題と思われる))ため、別のいいアイデアやデザインの都合があって、どうしてもformを一つにしなければならないなら、それは仕方ないと思っています。また、cancelのformが分けてあるかどうかは確かに死活問題ではないので、とりあえず cancel のために form が分けてあるかどうかという件は無視して、パッチを理解する方に戻りたいと思います -- [[henoheno]] &new{2007-08-19 (日) 00:26:36}; -- よろしくお願いします。 -- [[ぃぉぃぉ]] &new{2007-08-19 (日) 02:18:30}; - こちらの件、上に画像で提示したレイアウトから考えるに、バッティングしていない([[BugTrack2/160]]のアイデアを打ち消す必然性がない)様に見えてきました。本当でしょうか。バッティングしていないのに破壊しているとしたら、上のコードの主張は結構乱暴なので、大人しい状態に直す事ができるでしょう。 -- [[henoheno]] &new{2007-08-27 (月) 23:48:22}; -- 少し上のa.「テキスト整形のルールを表示する」ボタンを(ソース上で)CANCELボタンより上に持ってくる が可能であれば、その通りだと思います。&br;css(よく分かってません^^;)で頑張れば出来そうな気もします。skinに影響が出るかな? -- [[ぃぉぃぉ]] &new{2007-08-28 (火) 02:43:29}; -- ? (^^; あ、そうか・・・ちょっと適当言ってたみたいです。申し訳ありません。 -- [[henoheno]] &new{2007-08-29 (水) 01:45:09}; -- 了解っす^^; -- [[ぃぉぃぉ]] &new{2007-08-30 (木) 01:50:40}; #comment ** メタコメント: パッチ(差分)に関して [#z0182e6c] - 見た目を含めて検討したかったのですが、上記のパッチはそれぞれどのリビジョンに対するものでしょう。 html.php で言えば $help_on といった変数は無いので、何か部分的なパッチのようにも思えます。 -- [[henoheno]] &new{2007-08-05 (日) 17:32:51}; -- 元になっているのはPukiWiki Ver.1.4.7_notbです。&br;$help_onはローカル変数で上記パッチで新設したものです。getメソッドでの&help=onの場合の挙動は変更ありません。(上記パッチを当ててもヘルプありの編集画面となります。) -- [[ぃぉぃぉ]] &new{2007-08-05 (日) 18:08:20}; --- はい、$help_on はこのパッチで用意された変数ですよね。それなのに以下の部分は $help_on が以前から存在したかのような表現になっているのです -- [[henoheno]] &new{2007-08-05 (日) 19:00:38}; if ($help_on) { $body .= $hr . catrule(); } --- [[フォーム生成部改造のhtml.phpのfunction edit_form() のL.240あたり>./#l240]]、の最初の部分で$help_onの値を生成しています。 -- [[ぃぉぃぉ]] &new{2007-08-05 (日) 19:04:49}; --- はい、そしてそのパッチの最後の部分にある、 + でも - でもない部分で $help_on が登場していますが、そこの部分が不思議なのです。何か勘違いしているかな・・・ -- [[henoheno]] &new{2007-08-05 (日) 21:00:42}; --- 失礼しました。その３行も+です。(修正しました) -- [[ぃぉぃぉ]] &new{2007-08-05 (日) 22:52:47}; #comment
タイムスタンプを変更しない
* 編集中に「テキスト整形のルールを表示」しても、メッセージがクリアされないようにする [#f1df1243] - ページ: [[BugTrack]] - 投稿者: [[ぃぉぃぉ]] - 優先順位: 低 - 状態: 完了 - カテゴリー: 本体新機能 - 投稿日: 2007-08-04 (土) 10:35:44 - バージョン: 1.4.7 - リリース予定バージョン: 1.5.2 ---- #contents ---- **編集フォームの「テキスト整形のルールを表示する」をPOSTメソッドにして、編集中のメッセージが引き継がれるようにする。 [#pb64d14c] 使い始めた頃、編集し始めてから「表はどう記載するんだっけな?」と、整形ルールを表示したら、「あ゛～、今まで入力した内容が消えた ＞＜」なんてことがよくあったのですが、そうならないようにする方法です。&br; 周り(パソコンに不慣れな人たち)に自分のPukiWikiを紹介して使ってもらったら、この苦情がでてきたもので、対応してみました。 #ref(BugTrack2-266_ioio_01_buttonA.png,nolink) #br #ref(BugTrack2-266_ioio_01_buttonB.png,nolink) ***フォーム生成部改造 [#zf9d8829] -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あたり&br; //value=$_msg_help(_off)を""でくくり忘れていたので修正。(2007-08-09 (木) 00:09:29) $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の中身決定。 [#dafc40a8] -global - global $vars, $_title_edit, $load_template_func; + global $post, $vars, $_title_edit, $load_template_func; -L.30あたり&br; プレビューかフォーマットルール表示の場合には引数から渡された(=ポストされた)msgを使用。 + if (!isset($post['msg'])) { $postdata = @join('', get_source($page)); if ($postdata == '') $postdata = auto_template($page); + } else { + $postdata = $post['msg']; + } ***ボタン表示切り替えに、消すときのメッセージ作成 [#gd8ebceb] -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'); -------- **コメント [#kf831b9b] - こんにちは :) 確かに私もついクリックしてしまい、「戻る」機能の世話になることがあります。問題が何かという件ですが、この件については「ハイパーリンクは非常にクリックしやすい。またついクリックしてしまう場所にリンクがある。」というUIの特徴とレイアウトに関する問題ではないでしょうか。勘違いでなければ、他の回避策ないし解決策として、レイアウトや表示デザイン上の修正というのが入ってくると思います。(1)マウスアローが通過する操作コースとの兼ね合い(例えば、ボタンの直下におかずに、もう一～二行分下にずらせば抑えられるかもしれない) (2)周辺の強調度合いの少なさ(例えば、周囲が色付け/強調されていればある程度抑えられるかもしれない)等、どんな要素(無要素)でソレが誘発されたのか、どの用に感じられたのかについて、その方にお話を聞いてみたくなりますね。準備時間がそこそこあるなら、そうしたデザイン上の変化を絵で何パターンかを用意して、それらを見せながら意見を得たりとか。 -- [[henoheno]] &new{2007-08-04 (土) 10:43:45}; -- 失礼しました (^^; クリックするまでの話ではなく、クリックしてから後の話なのですね。 -- [[henoheno]] &new{2007-08-04 (土) 18:27:40}; -- 挙動的にはプレビューの亜種なのだなあ。 -- [[henoheno]] &new{2007-08-04 (土) 18:23:55}; -- そうですね。送るデータはsubmitがpreviewかhelp関係かという以外同じです。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 23:18:00}; - 自分の場合はついついクリックしたのではなく、Formatting Ruleを調べるために故意に押していました。ブラウザによるようですが、IE6の場合は、「戻る」で戻ったら、編集内容は保存されておらず、編集モードに入った時点の状態に戻ってしまいます。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:20:56}; -- 最近は消えることが分かっていますから、shift+クリックで別画面に表示したりしますが、これでは編集画面+フォーマットのヘルプという構成になっている意味がありません。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:18:08}; --- これならツールバー(? 最上部のメニュー)や下部のアイコンのヘルプで十分ですよね。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:22:10}; -- つまり、現状では編集モードに入った''直後''に「テキスト整形のルールを表示する」をクリックした場合のみ意味があります。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:21:37}; --- 一度プレビュー表示をした後なら、プレビュー表示に「戻る」＋「更新」で編集内容を送りなおす（復活させる）、とできなくはない（IE6の場合）ですけど... -- &new{2007-08-04 (土) 12:32:27}; --- プレビューの後でも、プレビューの''直後''しかだめですよね。その後編集していたものは残りませんT_T&br;この改造を適用すれば大丈夫v(^_^) -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 23:24:32}; -- ということで、このBugTrackのように、「テキスト整形のルールを表示する」をクリックした場合にも編集状態が保持されるようにするのがよいと思います。 -- [[ぃぉぃぉ]] &new{2007-08-04 (土) 11:22:52}; - アイデアだけな関連 : [[BugTrack/570]]の注釈 - 今までの実装が $vars['help'] を見ているということは、cmd=edit&help=on&page=<ページ名> といった GET method でも意図通りの状態になるということです。そのへんと上手く合わせられないでしょうか -- [[henoheno]] &new{2007-08-05 (日) 17:34:09}; -- 今でもL.240あたりの「+ if (isset($vars['helpoff']) || !isset($vars['help'])) {」でvars['help']を見てますのでGETでもいけますよ～。&br;この条件文のelseの時、つまり$vars['help']がある時にヘルプが表示されます。 -- [[ぃぉぃぉ]] &new{2007-08-07 (火) 01:29:16}; - なんだかシングルクォートがエスケープされてました。spamか何かで引っかかって、復活してもらったときに入ってたのかな。修正しました。失礼しました。 -- [[ぃぉぃぉ]] &new{2007-08-07 (火) 12:34:04}; - とりあえず、こちらにデモページを%%用意しました%%設置してました。henohenoさん、よろしかったらご覧下さい。id/passはguest/guestです。 -- [[ぃぉぃぉ]] &new{2007-08-19 (日) 02:18:30}; -- 助かります。ページの先頭に、外見と動作が理解できるような絵を貼り付けました。(ファイル添付は我々にしかできませんが、こうした物を用意いただければこちらで対応します) -- [[henoheno]] &new{2007-08-19 (日) 21:11:46}; --- 動作確認ありがとうございました。&br;画像作成、添付ありがとうございます。デモページは閉鎖しました。 -- [[ぃぉぃぉ]] &new{2007-08-22 (水) 01:20:46}; - edit.inc.php の部分ですが、msgを POSTのみから得ることを強制して安心したいシチュエーションでは $vars['msg'] でなく $post['msg'] にされるのがいいでしょう。・・・でも既存コードがそうしてるな・・・今まとめて見直します。上のパッチも直しておきます-- [[henoheno]] &new{2007-08-19 (日) 21:27:29}; -- [[cvs:plugin/edit.inc.php]] (r1.42) - この機能は本体に組み込まれる可能性はありそうでしょうか? -- [[ぃぉぃぉ]] &new{2007-08-23 (木) 01:08:08}; -- [[ぃぉぃぉ]]さんが話されたアイデアやその発想はすぐに理解できたのですが、コードの言ってる事がまとまってない様に見える(聞こえる?)ので、整理しながら練らせていただいている、というのがこれまでの経過かな :) -- &new{2007-08-27 (月) 23:56:06}; -- 了解です。私が提案したまんまの仕様では組み込まれる可能性は低いけれど、helpボタンのPOST化は可能性がある、ということですね? -- [[ぃぉぃぉ]] &new{2007-08-28 (火) 03:17:52}; - 随分細かいやり取りが続いていますが、こうした部分がクリアされないと、このコードの主張しているだろう(けどまだ明確に書かれていない)データ構造の話題ができないような気がしていますです (^^; 練る話題としては、最近の [[cvs:plugin/tracker.inc.php]] の差分が該当すると思います。何段階練っていただいても歓迎します-- [[henoheno]] &new{2007-09-12 (水) 00:39:20}; - どこに書けばいいかわからなかったので、必要に応じて移動してください。私としては「戻る」を押したときに必ずリロードされるのが気に入らない、と思うこともあります。初心者向けだと、古いバージョンが履歴に残らないほうがよいという考え方なのでしょうか。ちなみにOperaではリロードされなかったかも知れません。 -- [[pai]] &new{2007-09-12 (水) 01:25:09}; -- 「整形ルールを表示する」ボタンの挙動とは直接関係がなさそうなので、雑談に移動します。 -- [[ぃぉぃぉ]] &new{2007-09-13 (木) 02:22:32}; - これがうまくいけば、[[追加で整形ルールを表示すると編集になる>BugTrack/570]]の件が解決…してくれないかな。 -- &new{2007-09-12 (水) 19:48:27}; -- addもedit_form()を使用しているので「ヘルプを呼び出すと、それまでの編集内容が消える」に関しては解決します。(解決することを確認しました。) -- [[ぃぉぃぉ]] &new{2007-09-13 (木) 02:27:49}; - シンプルに、「テキスト整形のルール」ページを別ウィンドウ/別タブ で開くようにしました commit:8dc8b36fe2 -- [[umorigu]] &new{2017-06-20 (火) 00:47:42}; #comment ** コメント: 資源の消費量 (理解するコストを減らし、結果的に柔軟なコードにするためのスリム化) [#j721b139] - html.phpの差分は、$vars['helpoff'] の無い、よりシンプルな状態にできると思うので、もしよろしければ見ていただけないでしょうか。気になっていたのですが、うまく説明する自信が無かったので、最終的にテストコードを作りました。(HTMLを手で書いたのは久しぶりなので、かなり苦しみました)動作確認は FirefoxとIE6でしました。シンプルでないと後が困るというのがポイントで、必ずしもこの通りにして欲しいというものではありません。 -- [[henoheno]] &new{2007-08-27 (月) 23:57:37}; -- [[cvs:../devel/followup_html]] (1.1) -- デモ作成お疲れ様です。拝見致しました。なるほど、すっきりしますね。$showhelpの型をbooleanにしたりstringにしたりしているのが気になりますけど、phpでは気にしなくて良いのでしょうか? -- [[ぃぉぃぉ]] &new{2007-08-28 (火) 03:40:47}; -- PHPマニュアルの変数の項を参照下さい。初期化さえしっかりしてれば問題にはなりません。submitの初期状態を明確にし、またtoggleしている部分を完結に表現するために前段をbooleanに揃えてみたただけです。 -- [[henoheno]] &new{2007-08-29 (水) 01:41:36}; -- マニュアル見てみました。とりあえずNoticeも何も出ていないので問題はなさそうですね。本題から離れるので雑談にちょっと記載します。 -- [[ぃぉぃぉ]] &new{2007-08-30 (木) 01:51:47}; - こちらの(というか、そちらのお手元の)ソース、$vars['helpoff'] の無い状態に整理しておいて下さい :) -- [[henoheno]] &new{2007-09-03 (月) 00:13:26}; - $vars['help_on']を使うようにしました。$vars['showhelp']でも良かったのですが、なんとなく^^; -- [[ぃぉぃぉ]] &new{2007-09-03 (月) 02:34:41}; - お疲れ様です。こちらの件、もう少し簡素にできないでしょうか: -- [[henoheno]] &new{2007-09-12 (水) 00:32:51}; $help_on = isset($vars['help_on']) ? $vars['help_on'] : FALSE; $help_on = $help_on ^ isset($vars['help']); -- 一行目でstringかbool(FALSE)が変数に入っていますから、FALSEには何か特別な意味があるのだろうと思ったのですが、二行目でboolとのビット演算(XOR)をされています。bool型は強制的に1ビットの整数に変換され、文字列は強制的に1ビット以上の整数になるでしょうから、二行目では1ビットと1ビット、ないしNビット(string由来)と1ビットのXORが行われています。ビット数の異なる値のXORが起こる部分や、複数ビット同士のビット演算のために使うだろう ^ 演算子が使われている部分は多分意図されていなくて、実際に表現されたいのは1ビット同士のXORのはずです。どうしてもXORにこだわるなら、こんな感じに変形できると思います: $help_on = isset($vars['help_on']) ? (bool)$vars['help_on'] : FALSE; // bool world $help_on = (isset($vars['help']) xor $help_on); // bool world: 優先順位が低いので、カッコ必須 -- 論理演算子とbit演算子を区別していませんでした。失礼しました。xorに修正しました。&br;$vars['help_on']はboolを渡しています。$help_on、$vars['help_on']はboolで統一していますので、^をxorに修正するだけで良いと思います。 -- [[ぃぉぃぉ]] &new{2007-09-12 (水) 12:28:46}; -- どうして [[cvs:../devel/followup_html/form_submit.php]] でこの手のstatusを "on" "off" として出力しているのかといえば、それは「いつかデバッグがしやすくなる様に」です。HTMLとして出力される $help_on がどうなっているか、また $vars['help_on'] の型が何であって中身がどうなっているかを確認しておいて下さい。 -- [[henoheno]] &new{2007-09-13 (木) 23:13:02}; -- boolの値を収めた変数をechoしたとしてもユーザーに届く値はstringです。また、ユーザーから得られる値は通常必ず任意の(binary)stringです。 -- [[henoheno]] &new{2007-09-27 (木) 00:31:41}; #comment ** コメント: ユーザーインターフェース同士の関係性 [#v16bd7c3] - 「プレビューのボタン」と、「プレビューの亜種であるところのこのボタン」は、「一つのボタンと、二つのチェックボックス」で表現できないでしょうか。ボタン名が悩ましいですが例えば「リロード」とか。 -- [[henoheno]] &new{2007-08-20 (月) 00:21:15}; -- 「一つのボタンと二つのチェックボックス」で表現は簡単そうな気がしますが、良いレイアウトが浮かびません。現状の「整形ルール表示」や「プレビュー」ボタンは1クリックでその動作をしてくれますので直感的に操作できますが、チェックボックスのチェックをしてからボタンクリック、という1アクション増えると、パソコンに不慣れな人には辛くなるかな、と。&br;おじいちゃんおばあちゃんに使わせようと頑張っているのでｗ -- [[ぃぉぃぉ]] &new{2007-08-22 (水) 01:36:56}; -- 機能ごとにボタンが一つあるというのは確かにそこだけ見ると解り易いでしょう。しかしその発想だけでは逆の(コストを減らす)発想が無いのでバランスが悪く、新しいアイデアが生まれる度に編集画面にボタンが増えてしまう様な方向に繋がりかねません。もし結果的に得られるのであれば、ニーズと経済性が上手に折り合った、エレガントな回答が欲しいです。(シェイプアップさせる事で、新しい価値がそこから見出されるならなお良し) -- [[henoheno]] &new{2007-08-23 (木) 01:05:36}; -- レイアウトについてはこんなイメージでいました。集約させるボタンの名前、もっといいのがあるといいのですが。 -- [[henoheno]] &new{2007-08-23 (木) 01:06:14}; [ リロード ] □プレビュー □整形ルール [ ページの更新 ] □タイムスタンプを維持 [ キャンセル ] -- 「整形ルールを表示する」というのをわかりやすく省略するのが難しいなあ、と考えています。上のhenohenoさんの案の整形ルールだと、「整形ルールに従って整形してくれるのかな?」みたいな感じがしませんか?我々のようにPukiWiki使用経験がある程度以上あるものならすぐに分かりますけど。これなら現状の方がわかりやすいな、と自分は思います。henohenoさんの案に似ていますが □タイムスタンプを維持[ ページの更新 ] □プレビューON □整形ルール表示 [ 実行 ] [ キャンセル ] というのは考えてみましたが、この長さなら現状の方がよいな、と。衝突検知等、他の機能が増えてボタンが増えそうなときにレイアウトを検討した方がよいのではないでしょうか。 -- [[ぃぉぃぉ]] &new{2007-08-23 (木) 01:17:54}; #comment ** コメント: 抽象化による展開例: 衝突検知など [#l911d7bf] - 「プレビューのボタン」と、「プレビューの亜種であるところのこのボタン」は、「一つのボタンと、二つのチェックボックス」で表現できないでしょうか。ボタン名が悩ましいですが例えば「リロード」とか。そんな方向に持って行くと、すぐには実現できないでしょうが、編集中に他人が同じページを更新してしまったかどうかをチェックする機構や、それを解決させる機構に収斂することができるのではないかナーと、ちょっと思いますがいかがでしょう -- [[henoheno]] &new{2007-08-20 (月) 00:21:15}; -- なるほど、編集の衝突のチェックですか。衝突対策の良い案があるといいですね。 -- [[ぃぉぃぉ]] &new{2007-08-22 (水) 01:36:56}; -- 衝突検知は今でもできる((だから衝突した事を知らせる事だけなら今すぐできる))けど、衝突解消をユーザーに促すためにはデータを保管するバックエンドや、内部関数や、編集フォームの部分をその視点で見直さないといけないでしょう。見本になるのは例えばCVSのconflictですが、Wikiの更新とソースコード管理システムのコミットは求められる更新頻度やスピードが大きく異なるものですから、乱雑にハックしたものが本当の意味で実用(万人向け)になるとは思っていないです。 -- [[henoheno]] &new{2007-08-23 (木) 00:50:50}; -- 衝突検知に関しては、確かに実用的なものというのは難しいと思います。&br;ですので、現状ではレイアウトやデザインにそのことを絡めて考える必要はなさそうですね。現状に近づけた、上の添付画像のもので十分実用になると思います。(自分のサイトでは、デモしていたようにこの状態で運用しています。) -- [[ぃぉぃぉ]] &new{2007-08-23 (木) 01:08:08}; #comment ** メタコメント: 既存実装とのバッティング (cancel時のpayload) [#g276085f] - lib/html.php の edit_form() で、cancelが本文をPOSTしないようになった [[BugTrack2/160]] の工夫が殺されてしまっておるようです -- [[henoheno]] &new{2007-08-12 (日) 23:34:02}; -- 動作的にはplugin/edit.inc.phpで対応済みの様です。$vars['cancel']が存在するとリロードするようになっています。([[BugTrack2/160]]の工夫とはこのことでよろしいのでしょうか?) -- [[ぃぉぃぉ]] &new{2007-08-14 (火) 20:27:14}; -- お疲れ様です。BugTrack2/160 の工夫 というのは、"「キャンセル」ボタンを別formに。" とある部分の事を差しています。別formでなくなってしまっているので、cancelボタンをクリックした時のペイロードが大きくなります(不要なデータを沢山送りつけてしまいます)。 -- [[henoheno]] &new{2007-08-16 (木) 00:06:46}; -- なるほど。cancel時はPOSTデータのほとんどが不要ということですね。この不要なPOSTデータをやめるには、 +++「テキスト整形のルールを表示する」ボタンをCANCELボタンより上に持ってくる +++CANCELをボタンではなくリロードと同じリンクとする&br; という方法が考えられますね。自分としてはCANCELボタンの使用頻度は低いので、CANCEL時の冗長なデータは気にしませんが^^; -- [[ぃぉぃぉ]] &new{2007-08-16 (木) 04:11:22}; - ふむふむ、考え方が理解できました。edit_form の payload はそもそも無駄なものを抱えている節がある (('original'の件。設計上の、またはアーキテクチャの問題と思われる))ため、別のいいアイデアやデザインの都合があって、どうしてもformを一つにしなければならないなら、それは仕方ないと思っています。また、cancelのformが分けてあるかどうかは確かに死活問題ではないので、とりあえず cancel のために form が分けてあるかどうかという件は無視して、パッチを理解する方に戻りたいと思います -- [[henoheno]] &new{2007-08-19 (日) 00:26:36}; -- よろしくお願いします。 -- [[ぃぉぃぉ]] &new{2007-08-19 (日) 02:18:30}; - こちらの件、上に画像で提示したレイアウトから考えるに、バッティングしていない([[BugTrack2/160]]のアイデアを打ち消す必然性がない)様に見えてきました。本当でしょうか。バッティングしていないのに破壊しているとしたら、上のコードの主張は結構乱暴なので、大人しい状態に直す事ができるでしょう。 -- [[henoheno]] &new{2007-08-27 (月) 23:48:22}; -- 少し上のa.「テキスト整形のルールを表示する」ボタンを(ソース上で)CANCELボタンより上に持ってくる が可能であれば、その通りだと思います。&br;css(よく分かってません^^;)で頑張れば出来そうな気もします。skinに影響が出るかな? -- [[ぃぉぃぉ]] &new{2007-08-28 (火) 02:43:29}; -- ? (^^; あ、そうか・・・ちょっと適当言ってたみたいです。申し訳ありません。 -- [[henoheno]] &new{2007-08-29 (水) 01:45:09}; -- 了解っす^^; -- [[ぃぉぃぉ]] &new{2007-08-30 (木) 01:50:40}; #comment ** メタコメント: パッチ(差分)に関して [#z0182e6c] - 見た目を含めて検討したかったのですが、上記のパッチはそれぞれどのリビジョンに対するものでしょう。 html.php で言えば $help_on といった変数は無いので、何か部分的なパッチのようにも思えます。 -- [[henoheno]] &new{2007-08-05 (日) 17:32:51}; -- 元になっているのはPukiWiki Ver.1.4.7_notbです。&br;$help_onはローカル変数で上記パッチで新設したものです。getメソッドでの&help=onの場合の挙動は変更ありません。(上記パッチを当ててもヘルプありの編集画面となります。) -- [[ぃぉぃぉ]] &new{2007-08-05 (日) 18:08:20}; --- はい、$help_on はこのパッチで用意された変数ですよね。それなのに以下の部分は $help_on が以前から存在したかのような表現になっているのです -- [[henoheno]] &new{2007-08-05 (日) 19:00:38}; if ($help_on) { $body .= $hr . catrule(); } --- [[フォーム生成部改造のhtml.phpのfunction edit_form() のL.240あたり>./#l240]]、の最初の部分で$help_onの値を生成しています。 -- [[ぃぉぃぉ]] &new{2007-08-05 (日) 19:04:49}; --- はい、そしてそのパッチの最後の部分にある、 + でも - でもない部分で $help_on が登場していますが、そこの部分が不思議なのです。何か勘違いしているかな・・・ -- [[henoheno]] &new{2007-08-05 (日) 21:00:42}; --- 失礼しました。その３行も+です。(修正しました) -- [[ぃぉぃぉ]] &new{2007-08-05 (日) 22:52:47}; #comment
テキスト整形のルールを表示する
添付ファイル:
BugTrack2-266_ioio_01_buttonB.png
449件
[
詳細
]
BugTrack2-266_ioio_01_buttonA.png
580件
[
詳細
]
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
BugTrack2-266_ioio_01_buttonB.png
BugTrack2-266_ioio_01_buttonA.png
