3

ユーザーケースファイルのリポジトリを提供するWebベースのアプリケーションを開発しています。ユーザーが完全な読み書き機能を備えた Web ブラウザからこれらにアクセスできるようにしたいと考えています。

Windowsクライアントを備えたローカルLinuxサーバーでホストされていた以前の世代のシステムでは、フォルダーを共有し、\\server\share_name\file.docタイプのリンクでフォルダーにアクセスできました。これらのタイプのリンクが Web ページ (インターネット エクスプローラー) に含まれていて、MS Word で開いたファイルをクリックすると、共有フォルダーに直接保存できます。ただし、これらのタイプのリンクは IE でのみ機能し、FF や Chrome では機能しません。

次世代のシステムでインターネット ベースのソリューションに移行するには、同様の機能が必要です。

私たちは、WebDAV (または FTP/SFTP) を共有し、各クライアント マシンのローカル ドライブをそれにマッピングして、同様の機能を提供するというアイデアをいじっています。ただしこれは、\\server\share_name... タイプのリンクを持つ FF または Chrome ではおそらくうまく機能しません。簡単なテストを行ったところ、ファイルを開くと、file:// リンクは書き込み機能を提供しません。

最後の手段として、手動のファイル アップロード ダイアログを使用できますが、これは理想的ではなく、追加のエンド ユーザー トレーニングが必要になります。

この分野での同様の経験と、考えられる解決策/ベストプラクティスはありますか。

4

3 に答える 3

2

リモートリソースをローカルドライブとしてマップする場合、ブラウザの場合、これはローカルドライブになります。また、ブラウザはローカルファイルシステムへのアクセスが制限されています。これで、ブラウザへのリンクを提供すると、ブラウザのデフォルトの動作は、リンクの背後にあるリソースをダウンロードし、ローカルアプリケーションにそれを処理させることです。ブラウザは、リモートリソースを別の方法でローカルに開く方法を知りません。

解決策は、ブラウザに何か（ある種のリンクファイル）をダウンロードさせ、ローカルヘルパーモジュール（外部アプリケーションまたはブラウザプラグイン）にこのリンクファイルを開いてもらい、このリンクファイルで指定された場所をローカルで開くことです。これはクライアント側のヘルパーモジュールであるため、クライアントシステムと対話でき、提供されたリンクを開く方法を認識します。仮想ドライブ文字はシステムごとに異なる可能性があるため（ディスクをドライブ文字にマウントする場合）、ヘルパーモジュールは、正しいローカルドライブを指すようにリンクを解決する必要があります。非表示の仮想ドライブを作成する場合（仮想ストレージ製品でこれを実行できます）、リンクは「\ SomeFancyNameUniqueToYourApp \ Path \ To \ File.ext」のようになり、解決する必要はありません。そして、ほとんどのアプリケーションはこのタイプのパスをうまく処理します。

確かなことはわかりませんが、ブラウザがヘルパーモジュールを必要とせずにWindows .lnkファイルを開く可能性があります。非表示の仮想ドライブを使用すると、サーバー上でLNKファイルを生成し、ブラウザでローカルに開くことができます。しかし、これは単なる推測です。私の賭けは、とにかくヘルパーモジュールが必要になるということです。

于 2011-06-28T10:06:17.040 に答える
1

ftp://username:password@hostname/タイプのリンクは機能するはずであり、MS アプリではそれらの処理が改善されています。それでも100%ではないけど

于 2011-06-29T12:12:01.440 に答える
0

SMEStorage.com をお試しください。これらを使用すると、ローカルの WebDav および FTP サーバーをマップし、Linux、Mac、または Windows のクラウド ドライブを使用してファイルにアクセスしたり、モバイル デバイス (iOS、Android、BlackBerry、および Windows Phone 7) からファイルにアクセスしたりできます。各ファイルに固有のファイル リンクを取得し、リンクの有効期限が切れるファイル共有を保護することもできます。

于 2011-06-28T17:45:32.083 に答える