ソースコードの修正

TemPlatはConsoleからの入力情報をもとにサーバー、Web、Appのソースコードを生成します。
ここではそれぞれのソースコードの修正について説明します。

ソースコードの修正方法

ソースコードの修正を行うには、TemPlatが生成したソースコードを取得しましょう。
取得方法はソースコードの取得方法をご参照ください。

ソースコードを取得できたら、それぞれのソースコードをIDEやテキストエディタで開いて修正を行います。

ソースコードの修正に関しては、TemPlatが生成したソースコードとユーザーが修正したソースコードのマージを行うサーバーと、マージを行わないWeb及びAppで考え方が異なりますのでそれぞれ分けて説明します。

サーバーのソースコードの修正

サーバーのソースコードの考え方

サーバーのソースコードは、TemPlatが生成したソースコードとユーザーが修正したソースコードのマージを行います。
これはサーバーの開発はアプリケーションの中心ではなく、ERDの情報から生成されるもののみで最低限のアプリケーションは構築可能で、開発や運用時に発生するERDの変更に伴い確実に修正も画一的な物が多いという思想のためです。

そのためTemPlatには、サーバーのビルドを行なってもユーザーの修正が上書きされない仕組みがあります。
以下で紹介するサーバーの修正方法をマスターすることで、TemPlatを使った開発が更に効率化されますので是非ご参照ください。

サーバーのソースコードの修正方針

前述した通り、サーバーのソースコードは、TemPlatが生成したソースコードとユーザーが修正したソースコードのマージを行うため、ユーザーが修正を行なってもビルド時には上書きされないファイルが存在し、.templat_ignoreというファイルに定義されています。

つまり、.templat_ignoreに定義されているファイルをユーザーは自由に修正可能で、サーバーのビルドを行なった場合でもファイルが上書きされません。
言い換えると、.templat_ignoreに定義されていないファイルはサーバーのビルドを行なった場合にファイルが上書きされてしまう点にご注意ください。

.templat_ignoreについて

.templat_ignoreはサーバーのプロジェクトのルートディレクトリに存在し、サーバービルド時に上書きを行わないファイルを定義します。
記載方法は.gitignoreの記載方法と同じですので、分からない場合は適宜調べてみてください。

また、.templat_ignore自体をユーザーが修正することも可能です。
例えば、.templat_ignoreの内容を全て消した場合は、TemPlatが生成したソースコードで全ファイルが上書きされるようになります。
他にも、ユーザーが追加したファイルをTemPlatが上書き及び削除しないために.templat_ignoreにファイル名を追記する使用方法も想定しています。

.templat_ignoreは初期では以下のような定義がされています。

# Environment files
*.env*

# Application handler files
/src/app/handler/*_handler.go

# Application condition files
/src/app/model/*_condition.go

# Auth config file
/src/app/auth/config.go

# User file
# /src/app/model/app.go
# /src/app/service/app_service.go

なお、先頭に#がついているものはコメントアウトされているので、初期の状態で有効な物は以下のようになります。

  1. Environment files
  2. Application handler files
  3. Application condition files
  4. Auth config file

最後に、それぞれのファイルの具体的な修正内容を以下で説明します。

1. Environment files (*.env*)

環境ごとの設定を記載するファイルです。
.env系の実ファイルは/src/app/env配下に存在します。
詳細はAPIの環境別変数の設定方法をご参照ください。

2. Application handler files (*_handler.go)

サーバーの修正において重要なファイルで、APIの取得値の変更や、ERDからは生成されないアプリケーション独自のAPIの追加等を行います。
サーバーにロジックが追加する場合はほぼ全てこちらのファイルに記載する想定で問題ありません。
具体的な内容は標準APIのカスタマイズ例独自APIの追加をご参照ください。

3. Application condition files (*_condition.go)

ERDに定義されたtableやstructの情報をデータベースは変えずに拡張するために使います。
例えば、API設定で指定できない検索条件をAPIに追加したり、modelにデータベースには存在しないフィールドを追加するのに使用します。
具体的な内容は標準APIのカスタマイズ例をご参照ください。

4. Auth config file (auth/config.go)

認証プラグインを有効にした場合に、認可処理を実装するファイルです。
詳細は認証プラグインをご参照ください。

サーバーの修正方法まとめ

以上のように、.templat_ignoreを理解、修正することでサーバーのソースコードのあらゆる変更が可能になります。
ただし、.templat_ignoreの内容をあまりにも増やすとERDの変更がソースコードに反映されなくなり、管理が複雑になることも大いに想定されます。

そのため、サーバーの修正を行いたい場合は、まずApplication handler files (*_handler.go)やApplication condition files (*_condition.go)の修正で実現することが出来ないかをご検討ください。
かなり特殊なケースを除いて、基本的な修正は上記ファイルの修正で可能なはずです。

Web及びAppのソースコードの修正

Web及びAppのソースコードの考え方

Web及びAppのソースコードは、TemPlatが生成したソースコードとユーザーが修正したソースコードのマージは行いません。
これはWebやAppの開発はアプリケーション開発の中心に位置付けられるとともに、アプリケーションによって大きく異なるため、画一的なものを生成すると逆に扱いが難しくなるのを回避するため、WebやAppのソースコード生成はあくまでアプリケーションの枠組みを生成するという思想のためです。

ただし、枠組みとはいっても、Web及びAppともにサーバーと通信ができる状態で生成されるので、アプリケーションの初期開発には大いに役立つはずです。
また、WebとAppのソースコードはアプリケーションを開発する上でのサンプルコードとしても有用ですので、生成されたソースコードを読むことでTemPlatを使ったアプリケーションの開発方法の参考にしてください。

Web及びAppのソースコードの修正方針

前述した通り、Web及びAppのソースコードは、TemPlatが生成したソースコードとユーザーが修正したソースコードのマージを行わないので、基本的にどのファイルを修正して頂いても構いません。
ただし、修正したファイルをPushするブランチに再度TemPlat Consoleからビルドを行うとソースコードが上書きされてしまう点にご注意ください。

具体的な例で言うと、masterのブランチにそのまま修正をPushした状態で、TemPlat Consoleからmasterブランチに対してビルドを行うと、行なった修正が取り消されてしまいます。
これを回避するには、masterブランチを修正した後で、TemPlat ConsoleからWebやAppのビルドを再度行う場合はdevブランチやtemplatブランチ等のmasterとは別ブランチにビルドを行い、差分をmasterブランチに適宜Pullするか、ビルドを行なったブランチを参考にmasterブランチを適宜修正してください。

このように、Web及びAppのソースコードは参考にする、もしくは一部を引用するような使い方が適しています。

Open APIの更新

ERD変更を行なった場合やサーバーのAPIを変更した場合は、WebやAppのビルドを行わずにOpen APIのみ更新したいケースはビルド画面からOpen APIの更新のみを行うことが出来ます。
詳しくはビルド画面の使い方をご参照ください。