|
1: 2009-04-04 (土) 23:13:44 taked2  |
| | + | * xpWikiのデメリット [#t22ab283] |
| | + | RIGHT:&tag(xpWiki) |
| | | | |
| | + | #contents |
| | + | |
| | + | では逆にxpWikiのデメリットは何でしょうか。 |
| | + | |
| | + | ** 複雑なレイアウトができない [#w6aa4e21] |
| | + | |
| | + | これはxpWikiというよりWiki全般に共通するデメリットですが、レイアウト指向のページ作成には向きません。複雑な段組や図表を多用したページは苦手で、基本は1段組、図表の指定も右か左か中央かぐらいの指定しかできません。 |
| | + | |
| | + | ** XOOPSのモジュールである [#k8ae8b80] |
| | + | |
| | + | xpWikiがXOOPSのモジュールであるということは、メリットもある反面、デメリットでもあります。~ |
| | + | まずXOOPSという環境そのものに動向が左右されるということが最大のデメリットでしょう。技術的な面でもWebサーバの上に、XOOPS、そしてxpWikiが乗るという構造になりますので、通常のWikiクローンより高速アクセスなどの性能面で期待ができません。総じてXOOPSは動作が重く、中でもXOOPS Cube Legacyはもう一段もっさりしているようです。また複雑な構成であるということはxpWiki以外のXOOPSや他のモジュールのノウハウも必要になり、構築や運用、モジュールハックも一筋縄ではいきません。~ |
| | + | またXOOPSの市場性も問題になるでしょう。今後どのようなシェアを占めるのか、またXOOPS自体の開発方向性がどちらに向くのかによっては、せっかくxpWikiでWiki作ったのに、もうxpWikiが動く環境がないなんて最悪のケースも考えられます(まあ、それはどんなソフトでもある話ですが)。~ |
| | + | |
| | + | ** 設定が複雑 [#acc89656] |
| | + | |
| | + | xpWikiのベースとなったPukiWikiは多機能なWikiですが、そのため設定項目も非常に複雑になっています。その上にxpWiki独自の設定項目もありますので、すべてのオプションに精通しているのは作者のnao-ponさんしかいないかもしれません。またベースとなるXOOPSのバリエーションの違いや設定項目の多さ、もっというとWebサーバの環境やそれを実際に見る利用者のブラウザの種類を考えると、非常に多くの組み合わせがあり、設定は一苦労といえるでしょう。 |
| | + | |
| | + | ** バックアップが特殊である [#sbf96141] |
| | + | |
| | + | XOOPSの一般的なモジュールはデータをデータベースに保存しますが、xpWikiではページの内容をファイルで保存します。そのため通常のXOOPSのバックアップではxpWikiのページがバックアップされないこともあります。xpWikiには管理ツールとして独自のバックアップツールが用意されていますが、注意が必要です。 |
Counter: 3429,
today: 1,
yesterday: 0
