Buzzwordの中核スペルチェックエンジンはGrant Skinner's Spelling Plus Library(SPL)(source)である。SPLは100%Flash・Flex用のプログラミング言語であるActionScript 3で書かれた商用ライセンスされた製品である。
Coletta氏は彼のブログ上で9月のリリースにおいてこれを議論している(source)。
私達はGrant Skinnerの素晴らしいSpellin Plus Library(SPL)を、ディクショナリールックアップとサジェスチョンを提供するため私達のエディターに追加しました。SPLは全体的にActionScript 3で実装されていてとても小さく速く、そしてアプリケーションが起動している間にバックグラウンドでディクショナリーをダウンロードし、解凍する機能を提供するのです。だからユーザはディクショナリーがダウンロードされている間待つ必要がないのです。スペルチェックを簡単にFlexとFlashコンポー ネントに含ませるのが可能なSPLのハイレベルなインターフェースに加え、ワードルックアップとサジェスチョンを行う低レベルのAPIがあります。(現在私達が使用している)スペルチェックソリューションを全体的にクライアント側で持っているのはとても良いことなので、将来的には未接続の使用をサポートする時も同様に動作するようになるでしょう。今週のColettaの掲載(source)において、彼はFlashランタイムのシングルスレッド性質における挑戦に関して論じている。
Buzzwordはユーザインターフェースを反応良く保つために、それぞれのキーストロークで動作を最小限に抑える必要がありますが、FlashはActionScriptが 実行できるスレッドをたった一つしか提供しないので、バックグラウンドスレッドを使用するという贅沢はできないのです(タイマーとframeEnterイベントを使用してバックグラウンドプロセスを行う方法はたくさんありますが、それらのイベントハンドラの競争とメインスレッドを自ら注意深く管理しないといけま せん。)。Buzzwordにおいて、私達は全てのスペルチェックを同期的に行います。私達は、ドキュメントの汚い区分のリストを保ち、ユーザがアイドリン グ中にタイマーイベント上の汚いリストに取り掛かりながらそれをバックグラウンドで行うことを考えたのですが、そうするとデザインの複雑性と不確定性が非常 に上がってしまうのでそれを全てフォアグラウンドで行い、どうになるか様子を見ることにしたのです。そしてそれが適切なアプローチであることが判明したのです。シングルスレッド環境でスペルチェックを実装するという挑戦と共に、Coletta氏はパフォーマンスにおける挑戦に関しても論じている。
Buzzwordが出来る限り早く起動するために私達がしている事の一つは、バックグラウンドでメインのスペルチェックをロードして解凍することです(実はバックグラウンドロードと解凍はSPL内にて起こるので、その製品のユーザは誰でもその恩恵を受けることになるのです。)。しかしながらバックグラウンドでディクショナリーをロードするには弱点もあります。それはディクショナリーのロードとドキュメントのエディット間で競合状態を生むのです。ディクショナリーがスペルチェック用に完全に有効になる前にドキュメント上で5、10秒程の作業をするのは、Agileのユーザにとっては難しいことではありません。ユーザを5秒、もしくは10秒も待たせるのはよくありません。通常私達はドキュメントが開いたときにフラッグされている言葉だけを再チェックするのですが、この特別なケースにおいては、ユーザがしばらくの間"あなたがタイプしている間の"チェックなしに編集することが可能なので、私達はそのディクショナリーがロードし次第すぐにドキュメント全体をリスキャンする必要があるのです。Buzzwordの協力的な性質を支持する一方、スペルチェッカー機能を付加するという挑戦に関して論じているDavid Coletta氏のブログ(source)の続きを読んでみて欲しい。より従来的なサーバサイドのフレームワークと比較した時、BuzzwordのようなRIAアプリケー ションを構築することに関して明らかに新たな考え方があることが分かる。Flexアプリケーションにおいて、新たな挑戦はFlash Runtime用のクライアントサイドのプログラミングのニュアンスを伴ってプラットフォームの力に付随してくる新たな使用ケースに関連していることが多いのである。
原文はこちらです:http://www.infoq.com/news/2007/12/buzzword-spell-checker