Wiki系とWikiEngineについて語るスレーPart3

**nobodyさん** · 04/03/19 22:25

Part2　http://pc2.2ch.net/test/read.cgi/php/1060739206/
Part1　http://pc2.2ch.net/test/read.cgi/php/1014252667/

【関連】
Wiki Wiki　楽々 Run! Run! Run!
http://pc2.2ch.net/test/read.cgi/tech/1010317366/
日本発の wiki クローンリスト
http://www1.neweb.ne.jp/wa/yamdas/column/technique/clonelist.html
日本発の wiki クローンリスト２
http://www1.neweb.ne.jp/wa/yamdas/column/technique/clonelist2.html

78 · 04/04/14 23:20

BTMemoは実はチェック済みだった。お手数かけて申し訳ない。

いや、やっぱそんな上手い話はないもんですな。
とりあえずなんか考えてみようと思いまふ。

の · 04/04/15 01:38

>81
面白い！！面白い……でも、微妙……

個人的には、付箋はパーソナルツールとしての使い方しか思いつかないから、
Wikiみたいなコミュニケーションツールとの相性はどうなのかな？？と思う。

むしろ、blogとしての使い方のほうが相性にあっているような気がする。

……と思ったけど、線を活用すれば掲示板みたいにも使えるかな？
付箋だけじゃなくて、文章とか単語にぶら下がれるようだと面白いね。

＃Wiki+絵チャっつうのも試したいな……

**nobodyさん** · 04/04/15 01:42

「いまいちなので誰か直して」みたいなページそのものに関するコメントを
付箋するといいんじゃない。

**nobodyさん** · 04/04/15 01:48

>>81
>>83
KJ法に最適！

85 · 04/04/15 01:50

SandBoxとかぶってる…

の · 04/04/15 03:21

>85
ワシもそう思ったよ。みんなでやるＫＪ法ってどうなのかしらん？

**nobodyさん** · 04/04/15 11:19

>>81
はっつけすぎると致命的に重いね・・

**nobodyさん** · 04/04/15 12:42

NOTAはどっか導入するプロバイダあるのかな？

**nobodyさん** · 04/04/15 21:50

BTMemo漏れも試用してみたけど…、けど…。

リッチクライアントというには表現力が足りず、
ワープロ以外のコンポーネントがあるわけでもなく、
結局ハイパーテキストになってるというだけで、
自分の好きなようにカスタマイズ／機能拡張する余地がない。
Wikiスクリプトならプラグイン開発も本体いじりも簡単なのに。

VC++で直接ごりごり書くんじゃなく、Emacsなんかみたいに
インタプリタを内蔵してくれればと思う。
それかBTMemoがスクリプトホストになればいいんだろうな。

ちょっとずれるがBTRONの「超リンク」とか見てても筋が悪いなと思う。
機能が決めうちすぎて日誌書き以外の何にも使えない。
自動化の機構を提供するならならロジックはユーザーの自由にさせてくれって感じ。

**78（後日談）** · 04/04/16 12:24

ふらふらとblog巡りしてたら、ARTIFACTさんとこでたいむりぃな記事が。
http://artifact-jp.com/mt/archives/200404/svgcats2.html
タブレットPCとMicrosoft Office OneNote 2003……
こいつがズヴァリ！私が求めてたソリューションっぽい。

MSにお布施するか……。

**nobodyさん** · 04/04/16 14:09

Wiki等のCGIを、既存のHTMLの中に組み込むことは可能でしょうか？

例えばhogewiki.cgiというシンプルなスクリプトがあったとして、
<--#exec cgi="hogewiki.cgi"-->
とか
<--#include cgi="hogewiki.cgi"-->
みたいな方法で、ページのなかの特定部分をwiki化したいのです。

実際に試してみたのですが、うまくいきませんでした。
・・・なにか根本的に間違えているのでしょうか？

**nobodyさん** · 04/04/16 14:21

もしかしたらSVG CatsにHTTPのGETとPOSTの機能をつけるだけで
誰もが夢見た超RichなWikiが実現すると思われ。

**nobodyさん** · 04/04/16 14:23

>>92
考えられる原因がいっぱい過ぎて、それだけの情報じゃわからん。

まずは、その wiki 以外の単純なCGIでやってみて、そこから原因を探っていけば？
あ、でも、それすらうまくいかない場合は、ココじゃなくてCGIかSSIのスレへ行ってね。

他にも「くっつきBBS」みたいに、JavaScript を使う方法も考えられるかも。

**nobodyさん** · 04/04/16 14:59

インラインフレームにすると一番楽じゃないか？

<OBJECT DATA="http://hogehoge.com/hogewiki.cgi" TYPE="text/html"
WIDTH="" HEIGHT="" ALIGN="" Title="hogehoge">
</OBJECT>

でも、要求している内容と違ってる希ガス

92 · 04/04/16 15:37

>>94

おっしゃる通りなのですね、すみません（＾＾；）
cgiの仕組みもperlの仕組みもどれもこれも中途半端にしか理解していないので、
何をどうすればいいのかただただ混乱するばかりで。

もっと簡単に「既存のページ内にwikiみたいのを組み込む」ことができるかな、
と思ってたのですが、なんだか甘い考えだったようで・・・。

>>95

インラインフレームという仕組みを知りませんでした、恥ずかしながら。

調べてみて、とりあえず、これでやりたかったことは実現できると
分かりました。ありがとうございます。

**nobodyさん** · 04/04/17 18:31

最近のWikiはごちゃごちゃしていて難しい。
もっとシンプルで、見栄えのいい
CGIはないものだろうか？

**nobodyさん** · 04/04/17 19:36

yukiwiki or yukiwikiの旧バージョン

見栄えはcssの問題だから、書き換えたらいいし。

**nobodyさん** · 04/04/19 23:12

■SVGってどうなの？　http://pc5.2ch.net/test/read.cgi/hp/1004465594/l50

588 名前：Name_Not_Found ：04/04/18 21:55 ID:8bBRpTQD
SVGエディターの試作品（約16kb)です。要望や批判があれば下さい。

Ewiki　http://dhr.at.infoseek.co.jp/svgeditor.svg

注意点
AdobeSVGViewer ver.6の方がいいかもしれません。(Windows98のfirefoxとver.6などで動作確認)
右端のメニューが見えない方はWindowsならAltキーを押しながらマウスでずらしてみてください。

**nobodyさん** · 04/04/21 13:27

リッチ系Wikiと、シンプル系Wikiに分かれていきそうな情勢ですなぁ。

**nobodyさん** · 04/04/22 10:13

Wikiのリッチクライアント化のためには
鯖との通信プロトコルは極端にシンプルなほうがいいと思う。
そういう意味ではXML-RPCも複雑すぎる。Atomとかどうなんだろ。

深く考えずに書くけど tuple space over HTTP って成立するのかな？

**nobodyさん** · 04/04/22 13:54

>>101
君は深く考えればもっといい案が出せるのかい？そんなことはないだろう

**nobodyさん** · 04/04/22 14:20

ts.write ['page', 'SomePageName', 'Page Contents as String...']
↓
POST /page/SomePageName
(headers...)

Page Contents as String...
(end of stream)

ts.read ['page', 'SomePageName', nil]
↓
GET /READ/page/SomePageName/ HTTP/1.0 # 末尾がワイルドカードの場合は '/' で終わる

ts.take ['page', 'SomePageName', nil]
↓
GET /TAKE/page/SomePageName/ HTTP/1.0

take, read, writeはできそう。notifyは無理っぽい。
あとブロック→タイムアウトを制御する HTTP Header ってあったかな？

**http://www.tanteifile.com/tamashii/index3.html** · 04/04/23 01:18

#f - Wikiが流行らない理由 http://nnri.dip.jp/~yf/cgi-bin/yaswiki2.cgi?op=idaccess&id=367

**nobodyさん** · 04/04/23 12:40

ツールなんだから各自使いたいように使えばいいのに、
なんで定義しようとするのかそれが判らん。(^^;

普及させたいから？
オレは普及しなくても生き延びてくれればそれでいい……。

**nobodyさん** · 04/04/23 19:02

生き延びる為にやってるんだろ

**nobodyさん** · 04/04/24 03:42

わしは、「ちょっと便利なWiki」や「ちょっと目新しいWiki」にはもう秋田。
もはやWikiとは呼べないくらいの革新的なWikiを求む。

自分では思いつかないけど。

**nobodyさん** · 04/04/24 05:52

まだこういう無駄な改行で遊ぶバカいるんだな　┐(´д｀)┌

**nobodyさん** · 04/04/24 12:10

どのwikiを使おうか迷っているのですが、オススメのwiki教えてくれませんか？
一応候補としてはHikiとPukiWikiが上がってます。

**nobodyさん** · 04/04/24 13:28

どういう風に使おうとしているのか？候補としてHikiとPukiWikiが残った理由は？
その辺りがなけりゃ、あまり意味のあるお薦めはできそうにないな。
とりあえずYukiWikiでも使っとけ。

**nobodyさん** · 04/04/24 13:39

>>107
FLASHと融合したビジュアル重視のWikiはどうだろうか

**nobodyさん** · 04/04/25 01:36

>>111
見た目と処理とを完全分離できる点はいいな。

**nobodyさん** · 04/04/25 11:04

>>111
実装されてるものってどこかにある？

**nobodyさん** · 04/04/25 11:17

KNOPPIXのバリエーションとして、各種言語と、
それに対応したWikiを詰め合わせたパッケージがあったら面白いのになぁとオモタ。
データ用のパーティションを用意してやれば、サーバとして運用できるとなお嬉しい。

**nobodyさん** · 04/04/25 13:59

>>113
FlashWiki
http://www26.tok2.com/home/taiyaki/
うちでは見れなかったけど

**nobodyさん** · 04/04/25 14:24

■2004年4月23日 (金) - 『結城浩のWiki入門』ランキング

　http://www.hyuki.com/diary/dia0404.html#i23_14

**nobodyさん** · 04/04/25 14:53

>>115
やってみた。Reload速くてイイ。
Flashのメリットはビジュアルだけじゃなくてレスポンスの良さにもありそう

**nobodyさん** · 04/04/25 16:00

>>115
それ、ぜんぜんビジュアル重視じゃないような
使い方はよくわからんし、ページの関連も見えんし

**111** · 04/04/26 17:54

>>118
>>115は私じゃないんで･･･
これ、はじめから編集ウィンドウが開いてて、
書き込んで「Write」を押すと編集内容が記録されるみたい。

たしかにこれ自体はプレゼン的なもので実用じゃなさそうだけど
かえって想像が膨らんでいい

**nobodyさん** · 04/04/26 23:50

「声のかけら。」
Wiki風味掲示板、とでも言うのかな。
0.9.0出てました。
http://www.hyuki.com/kakera/about.html

**nobodyさん** · 04/04/27 15:15

初心者ですがwikiで作りたいサイトがあり、教えて欲しいことがあります。
それは、エントリ（ページ）が10000を越えるようなサイトを実用的に運用
できるかというものです。ページあたりは短いテキストで1000文字に満たな
いものが大半です。

また、このように大きくなる場合に、phpとかrubyを使ったプログラムのほ
うが有利なんでしょうか。

ちなみに、このデータベースは自己満足のためのもので、アクセス数は
数えるほどしかないと思います。

**nobodyさん** · 04/04/27 15:45

>>121
そりゃ、超有名なここを見れば可能であることが瞬間的に分かるだろう。
ttp://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8

**nobodyさん** · 04/04/27 16:44

ありがとうございます。

もちろん、wikipediaは知っていますが、一般人が個人で用意できる環境（レンタルサーバーか
自宅のＰＣサーバー）でそこまでできるんでしょうか？目指しているのは
これよりはるかに負荷は少ないですが。

**nobodyさん** · 04/04/27 17:32

>>123
それはクライアントが同時に何人ぶら下がるかによるので、wikiの問題ではない。

**nobodyさん** · 04/04/27 20:46

実装によってはページ数が増えるととたんに遅くなったり
するのもあるから気をつけたほうがいい。

**nobodyさん** · 04/04/27 21:06

自動リンクを制限するなど気をつければ大丈夫だと思うけど。

**nobodyさん** · 04/04/28 11:35

コメントありがとうございます。

>>124
それはクライアントが同時に何人ぶら下がるかによるので、wikiの問題ではない。

マイナーサイトなので、クライアントが同時に複数人ぶら下がることは考える
必要は有りません。

しかし、

>>125
さんの指摘されるところが問題になる可能性があると思うんです。

>>126
自動リンクを制限しないということを前提で考えたいものですから。

クライアントの同時接続はほとんどないので、回線的な問題は発生しないと
思いますが、データベースのマシンへの負荷が問題にならないか心配なんです。

「リンクをクリックしたら10秒、書き込みボタンを押したら１分、検索したら２分待ち」というのでは、使い物にならないと思うんです。

まあ、すぐに大きくなるものではないので、しこしこ作っているうちに、バージョンが上がったりマシンパワーが上がったりで使えるようになるかもしれませんが・・・

**nobodyさん** · 04/04/28 11:52

>>127
何はともあれ、Wikiだってperlやphpやrubyで作られてるので
不満があるのなら他の手段を考えるんだね

更新頻度が多くないんならstatic wikiだって選択肢の一つ

**nobodyさん** · 04/04/28 14:07

自動リンクという言葉を誤解していると思う。

自動リンクはBracketNameになっていない文章を
スキャンして、既にページ名が存在している言葉があれば
そのページへのリンクとして表示すると言う機能。

これを有効にすると、ページ数が増えるほど負荷が
増大する。

>>127 はこれが本当に必要？

**nobodyさん** · 04/04/28 17:15

ありがとうございます。

>>128
後で不満になるかどうかが分からないので、質問しました。

static wikiというのは初めて聞きました。良いかもしれません。
負荷も少なそうな名前(^^;ですし。

>>129
どうやら、誤解しているようです。

static wikiとも併せて勉強しなおしてきます。

**nobodyさん** · 04/04/28 21:00

HTMLを静的に生成できるwikiってないもんだな
変化の少ないページだけでも静的生成可能になれば負荷もストレスも減るんだが
需要がないってことか

**nobodyさん** · 04/04/29 00:22

>>131
FSWikiはHTMLをキャッシュできるようになったけど、
そゆことではない?

**nobodyさん** · 04/04/29 01:28

おまえらいつになったら検索サイトの使い方を覚えるんだと（ｒｙ

- ese-nikki（Perl）
-- 静的HTML生成機能

- VikiWiki（Ruby）
-- 複数のWikiPage文法に対応、静的HTML生成機能

- PassWiki（PHP）
-- ブックという管理単位、静的HTML生成機能

ttp://www9.ocn.ne.jp/~ymt/wiki/
ttp://www.naney.org/wiki/WikiEngine.html

**nobodyさん** · 04/04/29 01:49

検索サイトの使い方を覚えるといいことあんの？

2ch で適当に煽れば答える馬鹿がいるじゃん。

**nobodyさん** · 04/04/29 07:28

通常、その馬鹿が針に掛かるより早く答えにたどり着ける。
馬鹿未満だと無理かもしれないが。

**nobodyさん** · 04/04/29 07:44

釣りの楽しさを知らない若造がいますね。

**nobodyさん** · 04/04/29 09:37

>>131
最近のアクセス数を動的に出したり自動リンクしたりしてるWikiだと
キャッシュしにくいってのはあると思うよ。

**nobodyさん** · 04/04/29 22:20

つか、生成済みHTMLをWikiがキャッシュするってのと、
>>133がいうところの静的HTML生成ってのは同義?
教えてエロい人。
#「静的」HTML「生成」ってのは意味はわかるけど
#なんか違和感あるなあ

**nobodyさん** · 04/04/29 23:38

違うんじゃねーかな。

Wiki文法で書かれたページデータ→HTML　の結果をキャッシュしておいて、
ページの更新が無い限り、次のそのページ呼び出しの際にはキャッシュを
出すだけで変換処理をスキップ出来るってーのが「Wikiがキャッシュする」

Wikiがページを「保存・完全」したようなHTMLファイルをサーバ上に書出し、
それを直接開くことで以後はWikiの稼動無しにページが閲覧できるようになる
ってーのを「静的HTML生成」

と呼んでいるのではないかと推察。

**nobodyさん** · 04/04/29 23:59

なるほど。
.cgiでキャッシュのHTMLを閲覧するか、直接.htmlで閲覧できるか、
って感じの違いかな。
そこにいろんな要素は介在するかもしれんけど。

推察の上に推察を重ねてるので右斜め上の恐れもあるけど。

**nobodyさん** · 04/05/01 00:38

C++とJavaのサンプルコード貼り付けるのに便利なWikiEngine、プラグインってありますか？

"The Code Project"みたいなのが見やすいと思ってるんですが。
(http://www.codeproject.com/index.asp)

**nobodyさん** · 04/05/01 10:57

YukiWiki のバーベイタムを使うがよい

**nobodyさん** · 04/05/01 15:42

141です。
>>142さん、ありがとう

バーベイタム、pukiwikiにはないのかな?

あと、こんなのもありました。

・D言語のコードをPukiWikiでハイライト表示させる
ttp://moephp.org/?D%B8%C0%B8%EC%2FPukiWiki%2F%A5%CF%A5%A4%A5%E9%A5%A4%A5%C8#content_1_3

・TWiki : SourceHighlightPlugin
ttp://twiki.org/cgi-bin/view/Plugins/SourceHighlightPlugin

TWikiのハイライトプラグインがよさげなんだけど、
TWikiを設置する能力がない・・・

**nobodyさん** · 04/05/03 22:20

結局、Pukiwiki での見出し単位での編集ってどうなったん？
標準で搭載されるって話はどこ行ったんだ

**nobodyさん** · 04/05/04 09:27

>144
プラグイン使えばいいやん

**nobodyさん** · 04/05/04 11:07

Wiki板ができました！
http://pabbs.hp.infoseek.co.jp/

**从ﾟ。ﾟ）** · 04/05/04 12:18

**nobodyさん** · 04/05/04 13:25

>>145
それがオフィシャルのプラグインになるって話があったんだけど、
どうなってんだよ？って話さ
結局パッチ当てなきゃいけないっつーならやるさ

**nobodyさん** · 04/05/04 22:11

登録ユーザー管理ができるWikiってXoops＋B-Wikiしかないですか？
ゴテゴテXoopsは、できればパスしたいので・・・

**nobodyさん** · 04/05/05 11:16

素朴な疑問。
なぜwikiでユーザ管理がしたいのだろう。
だったら無理にwiki使わんでもと思う。
特定ユーザのみ利用可とさせるだけなら、webserver側でやっとけばいいような。

**nobodyさん** · 04/05/05 11:42

>150
俺は>149じゃないけど、
ユーザ管理は今後のWikiにとって必要なものになっていくと思うぞ。
現状のWikiは不特定多数が自由に編集出来るという特徴のせいで、
逆にコラボレーションツールとしての可能性を狭めてしまっていると思う。

俺はユーザ/グループ単位で全ページ、または
特定ページの編集・追加・削除の権限が設定出来たり、
（階層化をサポートしてるWikiなら、特定の階層以下に対して）
変更履歴がユーザ名などの情報と一緒に残るような、そういうWikiが欲しい。

**nobodyさん** · 04/05/05 11:50

>>151
>現状のWikiは不特定多数が自由に編集出来るという特徴のせいで、
>逆にコラボレーションツールとしての可能性を狭めてしまっていると思う。

ここ、詳しくお願いします

**151** · 04/05/05 12:03

>152
コラボレーションって色々な形態があるでしょ。
個人間、チーム間、企業間、1対多、多対多など、人数や所属などの面でも、
編集結果を不特定多数に対して公開するのか、
それとも限定された環境で閲覧可能にするのか、など。

>150が書いてるように、Webサーバ側でBASIC認証かけるなどするか、
通信自体をセキュアにしてしまえば、ある程度は解消出来るが、
柔軟性にも利便性にも欠ける。

ユーザ管理が出来ても、これらの要求を全てかなえることは出来ないだろうが、
現状のWikiよりは柔軟な管理が可能になる。

**nobodyさん** · 04/05/05 13:16

>>151/153
的確で、すばらしい　まさしくそれ。

こういった部分でも、いろいろなアイデアが盛り込まれて欲しい。
「1対多」に、ついてはPassWikiが実現している。
閲覧者から見たら最初っからすべてが触れない
「凍結」状態なのだけど、それはそれで良い機能だと思う。

Xoopsも、もっとシンプルだったら良かったのだ。
チーム管理が強いだけに惜しい。
Wikiクローンの作者さん達、この記事を見ててくれることを望む。

**nobodyさん** · 04/05/05 13:46

>151,153,154
で、誰がユーザー管理すると想定してる？
・ページを作成したユーザー
・最後にページ編集したユーザー
・Wikiオーナー
あたりは考えているんだけどねぇ。

**151** · 04/05/05 15:17

>155
Wikiクローン作者さん？

ユーザ管理権限：　　Wiki設置者（Admin）、Adminが管理権限を与えたユーザ
新規ページの作成：　ページ追加権限を与えられたユーザ
ページの編集：　　　　ページの作成者、Admin、Adminが他者ページの編集権限を与えたユーザ
（編集は削除含む）

ページを作成したユーザが共同編集者（編集を許可するユーザ）を指定出来るとなお良い。
あと、ユーザが多くなると管理の手間がばかにならんので、
グループ単位での管理も出来るようになってると非常にｲｲ。

また、Blogのようにページに下書き・公開といった段階を持たせられるとグッド。
（ゲストの閲覧権限を奪うといった方法でもいいけど、出来れば公開/非公開の別のスイッチがあった方がいい）

俺はこんな感じで設定出来れば、いいなと思う。

**nobodyさん** · 04/05/05 18:11

なんかユーザ管理と更新履歴を突き詰めていけば、cvsをバックグラウンドで動かしているwikiになるのかな。
もしくは機能や使い勝手を追求していけばノーツみたいなwiki（ってかノーツやんけ）。

これからwikiはどこにいくんだろう。楽しみだなあ。

**nobodyさん** · 04/05/05 21:03

結構同じような事考えてる人は多いのかな。

ユーザごとのコマンド実行権限とページごとのコマンド受付権限を与えて
両方の条件満たしたら反映するように必死でソース読んで改造試みてます。

正直Wikiらしい所はページの書式だけになりそう。

**nobodyさん** · 04/05/05 21:52

実際、Wikiの書式覚えるとHTMLでこつこつ書くの
とかってあほらしく感じちゃうんですよ。

**nobodyさん** · 04/05/05 22:25

実際、いったんHTML覚えるとWikiのばらばらな書式覚えるの
とかってあほらしく感じちゃうんですよ。

**nobodyさん** · 04/05/05 22:34

ユーザ管理ができるのはたしかにいいことだと思うんだけど，
Wiki独特の自由さやシンプルさが失われるのがやなんだよね．
その相反する要素をどうやって満せばいいんだろうか．

**nobodyさん** · 04/05/05 22:48

いやならWiki内部でそんなもの持つ必要はない
ウェブサーバや各種アプリケーションサーバのもつアクセス制限のための
インタフェースをWiki側が提供すれば済むことだ

**nobodyさん** · 04/05/05 22:51

PukiWikiしかさわったことないけど、特定の人だけが編集できるようにするのは
「ページの更新」ボタンの隣にでもユーザーIDとパスワードを入力できる場所を
置いておけば、不自由さをあんまり感じないで実現できるんじゃないかな

**nobodyさん** · 04/05/05 22:59

>161
すべてのWikiがそういった複雑な機能を持つようになる必要はないんだし、
シンプルに徹するWikiもあれば、複雑な機能を取り込んでいくWikiもあれば、
設定によって振る舞いを切り替えれるようなWikiがあったりとか、
そういう風に派生していけばいいんじゃないかな。

選択肢があるのは別に悪いことじゃないんだし、
Wikiとはこういうものだ、と固定観念を持ってしまって、
選択肢を減らすよりはよっぽどいいんじゃないかと思う。

**nobodyさん** · 04/05/06 00:04

っうか、海外物ではユーザー管理機能も普通にあるんじゃないか？
TWikiとかさ。

**nobodyさん** · 04/05/06 13:37

http://sheepman.parfait.ne.jp/wiki/Wiki%A4%C8%A5%E6%A1%BC%A5%B6%B4%C9%CD%FD

**nobodyさん** · 04/05/06 14:06

WYSIWYGエディターを既存のwikiに組み込んでる方っていらっしゃいますか？
blog系でも取り込み始めたサイトとかも、ちょこちょこみますが、wiki系ではまでみかけません。
wiki++など、最初からWYSIWYGエディターを組み込んだものの存在は知ってはいるのですが...
もっとも、組み込むならWYSIWYGエディター側をそのwikiの使用に合わせてかなりカスタマイズしなければならないとはおもいますが。
...

FCKeditor
http://www.fredck.com/fckeditor/

Kupu
http://kupu.oscom.org/

**nobodyさん** · 04/05/06 15:22

ぶっちゃけWYSIWYGエディタなんて必要？

**nobodyさん** · 04/05/06 17:03

「鶴の恩がえし」って話は知ってるよね。

記事を書いてるけども、今は完成するまで覗かないで待ってほしいな
ちょっとだけでいいから

という書き手の要望が、私的に望む「管理機能」なのです。

♪ My WikiWay

**nobodyさん** · 04/05/06 17:26

>>168
Wikiの記述に慣れてる方はいいんですけれど、そうでない方にも使ってもらいたくて。
社内の情報交換用に使ってるんですが、大体の方は記述法覚えるのが面倒らしくて、
1行コメントや、書いてもベタで記述しちゃうんですよね。
すでにWikiに触れてる方でも、自分が慣れてないWikiだと、わざわざ記述覚えようとはしないんです。
(わたしもYukiWikiからPukiWikiに乗り換えた時、非常に歯がゆい思いをしました)
無論、気持ちもわからなくはないんで、そういうとっかかりとしてWYSIWYGエディタはアリだとおもいます。

**nobodyさん** · 04/05/06 18:34

pukiwikiですが、編集制限で
「テストページ」というページ名以外を制限したいので
'/[^テストページ]/' => 'admin'
としましたが、テストページを含めばいいみたいで、テストページアホアホ
というようなページも作られてしまいます。。。
正規表現で「テストページ」だと
^(テストページ)$
なんですが、
その否定はどうすりゃいいのでしょうか・・・

**171** · 04/05/06 18:37

すいません。できてました・・
[]内は、それ”だけ”しかマッチしないようになってるんでしたか・・

**nobodyさん** · 04/05/06 19:27

初心者の人は、やたらと物理マークアップを使いたがるような気がする。
特に改行。

**nobodyさん** · 04/05/06 19:43

物理意マークアップって？

**nobodyさん** · 04/05/06 19:49

<br>使ったら素人扱いかよ・・・
やれやれ
<p>のほうがよっぽどダサいとおもうんだが

**nobodyさん** · 04/05/06 19:53

Pukiwikiで、URLオートリンクで
URLだけの行を改行する場合って
~でOKですよね？
#br &br;はオートリンクに含まれてしまうのですが

**nobodyさん** · 04/05/06 20:03

いや、たまにbr入れるくらいならともかく、
行末全部br入れてると、なんだかなーって思うわけよ

**nobodyさん** · 04/05/06 20:05

>>169
Nucleus に下書き機能が。

>>176
br要素使われると携帯やPDA、全画面表示でないときなど
微妙な改行具合がうざい。
pならうまく処理してくれる。気に喰わないならスタイルシートなり何なり使えば？

**nobodyさん** · 04/05/06 20:08

>>170
Help ページを画面右側にインラインフレームかなんかで表示すりゃ十分じゃね？

**nobodyさん** · 04/05/06 20:13

>>170
うーんなるほど、、、よくわかりました。確かにそうだ。

**nobodyさん** · 04/05/06 22:11

私はちょっと大きな資料を作るときにしこしこwikiの文法で書いてるのが嫌になることがある。
ここ太字とか、ここソースコードとか、ワープロみたいにドラッグしてボタン一つでできるのと比べてしまう。
WYSIWYGならぜひ使ってみたい。