OldType.案の検討 RSSPLAIN

Related pages: OldType
353352225323253522225334442532232225225325322252535355325335352
3

案の検討

5

 

3

コンテンツの公開/非公開の制御

3
案1. 全てWikiネームのネーミングルールでコントロールする ★
5

 

2
公開/非公開は一文字目が '_' かどうかで決まる。
2
 public
2
 _private
5

 

3
メリット
2

全てのコンテンツを通しで処理するバッチが書きやすい

3
デメリット
2

非公開にし忘れる恐れがある。

5

 

3
案2. 公開/非公開はミスを防ぐ為に、根本からディレクトリを分ける
5

 

2
公開コンテンツ
2
 public/*
2
非公開コンテンツ
2
 private/*
5

 

3

コンテンツにツリー構造をサポートするか

3
案1. する
4
    ディレクトリ構成      =>  Wikiネーム
4
    a                     =>  a
4
    a/b/c                 =>  a.b.c
2
      ディレクトリの区切りは '.' で表現
5

 

3
メリット
2

エディタで直接編集するときに、同種のコンテンツをディレクトリでまとめたりできるので把握しやすい。

2

コンテンツにOfficeファイル等の異種ファイルを含めた場合は管理がしやすくなる。

3
デメリット
2

エディタで直接編集するときに、リンクを辿った編集がやりにくい。

2

別の階層に同じ名前のファイルがあった場合、コンテンツ名が衝突してしまう。

2

バッチ処理がやりにくい

5

 

2
案2. しない ★
2

全て同じフォルダに収納する

5

 

3

画像データの置場所を一箇所に集めるか

2
案1-1. 集める。ディレクトリ階層は無し ★
5

 

3
メリット
2

画像が増えた時に、リポジトリに同じ画像が既に登録されているか確認しやすい。

2
デメリット
2

画像が多くなると、目的の画像を探すのに時間がかかる。

5

 

2
案1-2. 集める。但し、ディレクトリの作成は許可する
5

 

3
案2. 各ディレクトリに分散する。
5

 

3
案3. 1ヶ所に実体ファイルを置き、各ディレクトリからはimgファイルをシンボリックリンクで参照する。
5

 

5

 

3

依存規則を定義・実行する方法

2

(これは、コンテンツ全体がどういう構成になるかで変わってくるので後回し?)

5

 

3
案1. makeを使う
3
Makefileを生成してからmakeを実行するスタイルにする
5

 

3
案2. 自前で依存規則を解決して実行するプログラムを作る
5

 

2
案3. 依存規則を使わない。常に全体をビルドする ★