<\/HEAD>
<\/P>
時々、誰かがArcGIS JS APIアプリの構造についてどうすべきか尋ねてきます。私の本では、以下のアプリ構造を推奨しています:<\/P>
<\/P>
app\/<\/STRONG><\/SPAN><\/P> |-- css\/<\/STRONG><\/SPAN><\/P> |-- js\/<\/STRONG><\/SPAN><\/P> |-- controllers\/<\/STRONG><\/SPAN><\/P> |-- services\/<\/STRONG><\/SPAN><\/P> |-- utils\/<\/STRONG><\/SPAN><\/P> |-- widgets\/<\/STRONG><\/SPAN><\/P> |-- main.js<\/STRONG><\/SPAN><\/P> |-- run.js<\/STRONG><\/SPAN><\/P> |-- index.html<\/STRONG><\/SPAN><\/P><\/P>私は多くのプロジェクトでこのアプリ構造を使ってきましたが、問題なく機能しています。通常、私のrun.js<\/STRONG>は次のようなものでした:<\/P>(function() {
'use strict';
var pathRX = new RegExp(\/2F[^\/2F]+$\/2F)
, locationPath = location.pathname.replace(pathRX, '');
require({
packages: [{
name: 'controllers',
location: locationPath + 'js/controllers'
}, {
name: 'widgets',
location: locationPath + 'js/widgets'
}, {
name: 'utils',
location: locationPath + 'js/utils'
}, {
name: 'services',
location: locationPath + 'js/services'
}, {
name: 'app',
location: locationPath + 'js',
main: 'main'
}]
}, ['app']);
})();<\/PRE><\/P>これはかなりうまくいきます。しかし、一つ考慮していないことは、アプリとすべてのサブモジュールをapp<\/STRONG>パッケージとして扱うことです。これはCDNを使う際にモジュールをパッケージとして扱うことに関係しています。違いは何でしょう？<\/EM>お尋ねいただきありがとうございます！<\/P><\/P>例えば、あなたがアプリケーションをビルドしたいとします。もしかするとArcGIS optimizer<\/A>やesri-slurp<\/A>（素晴らしい例がこちらにあります）を利用するかもしれません。あなたは自分のアプリケーションを独自のパッケージとして扱いたいでしょう。どういう意味かというと、ArcGIS JS APIの使い方を見てみましょう。<\/P><\/P>require(['esri/map', 'dojo/declare'], function(Map, declare) {/*cool stuff*/});<\/PRE><\/P>この場合、esri<\/STRONG>はパッケージであり、dojo<\/STRONG>もパッケージです。APIには他にもdgrid<\/STRONG>、dstore<\/STRONG>、そしてdiijt<\/STRONG>などのパッケージが含まれています。これはDojoビルドシステムがファイルの参照方法を知っているためです。したがって、自然に自分のアプリケーションを独自のパッケージ（ここではapp<\/STRONG>と呼びます）としてバンドルできます。好きな名前（例えばSally）でもいいですが、ここではappで十分だと仮定します。<\/P><\/P>なので最近は、このような構造でアプリを作るのが好きです。<\/P>index.html<\/STRONG>
dojoConfig.js
app/
|-- styles/
|-- models/
|-- services/
|-- utils/
|-- widgets/
|-- main.js
|-- app.profile.js
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;
ここでは基本的なセットアップを行うdojoConfigファイルがあります。例えば次のようになります:
var dojoConfig = { async: true, parseOnLoad: true, isDebug: true, deps: ['app/main'] };
さて、これはesri-slurpを使ってAPIをダウンロードし、他の依存関係はbowerでインストールすることを想定しています。CDNとして使う場合は次のようにpackagesプロパティを追加します:
packages: [{ name: 'app', location: location.pathname.replace(/\\[^\\]+$/, '') + 'app' }]
それだけです。
ちょっと待ってください。 このapp.profile.jsって何？ このファイルは私たちのappパッケージ用にresourceTagsを定義しています。これは基本的にDojoビルドシステムに私のパッケージがAMDを使っていることを伝えます。 同僚から教えてもらいましたが、自分では必要ないと思っていました。でもDojoビルドシステムはこれがないとしつこく言ってきます。 内容はこんな感じです:
var profile = (function(){ return { resourceTags: { amd: function(filename, mid) { return /\.js$/.test(filename); } } }; })();
package.jsonはDojoビルドシステムにapp.profileの場所を知らせます:
{ "name": "myapp", "version": "1.0.0", "main": "main", "description": "Demo app.", "homepage": "", "dojoBuild": "app.profile.js" }
config.jsonは私が長年ArcGIS JS APIアプリで使っているもので、基本的にはマップの見た目やウィジェット設定などの設定情報です。このファイルを使ったりWebサービスから設定データを取得したりできます。その例はこちらで見られます： here. アプリ全体はかなり基本的なものです。現在の私のアプリ構造は最近よく使っているember-cliに強く影響されています。
しかしUI構築にReactを使う場合はよりFlux指向な構造にするのが好きです。
index.html
dojoConfig.js
app/
|-- styles/
|-- stores/
|-- actions/
|-- helpers/
|-- views/
|-- main.js
|-- app.profile.js
|-- package.json
|-- config.json
I would also do the same if I were using Angular, where I'd adopt a structure that uses directives instead of views or components. I'm currently working on a Yeoman ArcGIS JS Apps用ジェネレーターで、こちらでデモアプリを見ることができます。まだかなり実験的ですが、役に立つかもしれません。<\/P>
<\/P>
cmv-appは、私が取り組んでいたこのスターターキットに似た設定ベースの興味深いアプリ構造を持っています。<\/P>
<\/P>
ここでの重要なポイントは、私のアドバイスが好きかどうかに関わらず、自分に合った構造を選ぶことです。main.jsをアプリケーションコントローラーとして機能させ、UI関連のすべてをウィジェットフォルダーにまとめることもできます。繰り返しますが、自分に合っていればそれで問題ありません。<\/P>
<\/P>
次のステップであるアプリケーションのカスタムビルド作成について話すフォローアップブログ記事も書きます。それは楽しいはずです！<\/P>
<\/P>
さらに多くのgeodevのヒントやコツについては、私のブログをチェックしてください。<\/P><\/BODY><\/HTML>
