>> 7
1段階目の削除の後同じ名前で添付できますよ？
試したことがないので分かりませんが バックアップにはどのような形で、添付名で残るのでしょうか？
管理者の負担軽減の為に同じページもしくは同じ名前のバックアップは選択削除や一括削除があればいいんですけど。
それは難しいかも知れません。 ページなどのバックアップ等一括削除などは ページ破壊されてしまったときバックアップがないと 復旧することが出来なくなるので運営が認めないと思います。 こちらが思っていることは あくまでも個々でアップした添付ファイルを個々でバックアップも含めた削除の事で ページについては現状のまま管理者が管理を行えば良いと思っています。
間違えて添付しても削除して添付しなおすことは可能なので、都度管理者にお願いする必要はないと思います。 ただ、バックアップの削除は管理者にお願いすることになります。 現在のバックアップの削除は一つ一つパスワード入力が必要なのでバックアップが多いと管理者が大変です。 管理者の負担軽減の為に同じページもしくは同じ名前のバックアップは選択削除や一括削除があればいいんですけど。
ご返信ありがとうございます。
管理者しか削除できないのは「バックアップ」です。 添付ファイルは誰でも削除可能です。
こちらも繰り返しになりますが バックアップが残ると次にアップする際、同じ名前では添付出来ませんので それも含めて削除できるようにして頂きたいと思います。
ファイルの削除はこれまで通り誰でも行え、 バックアップの削除のみ 管理者に加えてアップロード者も行えるようにするという木主の案ならば 管理上の問題・不都合は生じないだろうと思われるので、 それが可能なら自分も賛成です。
ご賛同いただきありがとうございます。
現在2段階で削除できるようになっていますが 1段階目で従来通り、誰でも削除でき（バックアップは残ります） 2段階目でバックアップの削除のみ管理者に加えてアップロード者も行えるようにする。
また、あくまでもこちらの案としてですがドロップダウン方式にして 一般（ここは誰でもOK）、アップロード者、管理者と分けて パスワードを入力できるようにするのもありかと思います。（管理者のみ全てに対応）
ただし、パスワードシステムの導入と、 それを管理者だけに可視化できるようにする必要があろうかと思うので、 大規模なシステム改修が必要になる気がします。 なので、運営がそこまでやってくれるかは大いに疑問です。
現在のシステムに、少し手を加えると言う方法があればよいのですが こちらの方は、運営でないと分かりませんので、何とも言えないところです。
また、これらの内容で変わる良い方法があれば、それでも構わないのですが。
各自で添付したファイルを削除するのに 何故、管理者の判断になるのかが分かりません。
繰り返しになりますが、 管理者しか削除できないのは「バックアップ」です。 添付ファイルは誰でも削除可能です。
管理者がページをきちんと管理できていなかったり 連絡がつかない場合などは非常に不便です。
前提とすべきは、きちんと管理されているwikiです。 仰っている事情は、 そのwikiの特別な事情になってしまいます。
ファイルの削除はこれまで通り誰でも行え、 バックアップの削除のみ、管理者に加えてアップロード者も行えるようにするという木主の案ならば、 管理上の問題・不都合は生じないだろうと思われるので、 それが可能なら自分も賛成です。
ただし、新たなパスワードシステムの導入と、 それを管理者だけに可視化できるようにする必要があろうかと思うので、 大規模なシステム改修が必要になる気がします。 なので、運営がそこまでやってくれるかは大いに疑問です。 なぜなら、この案件は、
この何れかで対処できてしまう案件だからです。
追記： そういえば、バックアップの自動作成はアップロード時ではなく、 ファイルの削除時だった気がします。 そうなるとパスワードシステムは成立しない気もします。
そもそも、各自で添付したファイルを削除するのに 何故、管理者の判断になるのかが分かりません。 添付した各自の判断で問題ないと思います。
しかも、添付ファイルが簡単に削除できなければ 添付するのも躊躇してしまいます。
他の管理者様・利用者様のご意見もお伺いしたいです。
ご意見 ありがとうございます。
誰でも行えないのは「バックアップ」の削除
バックアップが残ると次にアップする際同じ名前では添付出来ませんので それも含めて削除できるようにして頂きたいです。
荒らしがイタズラでアップした画像が誰も消せなくなってしまうので
そのあたりは2段階になっていますので1段階目で誰でも削除できるようにして 2段階目（バックアップ）はアップロードの際にパスワードの設定で完全削除と言う形ではいかがでしょうか？ もちろん管理者はパスワードに関係なく削除できるようにすれば問題ないかと思いますが いかがでしょうか？
勘違いされているかも知れませんが、 添付画像の削除は誰でも行えます。 誰でも行えないのは「バックアップ」の削除で、 削除された画像のバックアップをどうするかは管理者の判断になります。
ページでも画像でも、バックアップが誰でも消せないのは、 ページや画像の削除が誰でも行えることの裏返しでもあります。 バックアップが残っていれば、 悪意を持った誰かに削除されても復旧できるからです。
アップロードの際にパスワードを設定するのは可能かも知れませんが、 そうすると荒らしがイタズラでアップした画像が誰も消せなくなってしまうので、 論外だろうと思います。
自動削除のONにしない限り自動的に削除されないというのはどうですか？
以下の可能性があるので自動で削除されては困ります。
改めて。<td style="display:none;"></td>このやり方は悪くない気がしてきました。htmlのルール的に問題がなければ。
<td style="display:none;"></td>
|A|1| |~|2| |B|3|
こう書いて|~|の部分を<td style="display:none;">A</td>と変換すれば、 fix-colの解決と同時に、結合を使ったtablesortが壊れる問題の解決の足掛かりにならないでしょうか。 tablesortをどう実現してるのかわかってないですが、ソートを掛けたときだけrowspanやdisplayの記述を無視あるいは削除してくれれば、ソートしても崩れないような気がします。
<td style="display:none;">A</td>
またすでにある書式の|~|の変換ルールを変えると影響が見えないので、新しい書式として例えば|^|みたいな書き方で上記変換に対応されれば互換性の問題が回避できないでしょうか。
検証できてませんが、tablescrollの高さ指定を数値(px)固定だけではなく、%とかautoとか使えるようになれば閲覧環境の違いは対処できそうな気がします。
ページ毎に表示高さを変えるほうは、tablescroll側が自在になればcssboxの高さ指定と連動してコントロールできるのか?あるいはoverflowというプロパティが使えればいいのか? overflowは現在使えませんが、試しに直接htmlに追記するとboxで指定した高さを内容がはみ出さすときはスクロールバーが出るようです。tablescrollの件とは関係なくoverflowは使い勝手があるかもしれません。
7) 先頭列が縦方向に結合した状態でfix-colを使うと|~|の隣の2列目が固定される問題
htmlの知識はないですが、中を覗いて見た感じ結合セル|~|の部分は記述が省略されるようで、 一方fix-colはhtmlの各行一番最初の要素を拾って固定するという動作のようで、 つまり|~|の隣に記述した|2列目|が先頭要素という扱いになってしまっているように見えます。 試しに|~|があるべき位置に<td style="display:none;"></td>とか不可視のダミーセルを記述して辻褄を合わせると、それが先頭列として拾われて期待通りに動作するようです。
ただこれを自動でやるにはtablescrollの機能ではなく、元々のテーブルの変換規則を変更する必要があるはずで、全体として成り立つのか考慮が必要でしょう。 他のtablesortも結合があると期待通りに動作しないのは従来からで、これらを利用するときは結合を避けるという運用となるか。
なお横結合|>|は左詰めになるようですが、今のところ問題は見えません。しかし同様に先頭から何番目みたいな指定があるときは同様の考慮が必要と思われます。
Wikiトップページで試したところ、ヘッダ行でなくても起こるようです。
#tablescroll{{
有用なプラグインの実装ありがとうございます。 画像はこちらのページで試した結果です。以下の赤枠を修正してほしいです。ヘッダ行が2列以上あるときに起こるようです。
#tablescroll(fix-col)
#tablescroll(screen-sticky){{
実装ありがとうございます。大型の表を閲覧しやすくなりました。
大変助かっているのですが、１つ問題点を確認しています。 先頭列のヘッダーが縦に結合していると、fix-colで先頭列以外のヘッダーセルが固定されてしまいます。
以下に一例を示します。
#tablescroll(,fix-col){{ |~先頭ヘッダー|>|~項目カテゴリー|~その他|h |~|~項目A|~項目B|~|h ||||500|c |~先頭|||| }}
この表を右にスクロールしていくと、『項目A』が『先頭ヘッダー』の上に重なってしまうのがわかると思います。
追記: このような場合でも、先頭列のみが固定されるようになるとありがたいです。
「画面上部にヘッダ貼り付け」で、横はみ出しが切れないようにしてほしいです。 何とかならないでしょうか？
ページ編集フォームごと表示されないようです
さらに。 行と列の追加、挿入、削除、コピペが出来るように。 特に列は従来エディタだと面倒だったところ。ミスをすると表が崩れて壊滅的になり、しかもどこを間違えたのか捜索が大変。巨大な表だとスプレッドシートを使うか正規表現置換を駆使する必要があるが、出来る人は限られる。
セル内改行を&brとするか↲キーで可能にするかはエディタの表示メニューで選択。
スプレッドシートから範囲コピペ可能に。
0ベースで検討できる贅沢な状況のようですが。 閲覧状態から対象箇所を直接指定で編集できるのは魅力的です。｜棒が沢山並んだ巨大な表のソースでは、どこを編集してるのかわからないので、大抵スプレッドシートに展開してから編集してます。 一方でそれをダブルクリックなどで手軽に編集可能になってしまうと、誤操作や意図せぬ書き換え、イタズラの敷居が下がります。 またもし一箇所ごとに変更が反映されるなら、その度に更新が入り負荷が高そうです。編集が競合したときどうなるのかも気になります。
見出し内編集のように特定のボタンを押すと表編集エディタが開くのが良いと思います。ボタンは表外の右上が良いと思います。目に付きにくい所がいいです。
エディタはスプレッドシートのように扱えると良いです。つまり縦横二次元の表のまま、コピペ、範囲指定、セルごとの書式など操作できるように。ショートカットやスマホで操作出来るようボタンメニューも。左側に入力エリア、c書式行や//コメント行を含めて。(UI的にコメント行が難しければなしで)。右側にプレビュー画面。
エディタは通常編集画面からも呼び出せると良い。
上記だけだとプラグインではなく、見出し内編集のように標準組み込みでも良いかもしれません。ただ完成した表をロックしたいとかあるかもしれないので、逆にプラグインで編集ロックできると良いかも。既にそんなプラグインがあったような。
私の場合zrecentはコメント更新確認の目的で使っているので、新規トピックや本文側の更新が反映されなくても不便は無いです。
zawazawaをwikiwikiのコンテンツのコメント機能のために使うのか、zawazawaの内容を方を主としてそちらの状況をwikiwikiで確認したいのかの違いだと思いますが、zrecentはpcommentの代替として前者の目的で登場したと思います。
機能拡張しても損はないとおもいますが。例えば本文をコメント0番として反映させるとか。
6) 状況に応じて縦スクロール幅制限を外したい 私も似たような問題ですが、以下の条件を同時に満たしたいです。
ページ構成
期待する動作
問題点
#tablescroll(高さ指定){{ #popout{ includex(表ページ) }} }}
どうなれば良いか tablescrollで高さ未指定時は最大とし、表示領域の高さ指定は別のプラグインで担当する。 時間がないので試せてないですが、cssboxの高さ指定でできるだろうか。
本文ページ #表示領域指定プラグイン(高さ){{ includex(表ページ) }} 表ページ #popout{{ #tablescroll(高さ最大){{ |表| }} }}
>画面上部にヘッダ貼り付け >横はみ出しは切れる。 なのですが、横はみ出しは切れないように（というより先頭列を固定した横スクロールと併用できるように）ならないでしょうか？
上2つだと、高さを指定しなければならず、スクロールバーを複数設定したくない・レイアウト的に表全体が見えてほしい、という場合に不便があります。
確認いたしました。期待していた挙動です。修正ありがとうございます。 より深いところ、プラグイン名やパラメータのパターンマッチのところに原因があったのですね。根源の調査と根本的な対策、その修正規模感に比してとても素早い対応をしていただき、ありがとうございました。
自分は最近使い始めたばかりですが、新着が表示されないことに今まで誰も不満が無いのであれば需要が無いということなのでしょうか？ 他に利用されている方のご意見も聞きたいです。
もし改善される見込みがある場合の仕様提案です ・現在の表記はタイトル全文が表示されて長すぎることがあるのである程度の文字数以降は省略する ・新着トピックにNewをつける
こんなイメージです
24時間以内に投稿 ・新たな編集可能テーブルプラグイン(table_edit2.inc... 2023-06-07 ・表の見出しを固定する機能 ・zrecentプラグインで表示されないトピックがある ・「recent」ページ名でフィルタをかけられるようにする... ・ ページ名変更と一括変換機能をサブパスワード保持者に... 2023-06-06 ・flexboxの境界線と背景色指定 ・コメントフォームでの画像展開時のリロード不具合 ・tooltipプラグインのterm引数に、他のインラインプラ... ・構文解析の不具合仕様について New
仕様が古く実装できなかったのですね、それは失礼いたしました
自分がよく編集しているWikiにはこのようなとてつもないサイズの表があるのですが、入力する量が多いため、入力フォームを作成できるようになればかなり楽になると思います また、この表は下にどんどん追加していくという追記のやり方よりは、対応するグループに応じて間に挿入していく追記がメインですので、
表のセルをダブルクリックするとセルが入力フォームになって直接入力できる
もしこのような実装に決定した場合、下の行を追加するような機能もあると嬉しいです
ただ、直近のアップデートでスプレッドシートからコピペで表を貼り付けできるようになったので スプレッドシートを運用するのであればプラグインが拡張することに魅力はあまり感じないのかなと思います。
複数人でスプレッドシートをメンテできるのと、Wiki側で表を調整できる人が1人いればいいので
これは魅力を感じました。
表の角のアイコンをクリックするとGoogleスプレッドシートのような入力画面になる データベースからレコードを操作して表を作成したり書き込んだりできる
試験実装ありがとうございます。非常に使いやすいです。 大きな問題ではないのですが、popupプラグインを併用したときに、新規ページとして開かれた表がスクロールなしになるようにプラグインを記述する(*1)と、表と一緒にpopupのボタンもスクロールされるようになってしまうので、できればスクロールされないような記述が可能になると、より使いやすくなるだろうなと感じました。
※1 tablescroll→popup→その他プラグイン(tablesortなど)の入れ子
システム的にこのプラグインを導入することはできません。 同等の機能で新しく作ることは可能ですが、このプラグインの仕様は古すぎます。 新しい仕様をご検討いただけたら幸いです。
例えば
などです。
引き続き議論をお願いいたします。🙇♂️
需要があれば導入いたしますので、引き続き議論いただけたら幸いです。 仕様など(例えばリストのリンク先はどうするのか、表記はどのようにするのか)もお考えください。
こちらのプラグイン、技術的に問題があるのでなければ再度検討願いたいです
遅くなりました。 希望のものが実装されております。ありがとうございました。
たしかに管理者の負担が大きい部分はあります 例えば、サブパスワード保持者がリネームをリクエストして、管理者が承認後に自動でコマンドが発行されるような仕組みがあれば最終的な判断は管理者というのは変わりはないので便利かもしれません。
いずれにしてもリネームが管理者1人しかできないというのは、何か手を加えてほしいところではあります。
あくまで仕様なので、変更をするつもりはないということでしょうか。残念です。
WIKIWIKI さんぷるWIKIのMenuBarでも以下のようにwikiwiki officialのトピックを表示しようとしていますが公式が投稿したトピックが広く周知されないのはいかがなものかと思いますが・・・
*zawazawaの最新のトピック [#zc67eff8] #zrecent(wikiwiki,wikiwiki-help,wikiwiki-request)
元々ブロック型プラグインではダブルクオートで囲めばよかったんですね。 csssboxプラグインの説明ページでもダブルクオートで囲んだ例に変えていただいた方がわかりやすいと思います。 ご回答ありがとうございました。
1) fix-colは対象列が"|~A|"だと機能しない
2) 罫線はオリジナルと同じに
見出し行の直後に表が配置されているページにおいて、表をスクロールするときに少しだけヘッダー行が移動してしまいます。
フィードバックありがとうございます。 ひとまず上記の不具合を修正しました。
引き続きよろしくお願いします。
連絡が遅くなりました。 さきほど閲覧数の多いページへプラグインを導入中に罫線が細くなったのを確認しました。 とりあえずの要望としては細いのを希望しようと考えおりましたので助かりました。ありがとうございます。
申し訳ございません。 #zrecentは最新のコメントリストを出力するプラグインです。 トピックの更新は対応しておりません。
#zrecent
解決済とさせていただきます。
仕様です。
#foldはブロック型プラグインです。 行頭に書いて使います。
#fold
#pcommentは指定されたページのコメントリストを表示しています。 リスト内にブロック型のプラグイン書式が挿入されると正しく表示されないことがあります。
#pcomment
>> 7
試したことがないので分かりませんが
バックアップにはどのような形で、添付名で残るのでしょうか？
それは難しいかも知れません。
ページなどのバックアップ等一括削除などは
ページ破壊されてしまったときバックアップがないと
復旧することが出来なくなるので運営が認めないと思います。
こちらが思っていることは
あくまでも個々でアップした添付ファイルを個々でバックアップも含めた削除の事で
ページについては現状のまま管理者が管理を行えば良いと思っています。
1段階目の削除の後同じ名前で添付できますよ？
間違えて添付しても削除して添付しなおすことは可能なので、都度管理者にお願いする必要はないと思います。
ただ、バックアップの削除は管理者にお願いすることになります。
現在のバックアップの削除は一つ一つパスワード入力が必要なのでバックアップが多いと管理者が大変です。
管理者の負担軽減の為に同じページもしくは同じ名前のバックアップは選択削除や一括削除があればいいんですけど。
ご返信ありがとうございます。
こちらも繰り返しになりますが
バックアップが残ると次にアップする際、同じ名前では添付出来ませんので
それも含めて削除できるようにして頂きたいと思います。
ご賛同いただきありがとうございます。
現在2段階で削除できるようになっていますが
1段階目で従来通り、誰でも削除でき（バックアップは残ります）
2段階目でバックアップの削除のみ管理者に加えてアップロード者も行えるようにする。
また、あくまでもこちらの案としてですがドロップダウン方式にして
一般（ここは誰でもOK）、アップロード者、管理者と分けて
パスワードを入力できるようにするのもありかと思います。（管理者のみ全てに対応）
現在のシステムに、少し手を加えると言う方法があればよいのですが
こちらの方は、運営でないと分かりませんので、何とも言えないところです。
また、これらの内容で変わる良い方法があれば、それでも構わないのですが。
繰り返しになりますが、
管理者しか削除できないのは「バックアップ」です。
添付ファイルは誰でも削除可能です。
前提とすべきは、きちんと管理されているwikiです。
仰っている事情は、
そのwikiの特別な事情になってしまいます。
ファイルの削除はこれまで通り誰でも行え、
バックアップの削除のみ、管理者に加えてアップロード者も行えるようにするという木主の案ならば、
管理上の問題・不都合は生じないだろうと思われるので、
それが可能なら自分も賛成です。
ただし、新たなパスワードシステムの導入と、
それを管理者だけに可視化できるようにする必要があろうかと思うので、
大規模なシステム改修が必要になる気がします。
なので、運営がそこまでやってくれるかは大いに疑問です。
なぜなら、この案件は、
この何れかで対処できてしまう案件だからです。
追記：
そういえば、バックアップの自動作成はアップロード時ではなく、
ファイルの削除時だった気がします。
そうなるとパスワードシステムは成立しない気もします。
そもそも、各自で添付したファイルを削除するのに
何故、管理者の判断になるのかが分かりません。
添付した各自の判断で問題ないと思います。
管理者がページをきちんと管理できていなかったり
連絡がつかない場合などは非常に不便です。
しかも、添付ファイルが簡単に削除できなければ
添付するのも躊躇してしまいます。
他の管理者様・利用者様のご意見もお伺いしたいです。
ご意見 ありがとうございます。
バックアップが残ると次にアップする際同じ名前では添付出来ませんので
それも含めて削除できるようにして頂きたいです。
そのあたりは2段階になっていますので1段階目で誰でも削除できるようにして
2段階目（バックアップ）はアップロードの際にパスワードの設定で完全削除と言う形ではいかがでしょうか？
もちろん管理者はパスワードに関係なく削除できるようにすれば問題ないかと思いますが
いかがでしょうか？
勘違いされているかも知れませんが、
添付画像の削除は誰でも行えます。
誰でも行えないのは「バックアップ」の削除で、
削除された画像のバックアップをどうするかは管理者の判断になります。
ページでも画像でも、バックアップが誰でも消せないのは、
ページや画像の削除が誰でも行えることの裏返しでもあります。
バックアップが残っていれば、
悪意を持った誰かに削除されても復旧できるからです。
アップロードの際にパスワードを設定するのは可能かも知れませんが、
そうすると荒らしがイタズラでアップした画像が誰も消せなくなってしまうので、
論外だろうと思います。
自動削除のONにしない限り自動的に削除されないというのはどうですか？
以下の可能性があるので自動で削除されては困ります。
改めて。
<td style="display:none;"></td>このやり方は悪くない気がしてきました。htmlのルール的に問題がなければ。こう書いて|~|の部分を
<td style="display:none;">A</td>と変換すれば、fix-colの解決と同時に、結合を使ったtablesortが壊れる問題の解決の足掛かりにならないでしょうか。
tablesortをどう実現してるのかわかってないですが、ソートを掛けたときだけrowspanやdisplayの記述を無視あるいは削除してくれれば、ソートしても崩れないような気がします。
またすでにある書式の|~|の変換ルールを変えると影響が見えないので、新しい書式として例えば|^|みたいな書き方で上記変換に対応されれば互換性の問題が回避できないでしょうか。
検証できてませんが、tablescrollの高さ指定を数値(px)固定だけではなく、%とかautoとか使えるようになれば閲覧環境の違いは対処できそうな気がします。
ページ毎に表示高さを変えるほうは、tablescroll側が自在になればcssboxの高さ指定と連動してコントロールできるのか?あるいはoverflowというプロパティが使えればいいのか?
overflowは現在使えませんが、試しに直接htmlに追記するとboxで指定した高さを内容がはみ出さすときはスクロールバーが出るようです。tablescrollの件とは関係なくoverflowは使い勝手があるかもしれません。
7) 先頭列が縦方向に結合した状態でfix-colを使うと|~|の隣の2列目が固定される問題
htmlの知識はないですが、中を覗いて見た感じ結合セル|~|の部分は記述が省略されるようで、
一方fix-colはhtmlの各行一番最初の要素を拾って固定するという動作のようで、
つまり|~|の隣に記述した|2列目|が先頭要素という扱いになってしまっているように見えます。
試しに|~|があるべき位置に
<td style="display:none;"></td>とか不可視のダミーセルを記述して辻褄を合わせると、それが先頭列として拾われて期待通りに動作するようです。ただこれを自動でやるにはtablescrollの機能ではなく、元々のテーブルの変換規則を変更する必要があるはずで、全体として成り立つのか考慮が必要でしょう。
他のtablesortも結合があると期待通りに動作しないのは従来からで、これらを利用するときは結合を避けるという運用となるか。
なお横結合|>|は左詰めになるようですが、今のところ問題は見えません。しかし同様に先頭から何番目みたいな指定があるときは同様の考慮が必要と思われます。
Wikiトップページで試したところ、ヘッダ行でなくても起こるようです。
#tablescroll{{
有用なプラグインの実装ありがとうございます。
画像はこちらのページで試した結果です。以下の赤枠を修正してほしいです。ヘッダ行が2列以上あるときに起こるようです。
#tablescroll{{
#tablescroll(fix-col)
#tablescroll(screen-sticky){{
実装ありがとうございます。大型の表を閲覧しやすくなりました。
大変助かっているのですが、１つ問題点を確認しています。
先頭列のヘッダーが縦に結合していると、fix-colで先頭列以外のヘッダーセルが固定されてしまいます。
以下に一例を示します。
この表を右にスクロールしていくと、『項目A』が『先頭ヘッダー』の上に重なってしまうのがわかると思います。
追記: このような場合でも、先頭列のみが固定されるようになるとありがたいです。
「画面上部にヘッダ貼り付け」で、横はみ出しが切れないようにしてほしいです。
何とかならないでしょうか？
ページ編集フォームごと表示されないようです
さらに。
行と列の追加、挿入、削除、コピペが出来るように。
特に列は従来エディタだと面倒だったところ。ミスをすると表が崩れて壊滅的になり、しかもどこを間違えたのか捜索が大変。巨大な表だとスプレッドシートを使うか正規表現置換を駆使する必要があるが、出来る人は限られる。
セル内改行を&brとするか↲キーで可能にするかはエディタの表示メニューで選択。
スプレッドシートから範囲コピペ可能に。
0ベースで検討できる贅沢な状況のようですが。
閲覧状態から対象箇所を直接指定で編集できるのは魅力的です。｜棒が沢山並んだ巨大な表のソースでは、どこを編集してるのかわからないので、大抵スプレッドシートに展開してから編集してます。
一方でそれをダブルクリックなどで手軽に編集可能になってしまうと、誤操作や意図せぬ書き換え、イタズラの敷居が下がります。
またもし一箇所ごとに変更が反映されるなら、その度に更新が入り負荷が高そうです。編集が競合したときどうなるのかも気になります。
見出し内編集のように特定のボタンを押すと表編集エディタが開くのが良いと思います。ボタンは表外の右上が良いと思います。目に付きにくい所がいいです。
エディタはスプレッドシートのように扱えると良いです。つまり縦横二次元の表のまま、コピペ、範囲指定、セルごとの書式など操作できるように。ショートカットやスマホで操作出来るようボタンメニューも。左側に入力エリア、c書式行や//コメント行を含めて。(UI的にコメント行が難しければなしで)。右側にプレビュー画面。
エディタは通常編集画面からも呼び出せると良い。
上記だけだとプラグインではなく、見出し内編集のように標準組み込みでも良いかもしれません。ただ完成した表をロックしたいとかあるかもしれないので、逆にプラグインで編集ロックできると良いかも。既にそんなプラグインがあったような。
私の場合zrecentはコメント更新確認の目的で使っているので、新規トピックや本文側の更新が反映されなくても不便は無いです。
zawazawaをwikiwikiのコンテンツのコメント機能のために使うのか、zawazawaの内容を方を主としてそちらの状況をwikiwikiで確認したいのかの違いだと思いますが、zrecentはpcommentの代替として前者の目的で登場したと思います。
機能拡張しても損はないとおもいますが。例えば本文をコメント0番として反映させるとか。
6) 状況に応じて縦スクロール幅制限を外したい
私も似たような問題ですが、以下の条件を同時に満たしたいです。
ページ構成
ほぼ表だけが書かれてるページ。簡単な凡例や説明書きなどはある。
includexで複数ページがから呼び出される。
ページソースは文書を主として、表(複数)をincludexで呼び出す。
期待する動作
文章の中に表を組み込んでいるため、表示されるとき表が大きすぎると邪魔。ページ全体に対する表の表示領域を限定したい。
表ページへリンクとPopoutを組み込んで、必要なときは表だけに着目できるようにする。
表ページ及びPopoutは表を最大限活用するために使う。
このときはページバランスを気にする必要はないので画面幅を最大限利用したい。
ただし表が大きすぎると、やはりヘッダーが画面の外に逃げてしまう問題はあるので、tablescrollは使いたい。
閲覧者ごとに表示環境が違うため、高さは固定値ではなく表示環境ごとの最大としたい。
同様に横が収まるか分からないのでfix-colも使いたい。
問題点
screen-stickyは高さ最大相当になるが、fix-colと同時に使えない。
またfix-colを使わずとも横方向にはみ出し部分は表示できない。
以下の書き方だと、表ページ及びPopout時にtablescrollが機能しない。
あるいは内側にtablescrollを入れれば高さ制限が掛かってしまう。
どうなれば良いか
tablescrollで高さ未指定時は最大とし、表示領域の高さ指定は別のプラグインで担当する。
時間がないので試せてないですが、cssboxの高さ指定でできるだろうか。
>画面上部にヘッダ貼り付け
>横はみ出しは切れる。
なのですが、横はみ出しは切れないように（というより先頭列を固定した横スクロールと併用できるように）ならないでしょうか？
上2つだと、高さを指定しなければならず、スクロールバーを複数設定したくない・レイアウト的に表全体が見えてほしい、という場合に不便があります。
確認いたしました。期待していた挙動です。修正ありがとうございます。
より深いところ、プラグイン名やパラメータのパターンマッチのところに原因があったのですね。根源の調査と根本的な対策、その修正規模感に比してとても素早い対応をしていただき、ありがとうございました。
自分は最近使い始めたばかりですが、新着が表示されないことに今まで誰も不満が無いのであれば需要が無いということなのでしょうか？
他に利用されている方のご意見も聞きたいです。
もし改善される見込みがある場合の仕様提案です
・現在の表記はタイトル全文が表示されて長すぎることがあるのである程度の文字数以降は省略する
・新着トピックにNewをつける
こんなイメージです
仕様が古く実装できなかったのですね、それは失礼いたしました
自分がよく編集しているWikiにはこのようなとてつもないサイズの表があるのですが、入力する量が多いため、入力フォームを作成できるようになればかなり楽になると思います
また、この表は下にどんどん追加していくという追記のやり方よりは、対応するグループに応じて間に挿入していく追記がメインですので、
もしこのような実装に決定した場合、下の行を追加するような機能もあると嬉しいです
ただ、直近のアップデートでスプレッドシートからコピペで表を貼り付けできるようになったので
スプレッドシートを運用するのであればプラグインが拡張することに魅力はあまり感じないのかなと思います。
複数人でスプレッドシートをメンテできるのと、Wiki側で表を調整できる人が1人いればいいので
これは魅力を感じました。
試験実装ありがとうございます。非常に使いやすいです。
大きな問題ではないのですが、popupプラグインを併用したときに、新規ページとして開かれた表がスクロールなしになるようにプラグインを記述する(*1)と、表と一緒にpopupのボタンもスクロールされるようになってしまうので、できればスクロールされないような記述が可能になると、より使いやすくなるだろうなと感じました。
※1 tablescroll→popup→その他プラグイン(tablesortなど)の入れ子
システム的にこのプラグインを導入することはできません。
同等の機能で新しく作ることは可能ですが、このプラグインの仕様は古すぎます。
新しい仕様をご検討いただけたら幸いです。
例えば
などです。
引き続き議論をお願いいたします。🙇♂️
需要があれば導入いたしますので、引き続き議論いただけたら幸いです。
仕様など(例えばリストのリンク先はどうするのか、表記はどのようにするのか)もお考えください。
こちらのプラグイン、技術的に問題があるのでなければ再度検討願いたいです
遅くなりました。
希望のものが実装されております。ありがとうございました。
たしかに管理者の負担が大きい部分はあります
例えば、サブパスワード保持者がリネームをリクエストして、管理者が承認後に自動でコマンドが発行されるような仕組みがあれば最終的な判断は管理者というのは変わりはないので便利かもしれません。
いずれにしてもリネームが管理者1人しかできないというのは、何か手を加えてほしいところではあります。
あくまで仕様なので、変更をするつもりはないということでしょうか。残念です。
WIKIWIKI さんぷるWIKIのMenuBarでも以下のようにwikiwiki officialのトピックを表示しようとしていますが公式が投稿したトピックが広く周知されないのはいかがなものかと思いますが・・・
元々ブロック型プラグインではダブルクオートで囲めばよかったんですね。
csssboxプラグインの説明ページでもダブルクオートで囲んだ例に変えていただいた方がわかりやすいと思います。
ご回答ありがとうございました。
フィードバックありがとうございます。
ひとまず上記の不具合を修正しました。
引き続きよろしくお願いします。
連絡が遅くなりました。
さきほど閲覧数の多いページへプラグインを導入中に罫線が細くなったのを確認しました。
とりあえずの要望としては細いのを希望しようと考えおりましたので助かりました。ありがとうございます。
申し訳ございません。
#zrecentは最新のコメントリストを出力するプラグインです。トピックの更新は対応しておりません。
解決済とさせていただきます。
仕様です。
#foldはブロック型プラグインです。行頭に書いて使います。
#pcommentは指定されたページのコメントリストを表示しています。リスト内にブロック型のプラグイン書式が挿入されると正しく表示されないことがあります。