トップ 差分 一覧 Farm ソース 検索 ヘルプ RSS ログイン

雑談掲示板

ページの作成や編集にはユーザ登録が必要です。

FSWiki雑談掲示板

サポート掲示板は質問などの書き込みが主になっているようなので、FSWikiを使っての感想など、些細なおしゃべり・雑談の場合はこちらをお使いください。話が盛り上がってきたら適宜、サポート掲示板などに話題を移行させるような感じでの使い方もできるかもしれません。

  • 過去ログはページ下部の選択肢から参照できます。
  • 件数が増えてきたら古いものから順に過去ログに移動します。
  • 雑談掲示板一覧もどうぞ。
  • 設置に関するトラブルや要望などはサポート掲示板のほうにお願いします。
  • バグ報告に関してはバグトラックのほうにお願いします。
  • FSWikiとは無関係と思われる投稿、コメントに関しては削除させていただきますのでご了承ください。
お名前
件名
本文

将来的な希望として - H.Holon (2005年12月01日 07時14分10秒)

現在、URLが wiki.cgi?page=ページ名 のような形式になっていますが、wiki.cgi/page/ページ名 といったスラッシュをセパレータとした形式への対応を希望です。自分で修正しようとしたのですが結構埋め込みな query設定などがあって、設定で switchするような作りにするには大事そうでしたので、できれば将来的な実装希望として、お願いしておきます。

理由としては、CMS的な使い方をしたときに search engineがひっかけてくれないことが一番だったりします。

  • Yahooの場合は、descriptionを埋め込めるならインデックスされるみたいです。またLite版を使ってた時期には、p=(ページ名)がGoogleでもインデックスされたように思います。ちなみに、Googleの場合、ページ名が日本語(URLエンコード)より半角英数字の方がインデックスされやすいかもしれないという経験則を感じます。CGI.pmモジュールを使っているので、変数=値の式は変えられそうにないかも。mod_rewriteで対応しようとした時期もありましたが断念しました。 - A_M (2005年12月01日 15時27分38秒)
  • 思いつきで検証してませんし、変則的ですが、farm処理の前に$path_infoを元に$path_info自身と$cgi->param("page",$hoge)としてパラメータ値も書き換えてだませばmod_rewrite風の書き換えはできると思います。 - typer (2005年12月01日 22時28分45秒)
  • しかし、H.Holonさんが言っておられるのは、ページ生成時のURL生成コードが各所にあって大変そうだと言う事だと思います - typer (2005年12月01日 22時33分59秒)
  • search engineがひっかけてくれませんか?うちは、Yahooやgoogleから来る人が多いですけど。 - Kinsan (2005年12月17日 22時45分05秒)
  • クロールされますが、静的ページに比べてポイントは低くカウントされます。さらに、パラメータ部分が長いほど低くカウントされるようです。この辺はサーチエンジンによって違いますし、日進月歩変化してますので、ハッキリとしたことは言えません。 - あき (2005年12月18日 01時18分20秒)
  • 最近では、RSSフィードが、表示のための条件みたいな話も聞きますね。 - A_M (2005年12月18日 08時06分04秒)
  • BBS-サポート掲示板/470でも軽く触れたURL生成関数を必ず利用するように修正すれば、以降のURL生成コードは簡単に修正できそうですね。現在、標準で同梱されるプラグインについて修正を試みていますが、typer氏の仰るように膨大です。まだまだ時間がかかりそう。 - A_M (2006年01月04日 18時39分39秒)
  • URL生成もですがBugTrack-plugin/223への対応を考えるとリンク生成についても何かメソッドを作った方が良いかも知れませんね。ちなみに竹添さんは何か案をお持ちでしょうか? - typer (2006年01月04日 23時18分14秒)
  • wiki.cgi/page/ページ名のような形式はFarmと被ってしまうのでNGだと思います。もちろん/pageを予約にするなどすればOKなのですが、そもそもPATH_INFOを使った場合と、パラメータを使った場合とでは相対パスでのリンク先が変わってしまうので単純に切り替えできるようにするだけではダメかなと思ってます。せめて標準プラグインではURL生成関数を使用するようにしてmod_rewriteを使う場合など対応しやすいようにしておきたいところです。将来的にURLのカスタマイズを考える際の布石にもなりますし。 - たけぞう (2006年01月05日 00時58分27秒)
  • あと、BugTrack-plugin/223についてはあまり大袈裟な実装はせず、add_menuのオプションで指定するような方法を考えてます。今はメニュー項目などアクションの呼び出しは外部リンクと同じ扱いで、フォームなどから呼び出す際はPOSTメソッドで呼び出してますし、リンク生成関数を作っても使えないケースが多いんじゃないかなと思います。 - たけぞう (2006年01月05日 01時08分19秒)
  • 3.5.10においてURL生成関数を使えそうな場所を挙げてみました。確認が十分とは言えませんが、参考程度にアップロードいたします。 thinkingURL_euc.txt(1240) - A_M (2006年01月06日 07時32分53秒)
お名前: コメント:

3.5.10・・・ - kumaneko (2005年11月30日 22時36分34秒)

BugTrack-plugin/146のパッチあてでつまづいていて、いっそのことなら3.5.10のリリースを待つことにしていました。11月中にリリースとのことだったのですが、いつごろになりそうなのでしょうか?

首を長くして待っています。

  • BugTrack-plugin/146は3.1.10(まだ開発版との位置づけかもしれませんが)でコミットされているみたいですよ。SourceForgeでソースコードリポジトリのところからDL出来ました。ちなみに、ラジオボタンで変更できるようにしてくださっています。 - A_M (2005年12月01日 15時23分13秒)
  • ありがとうございます。先ほどダウンロードして来ました。早速使ってみたいと思います。 - kumaneko (2005年12月04日 11時34分41秒)
お名前: コメント:

FSWiki のテーブルで colspan と rowspan は使用できませんか - 名無しさん (2005年11月11日 14時20分54秒)

FSWiki のテーブルで colspan と rowspan は使用できませんか?
実装されていないようなら次回アップデートで実装して欲しいなと。
需要はないのでしょうか。
  • BugTrack-plugin/162を導入すれば使用できますよ。オプション一覧のところにある「COLS」と「ROWS」です。 - 名無しさん (2005年11月11日 14時33分27秒)
    • どうもありがとうございます。解決しました。既にプラグインがあったのですね。検索しても出てこなかったので。これは標準同梱して欲しいです。 - 名無しさん (2005年11月14日 14時37分46秒)
お名前: コメント:

管理画面を統一したデザインに… - A_M (2005年11月09日 06時26分06秒)

CMS向け拡張パックなどの動きもあるFSWikiですが、ログイン後の画面において、見出しのデザインやカラーリングなどが、選択したテーマに合わせて変化するため、大きくデザインが変わってしまいます。

このため、設置者ほどの知識はなくても、管理を担当するようなユーザを考えたとき、管理画面のデザインが統一されていれば、操作方法などの伝達も単純化され、多くの方に利用していただけるものに発展しそうな気がします。

この提案の発端は、ノリで作ってしまった「ブログライクテンプレート」によって、管理画面のデザイン上のばらつきが懸念される事にあります。

デザイン面においても自由度の高いシステムですので、このような問題も考えるべきなのかなと思い、投稿させていただきました。

  • とても重要な指摘をされているような気がするのですが、上手く伝わっていないかもしれません。具体的に「どういったことをした方がいい」と仰っているのでしょうか? 私は以前にtDiaryのテーマを取っ替え引っ替え試していて、フォームを見失いそうになったことがあります。あれ、かなりデザインが変わって、色や配置がとんでもないことになることがあるんですよね。例えば文字が全く見えなくなったり、ボタンが押せなくなったり…。単にこれを解決するだけでしたら、「管理画面に限ってはテーマを特定のもので固定する」という解決策があると思われますがいかがでしょう? 或いは、「そうしませんか?」といった提案でしょうか? - あき (2005年11月10日 02時15分52秒)
  • コメント有難うございます。「2通りの方法があるのかな」と思いました。1つは、あき氏の仰るとおりで「管理画面に限ってはテーマを固定」という方法。もう一つは、「Form部分に限っては、スタイルについてルールを設ける」という方法です。色々と思案中なのですが、編集画面で「プレビュー機能」がある点において、編集画面用の見栄えと、生成される確認用の見栄えとが混同してしまうように思うのです。こうした点についても、皆さんと一緒に打開策を模索したいというのものです。 - A_M (2005年11月10日 06時16分43秒)
  • 前後しますが、問題提起としましては、「統一しませんか?」ということです。雑談コーナーということで、脈絡の無さをお許しください。 - A_M (2005年11月10日 06時31分37秒)
  • 個々に作成されるテーマに「Form部分に限っては…」という条件を設けるのは多くの方への負担になるでしょうから、「管理画面に限ってはテーマを固定」とかの方が良いと思います。変更したスタイルを確認するには、「プレビューボタン」を設けてクリックすると別ウィンドウで事前確認とかできると良い気がします。事前確認できる機能っていうのは是非欲しいです。管理者がテーマを取っ替え引っ替え品定めしてる最中にユーザが訪れてきたら、ビックリでしょうから…。 - あき (2005年11月10日 21時38分28秒)
  • 別ウィンドウが、最も労力がかからなくて良いかもしれないですね。余談ですが、システム用の画面で言うと、大手のインターネットサイトが提供するブログなどは、管理画面が統一デザインとの事です。ヘルプドキュメントを作成しやすいからなのかもしれませんね。 - A_M (2005年11月10日 21時52分21秒)
  • とりあえず、思いついたのが次の2箇所を修正するパッチです。 - A_M (2005年11月24日 16時51分04秒)

管理画面では、admin というテンプレートとテーマがあれば、パラメータを修正して表示を変えてしまうというもの。

plugin/admin/Login.pm (62):

my $site_tmpl = $wiki->config('tmpl_dir')."/site/admin/admin.tmpl";
my $css = $wiki->config('theme_uri')."/admin/admin.css";
my $css_file = $wiki->config('theme_dir')."/admin/admin.css";
$wiki->config('css', $css) if ( -f $css_file );
$wiki->config('site_tmpl', $site_tmpl) if ( -f $site_tmpl );
my $buf = "<div class=\"admin\">\n<h2>ログイン中</h2>\n";

lib/Wiki.pm (537):

my $site_tmpl = $self->config('tmpl_dir')."/site/admin/admin.tmpl";
my $css = $self->config('theme_uri')."/admin/admin.css";
my $css_file = $self->config('theme_dir')."/admin/admin.css";
$self->config('css', $css) if ( -f $css_file );
$self->config('site_tmpl', $site_tmpl) if ( -f $site_tmpl );
	return "<div class=\"admin\">".$obj->do_action($self).
	       "<div class=\"comment\"><a href=\"".$self->config('script_name')."?action=LOGIN\">メニューに戻る</a></div></div>";
  • kitta氏の投稿したテーマ(051124_W_Lock.zip)をadminに改名して試用しましたが、横幅のブレもなく初心者でも混乱のない管理画面になりそうです。 - A_M (2005年11月24日 17時01分34秒)
  • ログイン公式Webサイト WebLOGiN 新刊案内 - xingyun (2005年12月03日 16時47分00秒)
お名前: コメント:

attachプラグインで大きなサイズのファイルが添付できない - 名無しさん (2005年10月24日 19時16分54秒)

バグとは言えないと思いますので、ここへ投稿します。サーバーのメモリ搭載容量が十分でない場合などに、attachプラグインで大きなサイズのファイルが添付できない場合があります。その場合、AttachHander.pmの50行目あたりを、

my $hundle   = $cgi->upload("file");
my $filecont;
while(<$hundle>){ $filecont = $filecont.$_; }

my $uploadfile = $wiki->config('attach_dir')."/".&Util::url_encode($pagename).".".&Util::url_encode($filename);

open(DATA,">$uploadfile") or die $!;
binmode(DATA);
print DATA $filecont;
close(DATA);

以下のように訂正することで、動作させることができます。

my $hundle   = $cgi->upload("file");
#my $filecont;
#while(<$hundle>){ $filecont = $filecont.$_; }

my $uploadfile = $wiki->config('attach_dir')."/".&Util::url_encode($pagename).".".&Util::url_encode($filename);

open(DATA,">$uploadfile") or die $!;
binmode(DATA);
while(<$hundle>){
    print DATA $_;
}
close(DATA);

以上。

  • 容量云々以前に、添付ファイルの内容をすべてメモリに取り込んでしまう従来の実装よりも改善案の方がいいように思えますね。 - gyo (2005年10月25日 10時26分26秒)
  • 上記改造案でも、改行コードが存在しなければ同じ現象が発生しそうです。while()文で1行毎に読み込むのではなく、任意の指定サイズ毎に区切って読み込む必要がありますね。 - あき (2005年10月25日 15時21分41秒)
  • readですね。青ラクダ本から:while(read $hundle,$_,16384){print DATA $_} - typer (2005年10月25日 20時39分38秒)
  • 今時のバッファサイズは幾らくらいが良いのかな? - typer (2005年10月25日 20時46分54秒)
  • 「今時」で言うなら、今回のようなリードをしながらのライトくらいでしたら、先読みやバッファリング出力が有効に働きますので、極端に大きすぎたり小さすぎたりしなければパフォーマンス的には殆ど変わらないはずですよ。上記のサイズであれば問題無いと思います。 - あき (2005年10月25日 21時39分01秒)
  • 修正しておきます。 - たけぞう (2005年10月26日 00時08分00秒)
お名前: コメント:

携帯電話での閲覧時に固定のフッタ - A_M (2005年10月20日 19時43分25秒)

4.0 の企画が上がっているので、雑談程度かと思いますが、tmpl/(template_name)/(template_name)_handyphone.tmpl に次のような1行を加え、

<!--TMPL_VAR NAME="COMMENT"-->

wiki.cgi に、次のリストのように加えると、携帯電話で閲覧時にもHandyFooter という特別ページをフッタとして固定表示できますね。

227. if ($is_handyphone) {
228.   # 携帯電話用処理
229.   my $handy_footer = "HandyFooter";
230.   if($wiki->page_exists($handy_footer)){
231.     if($wiki->can_show($handy_footer)){
232.       $template->param(COMMENT => $wiki->process_wiki($wiki->get_page($handy_footer)));
233.     }
234.   }
235.   $output = $template->output;
236.   &Jcode::convert(\$output,"sjis");

試してみると、編集モードでも表示されるので、詰めが甘いですが…。

4.0まで待ちきれない人向けの小話です。

  • 編集モードの時は「EDIT_MODE」がセットされているので、<!--TMPL_UNLESS NAME="EDIT_MODE"-->で対処出来ると思います。 - typer (2005年10月20日 23時57分26秒)
  • あ、ケイタイ時はセットされてなかった(^^; - typer (2005年10月20日 23時59分27秒)
  • なるほど。 ということは、"EDIT_MODE" をセットしちゃえば、出来そうかも知れませんね。 - A_M (2005年10月21日 03時01分04秒)
  • 上記の232行を if($action eq ""){ } で囲うと、編集時(?)に非表示になりました。 - A_M (2005年10月21日 06時22分23秒)
お名前: コメント:

bugtrackプラグインでBugList.pmで同じ内容の行は必要? - sige (2005年10月17日 20時41分30秒)

初心者なのでどこで問い合わせたらいいのかわかりませんでしたので雑談に書かせてもらいました。bugtrackプラグインでBugList.pmの93行目と94行目が同じ内容ですが、94行目は必要でしょうか?

    • 92行目 # サマリを作成
    • 93行目 my $bug_teian = 0;
    • 94行目 my $bug_teian = 0;
  • 要らないと思います。 - あき (2005年10月17日 22時29分56秒)
  • ご報告ありがとうございます。修正しておきました。 - たけぞう (2005年10月18日 00時45分18秒)
お名前: コメント:

Ajax の導入について - Mo (2005年10月15日 20時55分23秒)

最近Ajaxに興味があります。サーバーへ負荷を減らすこと出来るし、動的なページ、editor機能などさまざま事できるようです。

簡単にperlで作るpackageはCGI::Ajaxです。JavaScriptをあまり知らなくても作ってくれるのです。

fswikiにAjaxを導入すれば、面白いかもしれません。

CGI::Ajax is an object-oriented module that provides a unique mechanism for using perl code asynchronously from javascript-enhanced web pages. You would commonly use CGI::Ajax in AJAX/DHTML-based web applications. CGI::Ajax unburdens the user from having to write javascript, except for associating an exported method with a document-defined event (such as onClick, onKeyUp, etc). Only in the more advanced implementations of an exported perl method would a user need to write any javascript.

  • ネタとしては面白いですね。表示画面でそのままWYSIWYGで編集が出来るとか、ログインしていれば表示や編集権限をその場で変更できるとか。でも3.5系ではそこまでインターフェースが整理されていないから難しいかな。プラグインで出来るくらいの小ネタとしては今話題にあがっているattach関係とか出来ないだろうか。 - typer (2005年10月16日 22時13分41秒)
お名前: コメント:

アクセシビリティについて - A_M (2005年10月15日 19時43分46秒)

「アクセシビリティ ― 情報のバリアフリー化」はテーマとしては新しく、スクリーンリーダーによるホームページの読み上げなども実用化されています。FSWikiは、きれいなマークアップ構造を出力する上、完全にモジュール化されているので、十分対応できるテーマではないかなと感じています。

現在、個人的に「こんなこと出来ないだろうか」と考えているのは、次の3つです。

  1. 各画像の alt 属性(代替テキスト) 自動付加 ― 添付画像のファイル名をそのまま活用。添付画像ファイルは挿絵の機能と感じています(背景などの装飾用画像はスタイルシートで制御すればよいので)。
  2. アンカ−の title 属性追加 ― Wiki内の別ページ名を自動付加 ― 先走って作ったBugTrack-plugin/229ですが、説明も不十分ですし、他のプラグインにまで影響する為、現時点では却下になってもおかしくないものですけど。
  3. メインメニューの accesskey 属性の追加 ― 数字キーでダイレクトにジャンプできれば携帯電話での閲覧時に、FrontPage や、一覧、検索といった 各ページに戻りやすくなると思います。

参考)http://www-6.ibm.com/jp/accessibility/

  • 冒頭の「テーマとしては新しく」は、「注目を浴び始めている」と置き換えたほうが良いかもしれませんね。 - A_M (2005年10月15日 19時48分24秒)
  • 代替テキストはref_imageプラグインの第3引数に指定して、第3引数がない場合はファイル名を自動付加するようにした方が現実的じゃないでしょうか?画像の代替テキストは基本的に「意味が通じる」必要があるはずです。意味のあるファイル名ならば問題ないですが...。 - hoiho (2005年10月15日 23時44分36秒)
  • そうですよね。スタイルシート無しでも まともに読めるWEBドキュメントの作成者が任意に指定出来るほうが良いですね。プラグインとしてはHoihoさんの仰るような切り分けがあれば画像は簡単に対応できそうですね。 - A_M (2005年10月16日 01時15分24秒)
  • 富士通さんのアクセシビリティ関連ページを見ると、日付表記にスラッシュ(/)を使うと、音声ブラウザで数学の分数の読みになるとのこと。HTML出力される日付表記は「年月日」の日本語の読みが要求されてたりします。 - A_M (2005年10月26日 23時15分00秒)
  • 出典を忘れてしまいましたが、日付についてはW3Cが2005-Nov-04みたいなハイフンを使った表記を推奨していたように記憶しています。日本語では「年月日」にしておいた方が安全なんでしょうね。 - hoiho (2005年11月04日 15時02分31秒)
  • TABLEタグについてですが、CAPTIONを付けることも、アクセシビリティには要求されるようです。表に記載されるデータはどのような物か明確に表現するようですね。ちなみにborder=0の場合、レイアウト用とみなすことも書かれていました。 - A_M (2005年11月08日 12時54分04秒)
  • その他の内容ですが、アクセシビリティに関連すると思うのでこちらに追記させていただきますが、Wikiメニューの「一覧」をBugTrack-plugin/191で提案される方法で「新着」や「最終更新」とした方が、何の一覧かが分かって良い気がします。また、同プラグインを採用の時は、やはり「索引」等の文字の方が良いのかなとも感じました。 - A_M (2005年12月09日 18時48分12秒)
お名前: コメント:

編集中の「添付」の手続き - まー (2005年10月13日 01時26分06秒)

前から気になっていたんですけど、ページにファイルを添付する際、同時にテキストも編集したいとしても、

「編集」で編集画面に入る→
ファイルを添付する→いったん閲覧モードに戻される
→編集ボタンをもういちど押す→テキストを編集して保存

という回りくどい手続きになりますよね。

「ファイルを選択(Browse...)」のところにファイルの参照が入っていれば、テキストのところの「保存」「プレビュー」のボタンは、同時に「添付」もしてくれる動作の方が、テキストの編集とファイルの添付が一回で行えて便利な気がしますが、どうでしょうか。

  • 確かにそのほうが便利ではありますが、新規ページを作成する場合には、作成途中でやめてしまった場合に添付ファイルだけ残ってしまうという問題も出てしまいますね。 - KG (2005年10月13日 02時26分04秒)
  • 添付ファイルのフォームは、記事が既に存在していることを前提に出現する編集時専用のようですので、添付後は編集画面に戻されてもいいような気はしますね。 - A_M (2005年10月13日 06時50分21秒)
  • 追記ですが、プラグインでファイルの添付を一般の閲覧者から受け付けるページの場合、編集画面に移る必要がないので、切り分けの処理が要るのかもしれないですね。 - A_M (2005年10月13日 06時59分28秒)
  • そうですね。確かに添付操作後の画面が編集画面だと、連続で添付操作ができたりするので便利ですね。 - あき (2005年10月13日 07時07分56秒)
  • wiki慣れしてる人はなんとも思わないかもしれないんですが、そうじゃない人は、メールアプリっぽい操作を想像しちゃうように思います>添付 文章書いて、ファイルつけて、送信。のような。 - まー (2005年10月14日 07時16分34秒)
  • 編集画面の添付フォームはeditformプラグインとして実装しているのですが、editformプラグインはプラガブルな実装を可能とするためにそれぞれ別のフォームを出力する仕様になっています。なので今の仕組みでは編集フォームやeditformプラグイン間で連携することはできませんし、改善も難しいと思います。 - たけぞう (2005年10月15日 23時25分29秒)
  • フレーム内やポップアップウインドウ内て添付動作をすればテキスト編集エリアが出たまま操作できるわけですが、やはりフレームやポップアップは美学に反するっていう感じなんでしょうかね…。 - まー (2005年10月16日 01時13分06秒)
お名前: コメント:

[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ]

最終更新時間:2014年08月28日 09時33分14秒