マイクロソフトに対抗してるだけでは、MSともども、時代に取り残されるよ（＾＾）／

　で、前のブログで、書きたかったネタというのは、こいつ


OpenDocument普及促進団体が発足
http://www.itmedia.co.jp/enterprise/articles/0603/04/news011.html

　これは、なにかというと
(以下斜体は、上記記事より引用）


大手企業や団体が参加して、官公庁などにおけるオープンソースのオフィス文書フォーマット普及を目指す団体「OpenDocument Format（ODF）Alliance」が3月3日、結成された。


ほー、オフィス文書フォーマットの普及ねえ。。


参加しているのはIBM、ジャストシステム、Novell、Opera Software、Oracle、Red Hat、Sun Microsystemsといった企業や、OpenOffice.org、米マサチューセッツ州ハイテク委員会など、世界約35の企業・団体。


いちばん、普及しているマイクロソフトははいってないんだ。
PDFのAdobeは？？
もう、この時点で、なんか、あやしーにおいがするが。。

まあ、会の設立目的をみてみましょう。


技術の進歩と電子化の進展に伴い、公共機関ではさまざまなアプリケーションを使って文書を作成するようになっているが、こうした記録は相互に互換性がないばかりか


ここまでは、ほんと。言っていることはただしいが。。


将来的に使えなくなってしまう恐れがあるとODF Allianceは指摘。


　ちょっとまったー！
　それ、一昔まえの話だよ。。
　昔はたしかに、物理的な構造で保存していた。なので、アプリがなくなったら、開けないという危険はあった。

　しかし、現在は、うぃりあむのいたずらのような、ワーカーさんにすら、

・論理構造のXMLで書けば、
　　論理構造のXMLを物理構造に変換する機能があれば、
　　論理構造で保存している限り、使えないという危険はない。

・物理的なフォーマットで書く限り、どこまでいっても、
　　使えなくなる可能性はある。
　　そのアプリがなくなればそうだし、フォントがなくなっても使えない。

っていう知識はある。

---

　だから、ほんとーに、「将来的に使えなくなってしまう恐れがある」問題を解決したければ、
・論理的な構造で保存し、
・アプリは「汎用的に」（＝任意の）論理的なXML構造を物理構造にマッピングする機能
　を持っているように→これは、最近のOFFICE製品やDTPにはある。
することを普及しなきゃいけないのに。。(画像、線画だと、若干はなしは違うけど）


　この問題に対処するため政府機関などに対してオープン標準のファイル形式の利用を働き掛け、重要な情報や記録が、どのアプリケーションやエンタープライズプラットフォームで作成したものであっても、将来にわたって利用できるようにすることを目指す。


そーやって、標準とはいえ、特定のフォーマットを普及することで、この問題が、解決すると、本気で思ってる？？

オープンなファイルでも、物理構造ばりばりだったら、将来どころか、プラットフォーム変わっただけで利用できないよ！

フォント＝おおさか

とかいったら、どーするの？（おおさか＝まっくのふぉんと）



　OpenDocument FormatはXMLベースのオフィス文書フォーマットで、テキスト、プレゼンテーション、表計算のフォーマットで構成される。


は？ちょっとまった。

表計算のフォーマットって、それもろに、物理構造になっちゃうよ。
シートどこの行がどこで、列がどこという指定。
（＝ワープロの何ページのたて何ミリ、横何ミリという指定となんら変わらない）

そしたら、そのデータ、表計算ソフト以外で使えなくなっちゃうよ、
機械的には、関係がわかんなくなっちゃうから。。

あと何年もして、仮にケータイが主流になっちゃったら、表計算ソフトが存在するかどうかなんて、わかんないよ？？

---

　結局、はっきり言って、そんなことはわかっていて、

　これって、ただ単に、マイクロソフトに対抗してるだけでしょ。。

　でもねえ、エラーい人って、そーやって、競争するの好きだけど、
　そんなことやってると、消費者から見捨てられると思うよ。

　今、主戦場は、もはやパソコンではない。
　ケータイやPDAも含んだ市場になっている。
　その市場において、マイクロソフトは優位には立っていない。

　したがって、その市場で、ででてくるアプリでも、いままでのデータが使えるような構造（これは、論理構造を、ケータイ用に変換しないとできない）を考えないと、世の中、ケータイに移って、マイクロソフトともども、これらの会社もおいてきぼり、食っちゃうと思うよ。

　もはや、マイクロソフトですら安泰でないほど、ケータイがでて、コンピューターアプリ市場は動いているということを、エラーい人はわかってない。

　やっぱ、王様は裸だ。大丈夫か、この業界（＞＿＜！）

BREWで複数画面を効率的に開発するフレームワークのまとめ：その２画面内制御

　げ、今日は、ケータイネタを書かなかったら見る人が少ない。

　でも、急にケータイネタで、短時間で用意できるのっていうと。。。
　この前の「BREWで複数画面を効率的に開発するフレームワークのまとめ：その１」　の続きだ。。

ということで、その話（まだ、第6回にはいってないのに、そのまとめっていうのも変だけど）。

---

　複数画面において、以下の３つのポイントがあると、前回書きました。
　こんなかんじ。

（１）複数画面を、どう表現し、どう切りかえるか
（２）画面内の項目（コントロール）を、どう制御するのか
（３）画面間（ひいては項目間）に関連するデータをどうするか

　ということで、今回は２つ目の「（２）画面内の項目（コントロール）を、どう制御するのか
」について。

---

■■　一般的なコントロールの表現

　一般的には、こんな感じ。

（あ）アプレットのクラス(pMeにするやつ）に、そのコントロールをかく。

（い）コントロールをISHELL_CreateInstanceで生成する
　１画面しかないような場合は、InitAppDataで良く行われる

（う）必要なら、いろいろ設定した後、再描画する(Redraw)
　ここで、各コントロールのSetActiveをして、（最後の）TRUEのものに、フォーカスが行く
　ただし、この処理は、Startイベントの後に行わないと効かない。
　→１画面や初期画面の場合は、Startのあとにリドローする。
　　　それ以外では、Startはとうに越している。

（え）HandleEventに、各コントロールのHandleEventを書く。
　→黄色と赤のバイブルでは、これ以外方法がないと書いてあったが、
　　実は、自分でつくると、Javaのあだぷたーちっくなことができる
　　（末尾に注で書いておいた）。

（お）フォーカスを当てたいときは、SetActiveする
　値を入れたかったり取り出しかたっから、SetやGetの関数を呼び出す。
　テキトーにやってくれ。

（か）最後にインスタンスを消滅させる（各インスタンスのRelease)。
　１画面ならFreeAppDataの中で行う。

---

■■　では、今回のでは、どうするか？

今回、各画面ごとにInitAppData,HandleEvent,FreeAppDataの関数を用意しました。
で、この関数はStart以降に動きます。そこで、（い）と（う）はまとめられます。
（お）のフォーカスに関しては、１つの関数にまとめます。
ということで、今回gamen1_SetFocusという関数を作ります。

そーすると、こんな感じになります。

（１）アプレットのクラス(pMeにするやつ）（＝あ）
　・そのコントロールをかく。
　　基本的には、全部かく。
　　現在アクティブになっている項目の番号を入れるItemNoという変数を、intでとる

（２）各画面ごとのInitAppData（＝い、う）
・その画面で使うインスタンスを生成します（まあ、後から生成してもいいんだけどね）
・後述のSetFocus関数で、一番初めにフォーカスをあてるものをセット
→gamen1_setFocus(pMe,2);だと、２番目のに、最初のフォーカス
→この関数の中で、リドローする

（３）各画面のHandleEvent（＝え）
　画面内の各コントロールのHandleEventを書く。
　テキトーにSetGetして、処理してくれ
　フォーカスをかえる必要があったり、Redrawする必要があったら、
　SetFocus関数を読んでくれ

（４）各画面のFreeAppData（＝か）
　インスタンスをReleaseする

（５）新設；SetFocus関数（＝お）
　以下の処理を行う関数を用意する

・指定項目が-1（現状どおりでReDrawしろ）でなかったら、
　　　itemNoを指定のものに切り替える

・指定項目が-1以外のとき
switch(itemNo)
{
case 0: // 0の項目だけアクティブ
　　　Iコントロール_SetActive(0番のコントロール,TRUE);
　　　Iコントロール_SetActive(1番のコントロール,FALSE);
　　　Iコントロール_SetActive(2番のコントロール,FALSE);
:
case 1: // 1の項目だけアクティブ
　　　Iコントロール_SetActive(0番のコントロール,FALSE);
　　　Iコントロール_SetActive(1番のコントロール,TRUE);
　　　Iコントロール_SetActive(2番のコントロール,FALSE);
:
のようなものを用意しておき、それを実行する。
　つまり、指定項目のものだけ、TRUE、他はFALSEを送る。そうすれば、そこにフォーカスがあたる

・全部のコントロールをRedrawする

・ついでに、IDISPLAY_UPDATEもしておこうか（＾＾）

---

　って、こんな感じで、行います。

　といっても、抽象的なんでわかりにくいので、第６回で、実際に、どんな感じになるか、書きます。そのあとで、流れについて説明します。

　で、実際には、コントロール以外に自分で作りたいオブジェクトというのもあると思います。
　たとえば、全日本ＶＳパイオニアというバレーボールゲームで、栗原恵さんをオブジェクトにして、操作したいとか。。

　そういう場合も、おんなじカラクリでできますが、それは、また別の機会に書きます。

　ということで、第二回目のまとめは、ここまで。

---

●注　あだぷたーちっく

　　つまり、ある配列を用意し、
　　　　そこに、どのコントロールがActiveのとき
　　　　どー言ったイベントなら
　　　　どの関数を呼び出せ
　　ということをセットしておく。
　　そして、HandleEventの中に来たら、その配列をチェック、条件があったら、
　　どの関数を呼び出せという関数を呼び出す。
　　→どの関数を呼び出せというのは、
typedef struct _aaa
{
PFNNOTIFY pcf;
} Aaa;

　Aaa *pMe;

　 だとすると、 (pMe->pcf)(Voidの引数）;で実行できる。

　けど、まったく、意味通じてないよな（＾＾）今度、気が向いたら書く。

クラス図を立体的に捕らえることでＭＶＣ・仕様書の対比がしやすくなる

げ、さっきのブログで、Ｅｘｃｅｌの仕様書をＸＭＬで書いてプログラムの自動生成ってかいたけど、その前に

・どの仕様書が、どのようにプログラムに一致しているのか

というのを書かないといけないわけで・・
で、ＪＡＶＡのプログラムとＭＶＣの関係も有名。

なんで、仕様書とＭＶＣの関係を説明すればいいんだけど、
仕様書からＸＭＬをからめて、自動化する場合、

この関係を説明するには

・ＭＶＣとクラスの関係を立体的に捕らえると、話がやさしいよ

ということを説明しないと、話がめんどっちいっていうことを思い出した

（って、たぶん、これ読んでる人は、「なにいってんだ、こいつ？？」
だと思うけど、最後まで、いくと、全部見える。途中は、ずーっと
「なにいってんだ、こいつ？？」
だとおもう。

ってことで、まずは、ＭＶＣと、クラスの関係を立体的にとらえるという話

---

■■　クラス図で表現されるもの

　アクティビティ図からユースケース図に落とし、そこにデータを入れて、クラス図に落とし込むか、

　ＥＲ図のエンティティをもとに、データフローにおけるプロセスをテキトーに割り振って、クラス図をつくるか、

　どっちでも、かまわないんだけど、つーか、それ以外の作り方でもいいんだけど、こーやってできたものは、業務のクラス関係を表現している。

---

　一方、これとは、まったく関係なく、明らかに、画面には、クラス関係がある。

　フォーム
　　｜
　コントロール

　の関係ですな。

　で、これを１つのクラス図に表現するのは、別にかまわないんだけど、おなじレベルで考えると、なんだなんだってなる。
　そこで、とりあえず、この２種類のクラス図を分けましょう。

１つは、業務フローにもとづくクラス図
もうひとつは画面構造に基づく画面のクラス図

---

■■　２種類のクラス図を立体的にかんがえると、考えやすいよ

　で、この２種類＋この２つをつなぐクラスというのが仮にあり（これが、コントロール）、それも図に表せるとする。
　そのとき、こうやって考えると、きれいにいくよ。

　　　　　－－－－－－－－－　　
　　　　／ーーーーーーー　／
　　　／　コントロール　／　｜
　　／ーーーーーーー　／　｜｜業務モデルのクラス
　　－－－－－－－－－　｜｜｜
　　｜　　　　　　　｜　｜｜／
　　｜　画面の　　　｜　｜／
　　｜　クラス　　　｜　／
　　｜　　　　　　　｜／
　　－－－－－－－－－　　

上記は、箱のＡＡのつもりじゃ（＾＾）
画面のクラス図が、前面にあり、
真ん中に、コントロールのクラス図
後ろに業務モデルのクラス図がある。
で、この間が、関連でつながっているんだな。。

で、画面のクラスを完成させるには、画面定義書でできる。
したがって、画面定義書をＸＭＬ表現して、
このＸＭＬ表現したものが、自動生成でプログラム作れれば、
Ｖｉｅｗ部分は完成する

コントロールのクラスというのは、実は、どーでもいい
アプリ１個にまとめてもいいし、画面ごとでもよいし。。決めごと
メソッドは、コントロールから呼び出されることになるので、
画面定義書の呼び出しメソッドを画面定義書のＸＭＬから抽出すれば
自動生成できる

業務モデルは、このブログのいっちばん初めに書いたやりかたで
クラス図を作ればいい。そーすると、自動生成。。

---

ってなかんじで、結局、あとは、画面定義書をいかにＸＭＬ表現し、
Ｖｉｅｗとコントロールを自動生成するかを説明すれば、よさげな
雰囲気に。。。なった（＾＾）？
（他の部分、つまり、業務モデルの自動生成話は、さんざん言い尽くされてるんで
いいっしょ　＾＾；まあ、今度かくかもしれないけど）

で、その話。。。かこうかなあ。。。でも、ケータイの話も書かないと、見るひとへっちゃうし。。つーか、これって、脱線話で、本筋の話は違うこと書こうとおもったんだよな。。

っていうことで、次、何書くか、思案中。

２つの編集ソフトにおいて、互換性があるための条件

　すんません。忙しいんで、たいしたことでない話題です。
　昨日の、
ドキュメントにおけるデータ構造の持ち方とXMLでの問題点と、解決法 の話の続きです。

---

　ある編集ソフトが２つあったとします。
　ＤＴＰソフトでも、ワープロでも、表計算でもエディタでもいいです。
　とにかく、編集できるソフトが２つあったとします。

　このときに、２つのソフトをＡ、Ｂとしましょう。
　ＡのソフトのデータをＢのソフトに持っていって、表示・編集したいとき、どんな条件が必要でしょうか？もし、これが完璧にできると互換性を持つということになります。なので、これは、互換性のための条件ともいえます。

　ここで、一気にその問題を考えると難しいので、段階を追います。

ＡからＢのソフトにデータをコンバートすると、こういう結果のどれかになります。

（１）編集もできないし、表示も同じではない
　→まあ、あたりまえやな。これは、互換性があるとはいえない。

（２）編集はできるが、表示はちがう
　テキストエディタとＤＴＰソフトの関係のようなものです。
　記事は、テキストエディタで編集します。そのほうが早いですから。
　で、その記事を流し込んで、ＤＴＰソフトに表示します。
　もちろん、ＤＴＰソフトはテキストエディタの表示よりかずっと複雑に麗しく表示します

（３）表示はできるが、編集はできない、ないしは編集すると崩れる
　ＰＤＦがこれにあたります。
　基本的にＰＤＦは、ＤＴＰの内容を表示しますが、昔のバージョンは編集できなかったし、今でも編集したら、それはＤＴＰで編集するときと同じかといわれれば、そうとは言い切れないです。
　ＥＰＳやＤＴＰソフトの変換直後がこれに当たります。

（４）編集もできて、表示もできる
　完全上位互換の場合です。

---

で、それぞれについて、どういう条件を満たしていればいいかについて、考えます。
ここで（１）は、論外なので、除きます。

（３）が考えやすいので、（３）から説明します。
（３）を実現するには、表示内容があっていればいいので、物理構造のデータさえ、完璧に受け渡しでき、その内容を受け手のＢのソフトで、表現できればＯＫです。
ここでいう、物理構造のデータとは、何ページのどこに、どの文字をどのフォントで、どのサイズで、網掛けは。。。とかいう、見かけの情報です。
　情報が渡ってきても、Ｂのソフトで表現できなければ意味がありません。
　たとえば、ここ、太字で斜体という情報が来ても、受け手がテキストエディタだと、実現できません。

（４）は、（３）の情報に加えて、編集された結果が同じになることを保障しないといけません。編集した結果が同じになるためには、同じ組版規則を同じ条件で処理しないといけません。
　ところが、これは、簡単なものならＯＫなのですが、普通のプロポーショナルフォントで文字をおいた場合、会社が違うアプリ間では、ふつう厳密には、実現できません（だいたいならできるけど）。

　組版ルールの計算単位、方法が違い、それを公表していないため、端数処理の方法や、内部で利用している基準単位（というのがある場合がある。写研の場合、１パルス（４分の１歯）が基準になっていたと思った（ちがうかも）。ＤＴＰでは、ポイントやインチ系が多い）があるばあい、それの違いなどで、狂います。

　っていうことで、
・物理構造が完璧に表現されていて
・組版処理が同じ
ということになり、これは、一般には、同一メーカーの上位互換機か、よっぽど簡単な組版内容のものか（テキストエディタのように全角半角だけでよい）ぐらいです。

---

　ということで、表示をあわせる、つまり（３）、（４）を実現するには、少なくとも物理構造データを全部受け手のソフトに渡して、受け手のソフトがそれを、表現できなければいけません。でも、それって、かならずしも保障できないです。受け手のソフトが下位っていうこともありますから。。

　でも、（２）でいいのであれば、そこまでする必要がありません。
　（２）は、場合によって表示内容が変わります。でも、世の中、そのほうがいいことが多いです。紙に出す場合と、ケータイで見る場合、同じような見え方では、やりにくいです。

　（２）の場合は、見た目は変わるといっているのですから、見た目の物理構造はいりません。しかし、でたらめに文字が並んでいるのでは困るので、ふつう論理構造を渡します。
　つまり、論理構造さえ、渡せばＯＫです。
　そして、この場合、見た目を合わせるには、論理構造から物理構造へ変換する規則（＝ＸＳＬ）が同じであれば、再現できます。

　つまり、（２）でよければ、論理構造を渡せばいいだけです。表示の際にＸＳＬを使うことにより、見た目を表現することができます。

---

　っていうことも、これから書きたい話題の前フリなのです。。

　あ、でもその話よりも、Ｅｘｃｅｌの仕様書をＸＭＬで書いてプログラムの自動生成のほうが、話としては面白いよね。
　で、オブジェクト指向にあわせるためには、結局仕様書のＸＭＬ構造をあわせればいいって言う話しとか・・

　そっちのほう書こうかな（＾＾）