モジュール選択技術の事例研究
最近、クライアントからDrupalのサイトに新しい機能を追加するよう依頼されました。ブラウザにPDFファイルを表示します。 drupal.orgのオプションを閲覧したとき、私は新しいモジュールを選んだので、これが私の実際の意思決定プロセスを文書化する絶好の機会であることに気付きました。 私はいつもモジュールを賢明に選ぶと言っていますが、今ではこれが実生活でどのように機能しているかを見ることができます。
あなたが望むものを定義する
最初のステップは、あなたが望むものを定義することです。 私の場合、私は望んでいた：
- この例のように、WebブラウザでPDFファイルを表示する機能。 クライアントは会社のニュースレターのPDFをアップロードし、訪問者はそれらを簡単に読むことができます。
- このサイトはDrupal 7なので、モジュールはそのメジャーバージョンと一致する必要があります。 （Drupal 7はいまだ外に出ているので、モジュール開発者がDrupal 7のバージョンをまだ公開していない場合は、おそらくそうではありません。）
- クライアントはこれを指定していませんでしたが、サードパーティのサービスに頼ることも避けたかったのです。 ビデオの場合、私はYouTubeやVimeoにコンテンツを投稿してからDrupalサイトに埋め込むことができますが、PDFの場合、可能性のある面倒が潜在的な面倒さ、破損、費用を上回るとは考えていませんでした。 しかし、それが唯一の選択肢だった場合、私はサードパーティサービスにオープンしていました。
- サードパーティのサービスを避けたいと思っていたにもかかわらず、私の選択には第三者のJavascript ライブラリが必要になるだろうとわかっていました。 これにより、将来のアップグレードに追加のステップが追加されますが、サードパーティのサービスに頼るのではなく、自分のライブラリのコピーを実行することが一般的には良いと感じています。
- 私はモジュールをできるだけ軽量で具体的なものにしたいと思っていました。 私は、メディアファイルを扱う、または整理する根本的な新しい方法に関わりたくはありませんでした。 画像を拡大して表示するためのColorboxのようなものが欲しかったですが、画像ファイルをどのように管理するかはまったく関係ありません。 私は、このライブラリがpdf.jsであることには感心しましたが、私は他の可能性にもオープンでした。
- いつものように、私はDrupalモジュールを選択するための一般的なガイドラインに従いたいと思っていました。 基本的には、できるだけ数千人が（すでに使用している）すでに使用されているモジュールを、依存性を最小限に抑えて選択してください。これは、将来プロジェクトをサポートし続ける予定のアクティブな開発者によって維持されているようです。ライセンス料が必要です。
Drupal.orgで検索
これらの目標を念頭に置いて、次のステップはDrupal.orgでの簡単な検索でした。 モジュール・グッドネスのボール・ピットに飛び乗る時間。
＆＃34;比較＆＃34; PDFモジュールのページ
私の最初の休止は、このページ：PDFビューアモジュールの比較です。 Drupal.orgは、同じスペース内のさまざまなモジュールの長所と短所を概説する優れたドキュメンテーションページの伝統を持っています。 比較ページのリストが中央にありますが、サイト全体に散在しています。
PDF比較ページには、4つのPDFビューアモジュールが含まれていました。 私はここでそれらをカバーし、検索して見つけた他のいくつかのものをカバーします。 私はスキップすることを決めた候補者から始めます。
さて、これらのモジュールがなぜこのプロジェクトでうまくいったのか（あるいはほとんどなかったのか）の詳細を掘り下げてみましょう。
ファイルビューア
ファイルビューアはInternet Archive BookReaderを使用しています。私はInternet Archiveの中毒者ですから興味をそそられました。 私がそこに行くたびに、私は恐怖のくすぐりを感じ、私がエーテルから摘み取ることができる本の山に圧倒される。
それは、デモンストレーションサイトが私には少し醜いと思われると言われています。 私はそれで生活するかもしれませんが、pdf.jsがはるかにスタイリッシュに見えるときに私のクライアントが疑うことがありました。
また、プロジェクトページをもう一度見て、大胆な発表を頂きました： このモジュールは、PDFモジュールに正式に移行されました 。 けっこうだ。 400個以下のインストールで、より一般的なPDFモジュール（これから説明します）との統合は良い動きのようです。 マージ/移動/放棄されたモジュールは絶対にダウンロードしないでください。
Googleビューアファイルフォーマッタ
Google Viewer File Formatterは、Googleドキュメントを使用してウェブページにファイルの表示を埋め込む方法です。 私はGoogle Docsの多機能性が気に入っていましたが、私の目標の1つは、サードパーティのサービスとは独立していることでした。
また、このモジュールのインストール数は100未満でした。
Ajaxドキュメントビューア
「AJAX」は一般的なJavaScript用語ですが、Ajax Document Viewerは特定のサードパーティサービスに依存していることが判明しました。 約100回のインストールのみ。 上に移動...
Scald PDF
Scald PDFには40個のインストールしかありませんでしたが、明らかにScald（はい）という大きなプロジェクトの一部だったので、一見しなければなりませんでした。 Scaldプロジェクトのページでは、 「 Scaldは、DrupalでMedia Atomsを処理する方法を革新的に取り入れたものです 」と説明しています。
その文章は、「革新的な取り組み」と「アトム」とペアになった「メディア」という2つの巨大な赤旗を生み出しました。 "Atom"は明らかに "物"のための再利用された言葉でした。それはそれをすべて赤旗にしました。 Drupalは、これらの空ボックス型の単語、つまりノード 、 エンティティ 、 機能に好都合です。単語が一般的になればなるほど、変化はより掃除されます。
私がスクロールダウンしたとき、私の疑惑が確認された。 Scaldがどのようにして自分のサイトでMediaをどのように扱ったかについて、私が興奮した主張を読んでいます。
今、真実は、Drupalのメディア処理がいくつかの再発明を使用できるということです。 Scaldはこの分野で唯一野心的なプロジェクトではない。 しかし、これまでのインストール数が1000未満であったため、1階に入ることは望ましくありませんでした。
確かに、来年、Scaldが次のViewsになるかもしれない。 それは揺れ動くだろう。 しかし、それは捨て去られたサイトの（小さな）跡が残っているので、捨て去ることもできます。
今のところ、私ははるかに野心的で危険な解決策に固執したいと思っていました。 PDFを表示してください。 それが私が求めていたものです。
シャドーボックス
Shadowboxは私を驚かせました：PDFから画像、ビデオまで、あらゆる種類のメディアを表示する単一のソリューションだと主張しました。 これは「メディアアトム（Media Atoms）」のような全く新しい概念を導入せずにメディアを表示することに焦点を当てるだけなので、Scaldほど掃除はしていませんでした。 しかし、私が言及したように、私は既にColorboxが好きです。 私はその決定を再考する必要はありませんでした。
しかし、私は16,000以上のインストールで、Shadowboxが同じスペースでより強力な選択肢になる可能性があることに注意しました。 私は一見をしなければならなかった。
Shadowbox Drupalモジュールは、基本的にJavascriptライブラリShadowbox.jsの橋渡しであるため、私は図書館のウェブサイトをチェックアウトしました。 そこで、私は次の2つの理由を発見しました。
- 図書館では、商業利用にはライセンス料が必要です。 手数料は十分に妥当でしたが、私は無料ではないオープンソースソフトウェアを避けようとしています。
- FAQを慎重に検索すると、Drupalモジュールページの説明とは異なり、PDFはShadowboxライブラリによって100％サポートされていないことが明らかになりました。 おっとっと。 私はチェックして良かった。
2つの競合相手：＆＃34; PDF＆＃34; ＆＃34; PDFリーダー＆＃34;
残りの部分を取り除き、今私は2つの明らかな候補者になった：PDFとPDFリーダー
この2つのプロジェクトには、
- 両方とも、ほぼ3,000回のインストールがあり、これは代替案（Shadowboxを除く）よりもはるかに優れています。
- 両方とも同じ外部Javascriptライブラリpdf.jsを使用していました。
違いは？
PDFリーダーにもGoogle Docsの統合オプションがありました。 この特定のケースでは、私のクライアントがそれを好きかもしれないと思ったので、私はその選択肢が好きだった。
一方、 PDFは、共同メンテナーを求めているとマークされました。 これは、開発者が間もなくプロジェクトを放棄するという兆候かもしれませんが、一方で、最も最近のコミットは1週間前であったため、少なくとも開発者は依然として活発でした。
一方、 PDF Readerは積極的に維持されているとマークされましたが、最新のコミットは1年前です。
明確な勝者がなければ、私はそれらを両方ともテストすることにしました。
競合相手のテスト
私は両方のモジュールを私のライブサイトのコピーでテストしました。 （モジュールがどんなに強固で無害であっても、ライブサイトで最初に試してはいけません。サイト全体を破壊する可能性があります）。
PDFより多くのオプション（Google Docsなど）があるように思えたので、私はPDF Readerに偏っていました。 だから私はPDFを最初に試して、それを取り除くことにしました。
PDF失敗：コンパイルが必要ですか？
しかし、 PDFをインストールしてREADME.txtを読むと、私は見ただけでプロジェクトのページで無視した問題を発見しました。 何らかの理由で、このモジュールではpdf.jsを手動でコンパイルする必要があります。 プロジェクトページでは、これが必ずしも必要ではないことが示唆されていましたが、README.txtはそれを示唆していました。
PDFリーダーはこのステップを必要とせずに全く同じライブラリを使用するので、私は結局それを試してみることにしました。 それがうまくいかない場合は、いつでもPDFに戻ってpdf.jsを手動でコンパイルすることができます。
PDFリーダー：成功！ 並べ替え
だから、まもなく、私はPDFリーダーを試しました。 このモジュールは、Fileフィールドを表示するための新しいウィジェットを提供します。 必要なコンテンツタイプにファイルフィールドを追加し、ウィジェットタイプをPDF Readerに設定します。 次に、このタイプのノードを作成してPDFをアップロードします。 PDFは、ページの「ボックス」に埋め込まれて表示されます。
コンテンツタイプを再度編集し、フィールドの表示設定を変更することで、さまざまな表示オプションを試すことができます。
私は、各表示オプションに長所と短所があることを発見しました。
- Googleドキュメントリーダーは埋め込み機能としてはうまく機能しましたが、フルスクリーンにするためにクリックしたとき、私のレート制限を超えていたことを謝罪したGoogleドキュメントページに巻き込まれました。 おっとっと。 おそらく、このモジュールを有料のGoogle Appsアカウントに接続した方が信頼性は高いですが、私のクライアントがディスプレイを気に入らないと確信していたので、気にしませんでした。
- pdf.jsオプションはFirefoxとChrome上ですばらしく機能しました。 しかし、私がInternet Explorerを起動したとき、ボックスは空に見えました。 どうやら、これはPDFリーダーモジュールではなく、pdf.js自体の問題です。 私は、pdf.jsがMozillaによって開発され、Internet Explorerがそれ自体であるとすれば、これを期待していたはずです。 それでも、私は、pdf.jsが最初からすべてのブラウザで確実に動作していることを確認することを考えていなかったことに失望しました。
- 埋め込みオプションは最も信頼性の高いものでした。 これは、実際にはWebページのボックスにAdobe Readerを表示していました。 私のFirefoxはまだpdf.jsを実行することを好みましたが、これはブラウザの設定だと思います。 いずれにせよ、訪問者がFirefoxまたはAdobe ReaderのようなPDFビューアを持っていれば、PDFが表示されます。
したがって、最終的には、私のソリューションは、 埋め込み表示オプションでPDFリーダーを使用することでした。 このオプションを使用すると、PDFをDrupalノードに添付してDrupal Webページに確実に表示できます。
残念なことに、時には「信頼できる」だけでは不十分です。 この検索のすべての後、私は結局サードパーティサービスを検討しなければならなかった。