ディレクトリツリーの育て方
現在は主に、フォルダの階層表示を行う、
言ってみれば、ディレクトリツリーを作っています。
どのようなものかと言うと、
フォルダの中身を一望できるようなものです。
それを今は、GoogleAppsスクリプトにて、
Googleドライブのフォルダ構造をサイトに表示というのを行っています。
原理としましては、まず対象のフォルダ1つを指定し、
その配下のフォルダやファイルを次々に読み込んでいくというものです。
それを行うには、フォルダの中身を読み込む関数を別に作り、
配下のフォルダを見つけたところで、その関数、
つまりは自分自身を自分の中で読み込むというスクリプトを組みます。
他のプログラムでもそうでしょうが、スクリプトでは、
別の関数しか読み込めないという事はありません。
自分自身を読み込んで、それを別のインスタンスとして
稼働させるという事も可能です。
原理はわかったとしても、問題なのは、そのフォルダの中身でしょう。
フォルダの中身の量が増えるにしたがって、当然処理の量も増えていきます。
しかも、フォルダの中身は利用するお客さんによって、
どんどん追加されるものとなります。
そうなると、GoogleAppsスクリプトの場合は、
起動時間の超過というようなエラーになります。
これを防ぐ方法としましては、まず2つの方法が考えられます。
ひとつは、ループ内で処理をする要素を減らすなどをして、
処理の軽減を行う。
これはまだ考察中の部分でして、個人的には、
ファイル単体ごとにドライブにアクセスしている事が、
処理を増やしている要因ではないかとも考えています。
それならば、対象フォルダ以外のファイルも全て取得する、
「getAllFiles()」「getAllFolders()」関数で、
あらかじめ取得しておき、それらの親フォルダIDを取得、
これらの情報から、ツリーを作成していくという事を考えていたりします。
もうひとつは、限度として決めてお客さんにも納得していただく事。
1回の処理では困難である事を伝えたうえで、
大量のファイルが入ったフォルダを、一度に出力しようとは考えず、
いくつかのフォルダに分けて出力するという方法を取るなど、
代替処置を取るなどの手があると思います。
たとえばSDカードにしても、SDHCである同規格であったとしても、
16GBを境に32GBのメモリーカードを認識しない機種も存在はしますし、
一度に表示できるファイル数に限度のある機種も、世の中には存在します。
どのような処理をもってしても、無限に増え続ける要素を処理するのではなく、
あえて妥協をし、利用できる範囲でうまく利用していただく事を
提案するのも、また手ではないかと思ったりします。
しかし、個人的にはより処理を軽くし、
出来る限りは、多くのファイルを取得できるようなスクリプトを
組んでいければと思ってはいます。
ですが、それでもやはり限度というものは存在し、
プログラミングが出来るからと言って、決して万能ではないのです。
どんな物でも、無理難題を実現するよりも、
有効活用を考える事も大事な事だと思います。