SimpleBoxes

Fastbook は UIWebView でも軽快に動作する件

iOS 版 Facebook の実装が HTML5 アプリケーションからネイティブアプリケーション (CocoaTouch フレームワークを使ったアプリケーション) に変更されたのは記憶に新しいところ

それに対して「Facebookのモバイルアプリが失敗した理由は HTML5 のせいじゃない。HTML5 でサクサク動く Facebook アプリを作って見せた Sencha Touch 開発チーム」という記事がありました。

元ネタは The Making of Fastbook: An HTML5 Love Story (以下、元記事) です。

簡単に言うと、「HTML5 だから遅いんじゃないよ、デモアプリケーション Fastbook のようにネイティブアプリケーション同等な (むしろそれを上回る) パフォーマンスでるよ」ということになるでしょうか。

動画も挙がっていて、自信の程が伺えます。

これに対して、いくつか指摘が挙がっています。

え?これSafariじゃね?WebViewとSafariじゃあスピード全然違うよ

[→はてなブックマーク - hazisarashi のブックマーク - 2012年12月20日]

Safariとかずるすぎワロタ。WebviewはSafariの約3.3倍遅いんですが、Webviewで動かすとどうなるんでしょうね(ゲス顔

[→はてなブックマーク - fikah のブックマーク]

同様に元記事のコメントでも……

The demo is really promising, but it is in MobileSafari. When you make an iOS app, you can only use WebView, which is a second-class and slower browser.

[意訳] デモはとても前途有望だけれど、MobileSafari で動いているね。iOS アプリを作る時には WebView しか使えなくて、それは遅いブラウザになってしまうよ。

[→元記事コメント @hlb]

A sticking point with iOS is that embedded WebKit (in Facebook’s old native app) performs horribly compared to Mobile Safari (what Sencha used here) due to Apple's selfish hoarding of the Nitro JavaScript engine.

[意訳] 問題は Facebook の前バージョンでも利用されてた組み込み WebKit で、このデモで使っている Mobile Safari よりもひどく遅いけど。Apple の勝手な囲い込みで Nitro JavaScript エンジンは使えないから。

[→元記事コメント @Ron Waldon]

Mobile Safari では Nitro と呼ばれる JavaScript エンジンでスクリプトが処理されるのですが、CocoaTouch フレームで利用できる UIWebView ではその高速な JavaScript エンジンが (セキュリティ上の理由から) 使われません。

私もこの点 (デモが Safari 上で動いている) は少し気になっていました。

それに対して、Sencha Team のメンバーの何人かが答えています。

@hlb the issue is NOT JavaScript. It's the DOM. The DOM engine is the *same* for both use cases.

[意訳] @hlb JavaScript が問題ではないんだ。DOM が問題で、DOM エンジンは (Safari も UIWebView も) 同じなんだよね。

[→元記事コメント @Jay Garcia]

@hlb Simply save the app to your homescreen to force it to use a WebView.

[意訳] @hlb ホームに置くと、WebView を使うようになると思う (iOS 5.1 以降では Mobile Safari を利用するようになったという指摘あり)。

[→元記事コメント @Jamie Avins]

@Ron Waldon It doesn't matter for such apps like this. Again as we mentioned the bottleneck is never JavaScript execution. We wrapped the app in native webviews for you to try it out yourself: github.com/extjs/fastbook

[意訳] @Ron Waldon このアプリではそこは問題にならないんだ。(これまで) 指摘している通り、ボトルネックは JavaScript の実行にあるわけではないから。ネイティブな webview で実装した例を github に挙げたので、試してみてね。

[→元記事コメント @Jacky Nguyen]

Jacky Nguyen さんと Jamie Avins さんは動画にも登場されています。

コメント受けて、WebView を使った利用例が github に公開されました

コードは実にシンプルで、

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    // Override point for customization after application launch.
    self.window.backgroundColor = [UIColor whiteColor];
    
    UIWebView* view = [[UIWebView alloc] initWithFrame:[UIScreen mainScreen].applicationFrame];
    [self.window addSubview:view];
    [view loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://fb.html5isready.com/"]]];
    [self.window makeKeyAndVisible];
    return YES;
}

メインのコードはこれだけ。UIWebView を作って http://fb.html5isready.com/ を開いているだけです。

動作させてみると、私が思っていた以上に速い。iPhone 4S / iOS 6.x で確認。確か iOS6 から WebView に対して動作割当メモリが増えたので、それも影響している可能性あり。

UIWebView 上の WebKit でも、スクロールとかきびきびと軽快に動作します。

iOS のアプリケーションとしては、ステータスバーをタップしてもトップにスクロールバックしない、ローディングアニメーションが表示されるべきところで表示されない、未実装な機能 (例えば検索機能) がある、などブラッシュアップが必要な部分はありますが、デモアプリケーションとしてはなかなか興味深い。

もっともこれでもって「HTML5 使うべき」とも言えない部分もあって、

スクロール速度だけを取り上げても。Facebookのエンジニアが指摘した第一の問題はそこじゃないですよね。クラッシュの原因が解らない等 http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html

[→はてなブックマーク - Teshのブックマーク]

という Tesh さんのブックマークコメントや

The premise of this argument is wrong. It's not a simple question of "slow" versus "fast." Application performance is only one factor in building an HTML5 app. Device support, engineer productivity, testability, measurement, tooling/debugging, and native integration are all points that should be factored in. Anyone who has burnt the hours trying to debug a perf issue on a device that doesn't support Webinspector knows this pain. As does anyone who has gotten the bug report about the keyboard not popping up correctly on insert random Android 2.X no one has ever heard of here. As does anyone who has gotten the layout performance awesome in one test environment only to test another and find it terrible. The argument that HTML is ready while the device landscape is not is pretty fraught.

As far as fast goes, even as well done as this demo is, the scrolling framerate is noticeably slower on the Nexus 4 compared against the native application. I feel like all the demo is proving is what we already knew - somethings can be done reasonably well in HTML while many other can't. I'm a person who would rather have the web win. I'm pretty sure it will win in time. It's a pretty clear fact that until the browsers/webviews get faster and/or the device's have faster hardware, HTML is the second best option for smartphones.

[意訳] 議論の前提が違っているよね。単に「遅い」か「速い」という問題じゃない。アプリケーション性能は HTML5 アプリを構築するひとつファクタに過ぎないよ。どのデバイスをサポートするか、エンジニアの生産性、テストのしやすさや計測しやすさ、ツールの使い勝手、デバッグのしやすさ、ネイティブなサポート、など全てのファクタを考える必要がある。ウェブインスペクタをサポートしないデバイスでパフォーマンスをデバッグするのがどんなに大変か知っている人はいる?Android 2.X でキーボードが正しく表示されずにランダムな文字が入力されてしまうというバグレポートを見たことがある人は?あるテスト環境では素晴らしく性能がいいのに、別の環境ではめちゃくちゃだというのを経験したことがある人は?この議論を実際デバイスを横向きにして見ると見づらいという事実についてはどう?

[意訳] 速さという点に関しては、このデモはとても良くできている。スクロールのフレームレートは Nexus 4 で見るとネイティブアプリに比べて遅いけど。このデモは Sencha Team が HTML に関して深く理解している (そしてそれは他の多くの人はできない) こと証明しているに過ぎないと思うんだ。私個人的にはむしろ web が勝って欲しいし、いつかその日がくると信じているけれども、それはブラウザとデバイスが十分に速いというの明快になった時で、HTML はスマートフォンに対して二番目にベストなオプションだと思う。

[→元記事コメント @Jackson Gabbard]

元記事に寄せられた Jackson Gabbard さんのコメントのご指摘の通り、単純に速い・遅いという問題ではなくて、もちろんそれはとても重要な部分ではあるけれども、あくまでも全体の一部の問題でしかありません。

ツールの使いやすさ、デバッグのしやすさ、習得に対する敷居の低さ、などはソフトウェアを恒常的にメンテナンスする上で、重要なポイントになってきます。

Objective-C が習得に対して敷居が低いかどうかはまた別の議論になってしまいそうですが、ネイティブサポートのため、ハック的な知識がなくてもある程度の性能はいけるという印象はあります。もちろん実装次第ですけれども。

これは SenchaTitanium だけでなく、他のクロスプラットフォームなフレームワークでも大きな課題になっているポイントのような気がします。

はてなブックマーク - Fastbook は UIWebView でも軽快に動作する件

スポンサーリンク

Safari で Reeder

[画像] Reeder on Safri

reederGoogle Reader を快適に利用できるアプリケーションです。

その reeder からインスパイアされて、似たルック & フィールを Chrome 上で実現する機能拡張が Reeder for Chrome (Unofficial) (以下、RFC) です。

残念ながら RFC の開発は継続されないことになりましたが、ソースは公開されています

RFC の最も肝となるルック & フィールは基本 css のみで実現されていて、Stylish を使えば、他のブラウザでも利用できそうです。

他に fork している人がいたので、その内容を確認しようと思っただけだったんですが、間違えて自ら fork してしまい、それをきっかけに中身を確認することに……。

  1. Stylish for Safari より Stylish の機能拡張をダウンロード・インストールします。
  2. ツールバー上にある「Stylish」ボタンから管理画面 (Manage) を開きます。
  3. 「Edit」を選ぶと新規スタイル編集画面が開きます。
    Title
    RFC
    CSS
    GitHub から CSS の内容をコピー
    Applies to
    "Regexp" を選択して、https?://www.google.*/reader/.*

その後、Google Reader を見ると Reeder のようなインタフェースに変わっていると思います。オススメは 3 カラム表示。

(Webkit に特化したスタイルを利用しているため) CSS の一部変更が必要になりますが、Firefox でもほぼ同様に Stylish から利用できます。

はてなブックマーク - Safari で Reeder

スポンサーリンク

Re: Excel列名変換問題で第2回社内プログラミングコンテストを開催してみた(前編)

JunichiIto さんによる「Excel列名変換問題で第2回社内プログラミングコンテストを開催してみた(前編)」という記事を見かけて自分でもやってみる。

正確に時間を測ったわけではありませんが、問題 1 と問題 2 あわせて一応 90 分で解けたと思います。

問題1: Excel列名変換問題
  • 仕様
    • 入力されたアルファベットを数字に変換する。
    • 変換ルールはExcelの列名と同等。
    • 例) A=1、B=2、Z=26、AA=27、XFD=16384
  • 起動時引数
    • [0] アルファベット (A〜ZZZZ...[上限なし])
  • 実行例
    • ExcelColConv.pl A → 1
    • ExcelColConv.pl AA → 27

[→Excel列名変換問題で第2回社内プログラミングコンテストを開催してみた(前編)]

問題 1 に対する私の回答

問題2: Excel列名変換問題(逆変換)
  • 仕様
    • 入力された数字をアルファベットに変換する。
    • ただし、問題1で作ったプログラムを拡張すること。
  • 起動時引数
    • [0] 0=数字へ変換、1=アルファベットへ変換
    • [1] 変換する数字またはアルファベット(どちらも上限なし)

[→Excel列名変換問題で第2回社内プログラミングコンテストを開催してみた(前編)]

問題 2 に対する私の回答

問題 1 回答

#!/bin/perl

if ($ARGV[0] =~ /[A-Za-z]+/)
{
  print &convert(uc($ARGV[0])) . "\n";
}
else
{
  &usage();
}
exit 0;

sub usage
{
  print 'Usage: ',$0,' input',"\n";
}

sub convert
{
  my $input  = shift;
  my $output = 0;

  my $rank = 0;
  foreach my $char ( reverse(split(//,$input)) )
  {
    my $num = index('ABCDEFGHIJKLMNOPQRSTUVWXYZ', $char) + 1;
    $output += $num * (26 ** $rank++);
  }

  return $output;
}

アプローチとしては、3 位の方と同等ですね。一応、入力パラメータチェックしてます。

問題 2 回答

#!/bin/perl

if ($ARGV[0] eq '0' and $ARGV[1] =~ /[A-Za-z]+/)
{
  print &convert(uc($ARGV[1])) . "\n";
}
elsif ($ARGV[0] eq '1' and $ARGV[1] =~ /[0-9]+/ and $ARGV[1] > 0)
{
  print &rev_convert($ARGV[1]) . "\n";
}
else
{
  &usage();
}
exit 0;

sub usage
{
  print 'Usage: ',$0,' dir input',"\n";
  print '       dir 0 : alpha to num [input must be alphabet]'."\n";
  print '       dir 1 : num to alpha [input must be number greater than 0]'."\n";
}

sub convert
{
  my $input  = shift;
  my $output = 0;

  my $rank = 0;
  foreach my $char ( reverse(split(//,$input)) )
  {
    my $num = index('ABCDEFGHIJKLMNOPQRSTUVWXYZ', $char) + 1;
    $output += $num * (26 ** $rank++);
  }

  return $output;
}

sub rev_convert
{
  my $input  = shift;
  my $output = '';
  my @chars = split(//,'ABCDEFGHIJKLMNOPQRSTUVWXYZ');
  my $base = @chars;

  my @stack = ();
  while ($input > $base)
  {
    my $num = $input % $base;
    push(@stack, $chars[$num - 1]);
    $input = int($input / $base);
    # Needs to decrement $input if $input value is in multiple of $base
    if ($num == 0)
    {
      $input--;
    }
  }
  # Now handles within $base case
  push(@stack, $chars[$input % $base - 1]);

  return join('',reverse(@stack));
}

入力数値が基数にあたる 26 の倍数の時、桁を正しく処理する必要があるのがトリッキーな部分になるでしょうか。

一応、ざっくり確認したつもりですが、間違っていたらごめんなさい。

[2010.11.04 03:30 追記] perl の場合、配列に対して負のインデックスを指定すると、配列の後ろからアクセスするという仕様があります。なので、$input % $base の結果が 0 になる場合、@stack には "Z" が格納されます。

はてなブックマーク - Re: Excel列名変換問題で第2回社内プログラミングコンテストを開催してみた(前編)

スポンサーリンク

Safari on iPhone 対応に関するメモ

Serene Bach 3.00b027 から iPhone/iPod touch 用の Safari 向け管理画面インターフェースをサポートしました。

Android のブラウザも対応したつもりでしたが、先程エミュレータで確認したら、認識されていませんでした。近日中に修正する予定。

iPhone/Android で採用されているブラウザエンジンは Mobile WebKit (Mobile Safari) と呼ばれるもので、WebKit のサブセットになっているようです。

デスクトップ版 Safari と Mobile Safari で挙動が違うことは知られている通り。JavaScript ではマウスイベントハンドラ、実行時間の制限などがあり、読み込める画像のファイルサイズに制限があったりします。

ここでは Windows 版・Mac OS X 版の Safari をデスクトップ版 Safari と呼んでいます。

今回、Serene Bach 3.00b027 開発中に気づいた細かーーい挙動の差異をメモ。

head 要素内で document.write は使えないっぽい

document.write 自体は使える様子ですが、実行場所を選ぶようです。

詳細は検証していないのですが、とりあえず head 要素内に置かれた scriptdocument.write は実行できないようでした。

どうしてそんな場所で document.write を実行しているのかというと、外部 js から別の js ファイルをロードするため。head 要素内に DOM で appendChild する方法もあって、個人的にはこっちの方がしっくりするんですが、やや古い Safari で動作しなかったという経緯があり、document.write を使っていました。

td 要素 (多分 th 要素も) の display スタイルを変更できないっぽい

これも詳細は検証していませんが、例えば、以下のようなスタイル……

table#specific > tbody > tr > td {
  display: block;
}

は動作しませんでした。

ある特定の項をブロック要素として動作させたい意図があったのですが、動作しませんでした。デスクトップ版 Safari では動作するので、Mobile Safari の特徴の様子です。perl スクリプト本体の方は変更なしでいけるかとも思ったのですが、この仕様 (?) のため、ダメでした。

contenteditable は利用できない

Preparing Your Web Content for iPad: Technical Note TN2262: Preparing Your Web Content for iPad でも触れられていますが、contenteditable は利用できないようです。

おそらく designMode もダメでしょう。とりあえず、Serene Bach 3 で利用されているカスタム CodePress は利用できませんでした。

はてなブックマーク - Safari on iPhone 対応に関するメモ

スポンサーリンク

Lightbox plus を使ったスライドショー

  • 2010.06.16 Wednesday
  • web

toybox で公開している Lightbox Plus ですが、スライドショーは実現できないか?という質問があったので、適当に見つくろってみました。折角なので、公開します。

内容としては、タイマーで次から次へと画像を表示するだけの処理で特に難しい内容ではありません。

公開しているサンプルスクリプト lightbox_plus.js では、末尾で


Spica.Event.run(function() { 
  var lightbox = new Lightbox({
    // ... 省略 ...
  });
});

のようにして Lightbox オブジェクトのインスタンス lightbox を生成しています。この変数 lightbox はローカル変数なので、ブロック外部では参照できません。

スライドショーを実現するために生成したインスタンスにアクセスできるよう、lightbox をグローバル変数にします。

面倒なので、グローバル変数にしましたが、スライドショーを実現するオブジェクトを作って、その中で Lightbox のインスタンスを保持するという方法がおそらくスマートでしょう。

あとは生成したインスタンスに対して、タイマーを使って画像を順に表示していけば良いだけです。

とりあえず、途中で止めるなどの処理は考えず、ページ内の全ての Lightbox 対象の画像を表示したらスライドショーを終わらせるという方針で作成してみます。

サンプルスクリプト lightbox_plus.js の末尾を削除して、代わりに Lightbox を設置する html の末尾に以下のような記述を追加します。


<script type="text/javascript">
var lightbox = new Lightbox({
  // ... 省略 ...
});
var slideCount = 0;
function runSlideShow()
{
  var num = lightbox._open + 1;
  if (num >= lightbox._imgs.length) num = 0;
  if ( slideCount < lightbox._imgs.length )
  {
    if ( slideCount == 0 )
    {
      lightbox._show(num);
    }
    else
    {
      lightbox._close_box();
      lightbox._show(num);
    }
    slideCount++;
    window.setTimeout( function(){ runSlideShow(); }, 5000 );
  }
  else
  {
    lightbox._close();
  }
}
</script>
<div><a href="#" onclick="slideCount = 0; runSlideShow(); return false;">play</a></div>

Lightbox の _show メソッドは画像のインデックスを引数に取ります。有効な数値は 0 から _imgs.length の間です。Lightbox の対象となる画像は _imgs に配列として保持されているので、その length を取れば有効引数の範囲がわかります。

Lightbox オブジェクトの _open 変数は現在開いている、あるいは最後に開いた画像のインデックスです。これを +1 することで次の画像のインデックスを特定できます。初期値は -1 なので、仮にまだ開いていなくても +1 することで 0 になり、問題ありません。

グローバル変数 slideCount はスライドショーで開いた画像の数になります。これが Lightbox 対象の画像点数に達するまでタイマーで順に次の画像を開くようにしています。

今回作成したサンプルはアーカイブとして置いてあります。

「Lightbox plus スライドショー」をダウンロード


    window.setTimeout( function(){ runSlideShow(); }, 5000 );

およそ 5 秒で次の画像を表示するようにしていますが、表示の終了から 5 秒ではなく、_show メソッドをコールしてから 5 秒なので、短すぎるかもしれません。きちんと作るなら、ここは表示し終わってからタイマーを開始すべきです。

はてなブックマーク - Lightbox plus を使ったスライドショー

スポンサーリンク

solipo 0.09

  • 2010.02.07 Sunday
  • web

solipo ver 0.09 を公開しています。→ [solipo 紹介ページ]

solipo は、Windows 上で動作する polipo の GUI ラッパーアプリケーションです。

「solipo」をダウンロード

solipo 0.09 では、以下の仕様変更・バグ修正を行いました。

  • polipo から forbidden / uncachable が読み込まれないバグを修正しました。
  • ランタイムがない環境で、solipo が起動しないバグを修正しました。
  • デフォルトのプロセス監視間隔をおおよそ 30 秒に短縮しました。

古いバージョンの solipo からは、 solipo.exe と polipo.exe を差し替えることでバージョンアップできます。

これまでの関連記事
はてなブックマーク - solipo 0.09

スポンサーリンク

solipo 0.08

  • 2010.02.06 Saturday
  • web

solipo ver 0.08 を公開しています。→ [solipo 紹介ページ]

solipo は、Windows 上で動作する polipo の GUI ラッパーアプリケーションです。

「solipo」をダウンロード

solipo 0.08 では、先日リリースされた polipo 1.0.4.1 を同梱しています。

solipo 0.07 に付属していた polipo 1.0.5 はプレリリース版ということもあり、動作がやや不安定でしたが、polipo 1.0.4.1 は 1.0.4 からのマイナーフィックス版で動作が安定していると思います。

また、バックグランドで動作している polipo が落ちていないかどうかを solipo 側から監視する機能を追加しています。

定期的に polipo が落ちていないかどうかをチェックして、落ちていたら、自動的に再起動します。

古いバージョンの solipo からは、 solipo.exe と polipo.exe を差し替えることでバージョンアップできます。

これまでの関連記事
はてなブックマーク - solipo 0.08

スポンサーリンク

Serene Bach セッション管理

  • 2009.04.21 Tuesday
  • web

Serene Bach では sb::Session というモジュールで、管理画面へのログインセッションを処理しています。

Serene Bach 3 での管理画面セッションの確認は、sb::App::Admin モジュールで行なっています。

Serene Bach におけるセッション処理のフロー自体はそれほど複雑ではありません。

[図] Serene Bach セッション処理フロー

コードに直すと以下のようになります。

  use sb::Session;
  
  # セッションオブジェクトの生成
  my $session = sb::Session->new('key' => 'session_key');
  
  if ( $session->check )
  { # セッションが有効
    my $extend = undef;
  
    # ... なんか処理を行なう ...
  
    if ( $extend )
    { # セッションを延長
      $session->start();
    }
    else
    { # セッションを終了
      $session->finish();
    }
  }
  else
  { # セッションが期限切れ、もしくは未発行
    my $login_success = undef;
  
    # ... パスワード確認処理 ...
  
    if ( $login_success )
    {
      $session->start();
    }
  }

sb::Session では、以下のメソッドを利用します。

check

有効なセッションが発行済かどうかをチェックします。

start

セッションを発行します。発行済の場合は再発行となり、セッション期限が延長されます。

finish

セッションを破棄します。このメソッドを実行しなくても期限切れのセッションは自動的に破棄されます。

セッションオブジェクトを生成する際に、渡している key がセッション整合に利用されます。

具体的には、この key を利用して cookie の発行などを行なっています。sb::Session モジュールは cookie の利用を前提に動作しているので、cookie が有効でない環境下では正しく動作しません。

関連記事
はてなブックマーク - Serene Bach セッション管理

スポンサーリンク

Serene Bach テストコード

  • 2009.04.18 Saturday
  • web

Serene Bach 3 の開発に当たり、ごく簡単なテストコードを作成して、公開前に簡易な動作チェックを行なっています。

lib/ ディレクトリ内にある test/ ディレクトリにテストコードがあります。

先ほど公開した Serene Bach 3.00 beta023 で有効なテストコードは

  • test_initparser.pl
  • test_loadall.pl
  • test_netaws.pl
  • test_netping.pl
  • test_plugins.pl

こられのテストコードをまとめて実行する「_testcases.pl」というスクリプトも用意されています。

これらのテストスクリプトは、lib/test/ をカレントディレクトリとして実行することを想定しています。

これらのテストコードは、テストを実行するためのモジュール sb::Test を使っています。

テストコードのメインルーチンは、非常にシンプルです。

  my $testcase = sb::Test->new();
  $testcase->add('plugins',\&_test,\&_check);
  $testcase->run();

add メソッドでテストケースを追加して、run メソッドで実行します。

add メソッドは、

  1. テスト名
  2. テスト用実行サブルーチン
  3. 期待値チェック

という引数を渡します。

テスト用実行サブルーチンは、関数をリファレンスを指定します。テスト用実行関数は何らかの出力を返して、その返り値を「期待値チェック」でチェックします。

期待値チェックは、期待する値そのものを指定するか、テスト用実行関数をチェックするためのサブルーチンのリファレンスを指定します。

サブルーチンのリファレンスが指定された場合、その期待値チェックサブルーチンには、テスト用実行関数の出力結果が引数として渡されます。

関連記事
はてなブックマーク - Serene Bach テストコード

スポンサーリンク

Serene Bach テンプレートの互換性問題

  • 2009.04.15 Wednesday
  • web

Serene Bach 2 のテンプレートでは、入れ子になった独自ブロックを擬似的に扱っています。

一方、Serene Bach 3 のテンプレートでは、入れ子になった独自ブロックをきちんと階層的に扱うように変更されました。

例えば、

_main-1
******
<!-- BEGIN test1 -->
test1-1
<!-- BEGIN test2 -->
test2
<!-- END test2 -->
test1-2
******
<!-- END test1 -->
_main-2

のような構成のテンプレートがあったとして、

  • 独自ブロック test1 を 2 回繰り返す
  • 独自ブロック test2 を 1 回繰り返す

という場合、

_main-1
******
test1-1
test2
test1-2
******
test1-1
test2
test1-2
******
_main-2

のようになるのが自然だと思いますが、Serene Bach 2 ではそのように出力することができませんでした。

Serene Bach 3 では、このような入れ子構成を維持したまま、テンプレート処理を行なうので、期待通りに出力されます。

しかしながら、その代償として「同じ名前の独自ブロックが離れて置かれた」ようなテンプレートに対して、Serene Bach 2 と同じように出力されないという互換性の問題がありました。

例えば、

_main-1
<!-- BEGIN test1 -->
<!-- BEGIN test3 -->
test3-1
<!-- END test3 -->
test1-1
test1-2
<!-- BEGIN test3 -->
test3-2
<!-- END test3 -->
<!-- END test1 -->
_main-2

のような構成のテンプレートがあった場合、独自ブロック test3 が離れた場所に二カ所あります。

これまでの Serene Bach 3 では、このようなテンプレートを Serene Bach 2 と同じように出力することができなかったので、テンプレートの修正が必要になっていました。

この互換性の問題は、Serene Bach 3 の次のβ版リリースで解消されます。これによりテンプレートに関して Serene Bach 2 との互換性がかなり向上しています。

はてなブックマーク - Serene Bach テンプレートの互換性問題

スポンサーリンク

1/6