BiNDは何を自動修復するのか?

261 views
9 月 30, 2007 by 組長
Filed under: BiND for WebLiFE*, DS*Style

「BiNDの自動修復機能」とは何らかの理由でサイトが壊れてしまっても、BiNDがある時点の状態にサイトを復元してくれる機能のことらしく、FAQだったかmixiだったかで見かけて「それはすごいな」と思っていましたが、特にそれ以上の興味は沸きませんでした。
ところが、テンプレートを自作しようと調べ物や実験をしていた際に偶然この機能に出会ってしまい、実験自体はまさに組長の自己満足でしかないのですが(笑)、
　何をどこまで直しているのか?
について皆さんが知っていて損することは無いでしょうし、また、これによって
　「何となくBiNDって遅いよね」
という、皆さんが何となく引っかかっている感覚の理由(のひとつ)が説明できるのではないかと考え、以下に記すこととします。

なお、これはWindows版BiNDについての内容であり、Mac版についても100%同様のことが言えるかどうかは検証していません。また、組長はデジタルステージさんと何も関係ない「ただの物好き」であり、何もかも鵜呑みにして信用しないようにしましょう(笑)

—

さて本題に入りますが、皆さんにもイメージしていただきやすいように、これから行う実験に使用するサイトは
　「おまかせで作る」の「コーポレート(GlobalRed)」
とします。できれば事前に皆さんもサイトを作って中身を見てみると、これ以降の解説がわかりやすいと思います。

まず、BiNDによって生成された「Site0002フォルダ」を見た時点で明らかに見慣れないファイルがあります。

bdsite.xml

というファイルです。
XMLというファイルは、何らかのデータの意味や構造を記述するデータベースのようなものです。
なのでBiNDの「何か」を記録するための設計図の可能性があります。
そこで早速bdsite.xmlを開いてみると・・・

上から４行目あたりには「HOME」とか「index.html」とか書いてあるし、

ここなんか、思いっきりページのデータみたいです。
やはりこれはBiNDにとって重要な設計図だろうと当たりをつけて実験を進めることにします。

まず、MyBiND_Sitesに生成されたSite0002フォルダの中から、

bdsite.xml

以外を削除し、BiNDを起動してみました。
結果は・・・

先ほど作ったサイトが、サイトシアターには表示されなくなりました。
ということは、サイトとして認識されるには他のファイルが必要ということです。

そこで、BiNDを一旦終了し、どのサイトにも共通して存在していてサイトシアター画面で見かける画像やxmlファイルが入っている怪しげな

bdflashinfoフォルダ

を「Site0002フォルダ」に戻してBiNDを起動してみると・・・

サイトシアター画面にサイトが現れたました。

【ここまでの実験でわかったこと】

BiNDがサイトとして認識するには「bdflashinfoフォルダ」が必要。

—

それでは「Site0002フォルダ」に

　bdsite.xmlとbdflashinfoフォルダしかない状態

でサイトエディター画面に進みましょう。

htmlファイルは何も無かったのにコンテンツが表示されています。
ただし画像はリンク切れの状態で「dummy_054.jpg」「LinkIcon」など代替テキストが表示されています。
この時点で「Site0002フォルダ」がどうなっているのか見てみると・・・

なんとファイルやフォルダが増えています。増えたのは、

index.html
index.css
_modulesフォルダ

です。

【ここまでの実験でわかったこと】

BiNDがサイトとして認識するには「bdflashinfoフォルダ」が必要。

この状態でサイトエディター画面を開くと

index.html

index.css

_modulesフォルダ

が復元されるが、画像はリンク切れになっている。

ということは、bdsite.xmlにはサイト復元のために必要なデータが格納されている。

—

どんどん行きましょう。次はリンク切れの画像を何とかしたいのでブロックエディタを起動します。
画像と文章、リンクが混在している「最近の一押しNEWS」(メニューの右、TOPICSの下の部分)の編集ボタンを押してブロックエディタを起動しました。

おっ!　画像のサムネイルが表示されてるじゃありませんか。

画像を早速クリックして「画像パーツ設定」に切り替え「開く」ボタンを押すと・・・

アラート

画像は無いようです。残念・・・
続いてリンクパーツをクリックして「リンクパーツ設定」に切り替えると・・・

リンクアイコンは(同じ画像ファイルだけど)復活しています。

【ここまでの実験でわかったこと】

BiNDがサイトとして認識するには「bdflashinfoフォルダ」が必要。

この状態でサイトエディター画面を開くと

index.html

index.css

_modulesフォルダ

が復元されるが、画像はリンク切れになっている。

ということは、bdsite.xmlにはサイト復元のために必要なデータが格納されている。

ブロックエディタのサムネイル画像は「そこに何の画像を設定していたか」を視覚的にユーザーに知らせるため、bdsite.xml内に格納されていると思われる。

リンクパーツなどのアイコン(画像ファイル)は「_modules」フォルダに格納されている。

—

いろいろ分かってきました。ここで想像できるのは「じゃあ画像以外、HTMLファイルは復活できそう」ということです。
では、これらのファイルは「どの時点で復活する」のでしょうか?

この点については、とりあえず「画面左のサイトマップでページを切り替えた時かな?」と推測してみます。
そこで、サイトマップの「ポートフォリオ(portfolio)」コーナーにある「1ページ目(index.html)」を選択して「Site0002フォルダ」を見てみると・・・

予想通り「portfolio」フォルダが追加され、フォルダの中には・・・

index.html
index.css

が復活しています。
同じように、「掲載誌一覧(magazine)」「会社情報(info)」「プライバシーポリシー(privacy)」の各コーナーのページを選択すると・・・

各フォルダが復活しています。
では、ここで考えてみましょう。

実験を始める前、すなわち「bdsite.xml」以外を全て削除する前の正常なサイトと、実験を続けながら復活したサイトを比較して足りないものは何か?

お分かりでしょうか?それは、

　_srcフォルダ

です。
では、削除してしまった「_srcフォルダ」をゴミ箱から元に戻してみます。

戻したフォルダは「_srcフォルダ」だけです。他のファイルやフォルダはBiNDが修復したものです。
そして、改めてサイトエディタ画面に戻り、ページを切り替えてみると・・・

やはり画像が復活しました!!
フォルダの名前に使用されている src は source の略で、プログラムなどではよく使う表現方法です。source には「源」とか、「出所」という意味があります。「_srcフォルダ」はサイトに配置したオリジナル画像の「出所」なのであり、オリジナルであるがゆえにこればかりはBiNDでも復元不可能なのです。

【ここまでの実験でわかったこと】

BiNDがサイトとして認識するには「bdflashinfoフォルダ」が必要。

この状態でサイトエディター画面を開くと

index.html

index.css

_modulesフォルダ

が復元されるが、画像はリンク切れになっている。

ということは、bdsite.xmlにはサイト復元のために必要なデータが格納されている。

ブロックエディタのサムネイル画像は「そこに何の画像を設定していたか」を視覚的にユーザーに知らせるため、bdsite.xml内に格納されていると思われる。

リンクパーツなどのアイコン(画像ファイル)は「_modules」フォルダに格納されている。

「_srcフォルダ」にはオリジナル画像が保存されている。

—

以上、長くなってしましたがまとめに入ります。

冒頭に、今回の記事の趣旨を2点あげました。

何をどこまで直しているのか?について情報を書きます。
「何となくBiNDって遅いよね」の理由のひとつを考えてみます。

です。

まず「何をどこまで」についてですが、何をどこまでというよりも

bdsite.xml
bdflashinfoフォルダ
_srcフォルダ

さえあれば、ある時点の状態までは元に戻せるということが分かりました。もしローカル側(自分のマシン)のデータが吹き飛んでしまったとしても、サイトがサーバーにアップロードしてあれば先ほどのファイルとフォルダをダウンロードしてくればBiNDが修復してくれるわけです。
個人的には、これは「修復」という側面もあるのでしょうが、むしろ将来に向かって(どんなブラウザが今後登場するかわかりませんから)、常にXHTML+CSSのコーディングを最適化しなければならないBiNDにとっては当然の機能なのだと考えています。
まあ、いずれにしてもとにかく修復してくれるわけですから、ユーザーにとっては心強い機能ではないですか。

そして「何となくBiNDって遅いよね」についてですが、これまでの説明で何となくご理解いただけたかもしれませんが、BiNDはページ切り替えやブロックエディタでの編集などのアクションごとにサイトの設計図である「bdsite.xml」を書き換えたりhtmlやcssを生成し直しており、この一瞬の「空白の時間」が「反応鈍い」ひいては「遅い」に繋がっているのではないかと思うのです。

もちろん「遅くていいよ」というわけではないです。軽快に操作できるに越したことはありません。
でも、その遅さがサイト修復(または最適化)というある種の「保険」のためだと思えば、BiNDとの付き合い方も少しだけ変わるのではないかと思うのです。