2: 2009-04-04 (土) 23:18:08 taked2 |
現: 2009-07-27 (月) 07:52:14 taked2 |
| | | |
| ホームページはHTML(またはXHTML)と呼ばれるマークアップ言語によって記述されます(ホームページビルダーのようなWYSIWYGエディタを使っても、最終的にはHTML構文のテキストになります)。しかしHTMLはかなりの数の構文やオプションを装備しているため、一般の人には記述が難しいという難点があります。またHTML自体も数度のバージョンアップによって規格が変更されている上、ブラウザの種類によってはその再現が微妙に異なるといった「方言」の問題があります。それに基本的な問題として「タグが入れ子で閉じていなければいけない」という制約があり、複雑な構造のテキストになってくると、それを手動では保証する手段がありません。~ | | ホームページはHTML(またはXHTML)と呼ばれるマークアップ言語によって記述されます(ホームページビルダーのようなWYSIWYGエディタを使っても、最終的にはHTML構文のテキストになります)。しかしHTMLはかなりの数の構文やオプションを装備しているため、一般の人には記述が難しいという難点があります。またHTML自体も数度のバージョンアップによって規格が変更されている上、ブラウザの種類によってはその再現が微妙に異なるといった「方言」の問題があります。それに基本的な問題として「タグが入れ子で閉じていなければいけない」という制約があり、複雑な構造のテキストになってくると、それを手動では保証する手段がありません。~ |
- | Wikiでは「Wiki書法」と呼ばれる構文によってページを記述し、それをWikiエンジンが自動的にHTML構文に変換するという仕組みになっています。Wiki書法はHTMLにくらべると覚えておかなければならない書式が少ないため(10個ぐらいのWiki書式を覚えるだけで基本的な使い方はできます)、習得も容易です。また多くの書式は入れ子になる必要がないため、破綻が起こりにくくなっています。しかしその反面、HTMLよりは細かなページ表現ができないため、特にレイアウトの面で制約があります。これはWiki自体のコンセプトが「表現よりも内容を重視する」ためで、ある意味Wikiを使う上での限界といえるでしょう。 | + | Wikiでは「Wiki書式」と呼ばれる構文によってページを記述し、それをWikiエンジンが自動的にHTML構文に変換するという仕組みになっています。Wiki書式はHTMLにくらべると覚えておかなければならない書式が少ないため(10個ぐらいのWiki書式を覚えるだけで基本的な使い方はできます)、習得も容易です。また多くの書式は入れ子になる必要がないため、破綻が起こりにくくなっています。しかしその反面、HTMLよりは細かなページ表現ができないため、特にレイアウトの面で制約があります。これはWiki自体のコンセプトが「表現よりも内容を重視する」ためで、ある意味Wikiを使う上での限界といえるでしょう。 |
| | | |
| *** 論理的な構造のページが作成できる [#c57b4009] | | *** 論理的な構造のページが作成できる [#c57b4009] |
| HTMLでは文書の構造を規定していません。そのため、論文のようなタイトル、見出し、本文、注釈といった論理的な構造のはっきりした文書を書くには、書く人間が頭の中ですべてを把握しなければなりません。~ | | HTMLでは文書の構造を規定していません。そのため、論文のようなタイトル、見出し、本文、注釈といった論理的な構造のはっきりした文書を書くには、書く人間が頭の中ですべてを把握しなければなりません。~ |
| Wikiでは「見出し」を意識し、見出しのレベルを上げたり下げたりすることで、自然と論理的な構造のページを書くことができます。 | | Wikiでは「見出し」を意識し、見出しのレベルを上げたり下げたりすることで、自然と論理的な構造のページを書くことができます。 |
- | ワープロの機能でアウトラインプロセッサと呼ばれるものがありますが、例えばレベル2の見出しを章、レベル3の見出しを節というように意識することで、長文でも内容の追加、変更が把握しやすくなります。~ | + | ワープロの機能でアウトラインプロセッサと呼ばれるものがありますが、例えばレベル2の見出しを章、レベル3の見出しを節というように意識することで、長文でも内容が把握しやすくなります。~ |
| これは別に人間向けだけのメリットにとどまりません。多くのサーチエンジンではボットと呼ばれるプログラムが自動的にページの中身をサーチするわけですが、この際に論理的な構造のページの方が好まれる(?)ようです。 | | これは別に人間向けだけのメリットにとどまりません。多くのサーチエンジンではボットと呼ばれるプログラムが自動的にページの中身をサーチするわけですが、この際に論理的な構造のページの方が好まれる(?)ようです。 |
| | | |
| Wikiでの記法に慣れてくると、基本の機能が限られているのでもう少し機能を拡張したいという要望もでてきますが、PukiWikiではプラグインの追加により機能拡張をサポートしています。「カレンダー」「メモ」「投票」といった有用なプラグインは標準パッケージに同梱されていますし、有志のユーザーさんが配布している場合も(中には「HTMLの構文がそのまま書ける」といった過激なプラグインも)あります。もちろん腕に自信があれば自作することもできます。~ | | Wikiでの記法に慣れてくると、基本の機能が限られているのでもう少し機能を拡張したいという要望もでてきますが、PukiWikiではプラグインの追加により機能拡張をサポートしています。「カレンダー」「メモ」「投票」といった有用なプラグインは標準パッケージに同梱されていますし、有志のユーザーさんが配布している場合も(中には「HTMLの構文がそのまま書ける」といった過激なプラグインも)あります。もちろん腕に自信があれば自作することもできます。~ |
| ただし、xpWikiではPukiWikiのプラグインがそのまま動くことは保証されません。プラグイン変換ツールがありますので、変換しただけで動くケースもありますが、基本的に動作確認は自己責任となるでしょう。((xpWikiでのプラグインの動作状況については[[xpWiki/変換プラグイン動作状況一覧:http://nonnbei.dee.cc/modules/xpwiki/2695.html]]を参照。))~ | | ただし、xpWikiではPukiWikiのプラグインがそのまま動くことは保証されません。プラグイン変換ツールがありますので、変換しただけで動くケースもありますが、基本的に動作確認は自己責任となるでしょう。((xpWikiでのプラグインの動作状況については[[xpWiki/変換プラグイン動作状況一覧:http://nonnbei.dee.cc/modules/xpwiki/2695.html]]を参照。))~ |
- | なお、xpWikiniには独自のプラグインもパッケージに同梱されています。 | + | なお、xpWikiには独自のプラグインもパッケージに同梱されています。 |
| | | |
| *** スキンの変更によりデザインを変えられる [#j0a6afbc] | | *** スキンの変更によりデザインを変えられる [#j0a6afbc] |
| PukiWikiやMediaWikiなど通常のWikiクローンは、Webサーバ上のすぐ上のアプリケーションとして動作しています。そのため同じサイト上でWiki以外の機能、例えばブログなどを提供しようとすると別のパッケージを入れる必要がありました。しかし、そうなるとデザインやユーザーインターフェイスの統一は難しくなってきますし、バックアップなどの管理の手間も複雑になります。~ | | PukiWikiやMediaWikiなど通常のWikiクローンは、Webサーバ上のすぐ上のアプリケーションとして動作しています。そのため同じサイト上でWiki以外の機能、例えばブログなどを提供しようとすると別のパッケージを入れる必要がありました。しかし、そうなるとデザインやユーザーインターフェイスの統一は難しくなってきますし、バックアップなどの管理の手間も複雑になります。~ |
| xpWikiはXOOPSモジュールであるので、ブログや掲示板といった多彩な機能をXOOPS下で統一的に管理、提供することができます。これはセキュリティを守る上でも重要な意味を持っています。インターネット上に公開しているサイトとなると、最近ではアタックやスパムの被害が多く、その対応までWikiエンジンに組み込もうとするとかなりの手間ですし現実的ではありません。XOOPSであればセキュリティ防御に特化したモジュールと組み合わせることができるので、Wikiエンジンの肥大化(ひいては脆弱性の増大)を防ぎ、Wiki本来の機能強化に集中することができます。~ | | xpWikiはXOOPSモジュールであるので、ブログや掲示板といった多彩な機能をXOOPS下で統一的に管理、提供することができます。これはセキュリティを守る上でも重要な意味を持っています。インターネット上に公開しているサイトとなると、最近ではアタックやスパムの被害が多く、その対応までWikiエンジンに組み込もうとするとかなりの手間ですし現実的ではありません。XOOPSであればセキュリティ防御に特化したモジュールと組み合わせることができるので、Wikiエンジンの肥大化(ひいては脆弱性の増大)を防ぎ、Wiki本来の機能強化に集中することができます。~ |
- | またxpWiki特有の機能に「Wiki書式レンダラー機能」があります。これはWiki書式をxpWiki以外のXOOPSモジュールで利用できるようにする機能で、これにより利用者にHTMLを一切書かせないでリンクを指定することもできます。 | + | またxpWiki特有の機能に「Wiki書式レンダラー機能」があります。これはWiki書式をxpWiki以外のXOOPSモジュールで利用できるようにする機能で、これにより利用者にHTMLを一切書かせないでリンクを指定することも可能です。 |
| | | |
| *** 編集・閲覧権限を細かく設定できる [#t54307e1] | | *** 編集・閲覧権限を細かく設定できる [#t54307e1] |
| | | |
- | Wiki本来のコンセプトでは「誰でも自由に編集ができる」というのが大きな魅力でした。例えばPukiWikiなどでは「誰かが勝手に編集(書き換え)してしまうのですが?」という問いには「Wikiとはそういうものです」と答えています。しかしこれはちょっと極端すぎる意見といえます。Wikipediaの不毛な編集合戦がいい(悪い?)例ですし、特に企業がWikiを提供している場合などは信用問題にもなりかねません。しかしWikiエンジンに本格的なアクセス制御を組み込もうとすると、それは非常に大変な話になってしまいます。~ | + | Wiki本来のコンセプトでは「誰でも自由に編集ができる」というのが大きな魅力でした。例えばPukiWikiなどでは「誰かが勝手に編集(書き換え)してしまうのですが?」という問いには「Wikiとはそういうものです」と答えています。しかしこれはちょっと極端すぎる意見でしょう。Wikipediaの不毛な編集合戦がいい(悪い?)例ですし、特に企業がWikiを提供している場合などは信用問題にもなりかねません。しかしWikiエンジンに本格的なアクセス制御を組み込もうとすると、それは非常に大変な話になってしまいます。~ |
| xpWikiではXOOPSのユーザー管理機能を利用して、ページごとにユーザーやグループによる編集、閲覧権限を設定することができます。ゲストには閲覧のみを許可し、編集は限られたメンバーのみで行うことも容易です。 | | xpWikiではXOOPSのユーザー管理機能を利用して、ページごとにユーザーやグループによる編集、閲覧権限を設定することができます。ゲストには閲覧のみを許可し、編集は限られたメンバーのみで行うことも容易です。 |
| | | |
| XOOPSにはXOOPS2.x、XOOPS Cube Legacy、XOOPS JPEx、ImpressCMSなど様々な派生版がありますが、xpWikiは現行のほぼすべてのXOOPS環境で動作が確認されています。またEUC-JP、UTF-8にも対応していますので、日本語を含むマルチバイトの文書も扱うことができます。 | | XOOPSにはXOOPS2.x、XOOPS Cube Legacy、XOOPS JPEx、ImpressCMSなど様々な派生版がありますが、xpWikiは現行のほぼすべてのXOOPS環境で動作が確認されています。またEUC-JP、UTF-8にも対応していますので、日本語を含むマルチバイトの文書も扱うことができます。 |
| | | |
- | ** [#z5fee03c] | + | ** [#f44b934a] |
| + | ~ |
| #navi(../) | | #navi(../) |