サイトの公開から一週間ほどたったころ、作りを左右する話がひとつ決まった。このサイトは、将来、いまのクラウドから格安のレンタルサーバーへ引っ越す可能性があるという。ならば、特定のサーバーの機能に寄りかかった作りにはできない。そしてもう一つ。作品の入れ替えや展示の告知は、制作側を経由せず、店主が自分の手でできるようにしたい。頼まれるたびに私が動くのでは、更新はいつも後回しになる。この二つを同時に満たす方法を考えた。
管理画面は、ふつうサーバーが要る
サイトを画面から更新できる仕組みは、ふつう、サーバー側で動くプログラムとデータベースを前提にする。便利だが、その便利さはサーバーに根を張る。引っ越すたびに動作環境を整え直すことになり、格安のサーバーでは、そもそも動かないことすらある。将来の引っ越しを見据えるなら、その前提ごと捨てておくのが安全だった。便利さと引き換えに身動きを失うのは、小さな店には割に合わない。
データとロジックを分ける
まず、作品の一覧と展示の予定を、画面を描くプログラムから切り離し、それぞれ独立したデータファイルにまとめた。サイト側は、そのファイルを読んで描くだけ。更新とは、このデータファイルを差し替えることだ、と決めてしまう。仕組みの中心を、サーバーではなくファイルに置く。こうしておけば、置き場がどこに変わっても、中身の作りは影響を受けない。何を動かす部分とし、何を差し替える部分とするか。その線引きが、後々の身軽さを決める。
ブラウザの中で完結する編集
管理画面そのものも、ただの静的なページとして作った。合言葉を入れて開き、作品の追加や修正、並び替え、展示の登録をフォームで行う。編集中の内容はいったんブラウザの中に覚えさせておき、仕上げに、公開用データを書き出すボタンを押すと、先ほどのデータファイルが新しく作られて手元に落ちてくる。それをサイトの置き場に上げれば反映される。サーバー側に管理の仕組みが何もないから、引っ越し先がどこであっても、この手順は一つも変わらない。
写真も、データごと一式に
いちばん工夫したのは写真の扱いだ。作品写真はフォームにドラッグすると、ブラウザの中で自動的に手ごろな大きさに縮小され、画像のデータそのものがデータファイルの中へ埋め込まれる。写真置き場を別に構えて管理する必要がなく、ファイル一式を持ち出せば、写真ごとそっくり引っ越せる。移植性を、何よりも優先した形だ。縮小をブラウザに任せたのは、店主に画像の下ごしらえまで求めないためでもある。
書き出して、上げて、反映。たしかに一手間ある方式ではある。だがその一手間と引き換えに、この店のサイトは、どのサーバーにも縛られなくなった。身軽さは、小さな店の自由でもある。
次の回は、ギャラリーらしい見せ方と、ECらしい売り方のあいだで揺れた話を書く。